From kelly.ohair at sun.com Mon Dec 1 15:31:35 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Mon, 01 Dec 2008 23:31:35 +0000 Subject: hg: jdk7/build: 6750229: Upgrade Recommended Linux and Windows Build OS Message-ID: <20081201233135.27BC1DE5D@hg.openjdk.java.net> Changeset: 541bdc5ad32f Author: ohair Date: 2008-12-01 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/build/rev/541bdc5ad32f 6750229: Upgrade Recommended Linux and Windows Build OS Reviewed-by: xdono ! README-builds.html From Dalibor.Topic at Sun.COM Tue Dec 2 12:08:58 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 02 Dec 2008 21:08:58 +0100 Subject: [patch] Fix ant build to honor fcs MILESTONE setting In-Reply-To: <1227784804.25258.57.camel@dijkstra.wildebeest.org> References: <1226176961.3276.43.camel@dijkstra.wildebeest.org> <492DBD7D.1000007@sun.com> <1227738411.2453.4.camel@hermans.wildebeest.org> <1227784804.25258.57.camel@dijkstra.wildebeest.org> Message-ID: <493595DA.1040701@Sun.COM> On 11/27/08 12:20, Mark Wielaard wrote: > But please do talk to your legal team to make sure some obvious/trivial > rule is added. Requiring the SCA is a pretty high burden really, > especially for things like a simple s/milestone/fcs/ like change just to > get the build going. And they are most likely completely unnecessary > since such changes are not "legally significant" with respect to > copyright law. The SCA FAQ recommends that contributors execute the SCA for their contributions, no matter how small or large they are: http://www.sun.com/software/opensource/contributor_agreement.jsp#sa_2 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, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From mark at klomp.org Tue Dec 2 12:25:09 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 02 Dec 2008 21:25:09 +0100 Subject: [patch] Fix ant build to honor fcs MILESTONE setting In-Reply-To: <493595DA.1040701@Sun.COM> References: <1226176961.3276.43.camel@dijkstra.wildebeest.org> <492DBD7D.1000007@sun.com> <1227738411.2453.4.camel@hermans.wildebeest.org> <1227784804.25258.57.camel@dijkstra.wildebeest.org> <493595DA.1040701@Sun.COM> Message-ID: <1228249509.21771.4.camel@hermans.wildebeest.org> Hi Dalibor, On Tue, 2008-12-02 at 21:08 +0100, Dalibor Topic wrote: > On 11/27/08 12:20, Mark Wielaard wrote: > > But please do talk to your legal team to make sure some obvious/trivial > > rule is added. Requiring the SCA is a pretty high burden really, > > especially for things like a simple s/milestone/fcs/ like change just to > > get the build going. And they are most likely completely unnecessary > > since such changes are not "legally significant" with respect to > > copyright law. > The SCA FAQ recommends that contributors execute the SCA for their > contributions, no matter how small or large they are: > http://www.sun.com/software/opensource/contributor_agreement.jsp#sa_2 Precisely, that is the problem. Lets talk to the legal team to get a more pragmatic policy in place. See for example: http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html for the GNU Maintainer guidelines around such micro patchlets. But it isn't an issue for the current patch, which has already been checked in thanks to Jon. Cheers, Mark From martinrb at google.com Wed Dec 3 17:04:42 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 Dec 2008 17:04:42 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <4936E036.7030407@sun.com> References: <4936E036.7030407@sun.com> Message-ID: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > The source bundle for OpenJDK 6 build 14 is available for download from: > > http://download.java.net/openjdk/jdk6/ The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) Ubuntu dapper system as follows: cc1plus: warnings being treated as errors /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: In member function 'bool networkStream::connect(const char*, short int)': /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: warning: comparison is always false due to limited range of data type 32-bit systems are unaffected (not sure why). gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Running make with WARNINGS_ARE_ERRORS="" as previously advertised, appears to be the workaround. Martin From Xiaobin.Lu at Sun.COM Wed Dec 3 17:06:18 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 03 Dec 2008 17:06:18 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> Message-ID: <49372D0A.7010001@Sun.COM> I am looking into these failures and trying to fix these now on the latest ubuntu 8.10 installation. The gcc/g++ is 4.3.2. -Xiaobin Martin Buchholz wrote: > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > >> The source bundle for OpenJDK 6 build 14 is available for download from: >> >> http://download.java.net/openjdk/jdk6/ >> > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > Ubuntu dapper system as follows: > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > In member function 'bool networkStream::connect(const char*, short > int)': > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > warning: comparison is always false due to limited range of data type > > 32-bit systems are unaffected (not sure why). > > gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > Running make with WARNINGS_ARE_ERRORS="" as previously advertised, > appears to be the workaround. > > Martin > From aph at redhat.com Thu Dec 4 03:39:43 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Dec 2008 11:39:43 +0000 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> Message-ID: <4937C17F.3090904@redhat.com> Martin Buchholz wrote: > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: >> The source bundle for OpenJDK 6 build 14 is available for download from: >> >> http://download.java.net/openjdk/jdk6/ > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > Ubuntu dapper system as follows: > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > In member function 'bool networkStream::connect(const char*, short > int)': > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > warning: comparison is always false due to limited range of data type > > 32-bit systems are unaffected (not sure why). It's a bug. The code is basically this: #include typedef uint32_t in_addr_t; in_addr_t s_addr; int pp () { return (s_addr == (unsigned long)-1); } Promoting -1 to unsigned long on an LP64 machine gives 0xffffffffffffffff, which won't fit in an in_addr_t. Another weird corner case in C: 6.3.1.3 para 2. Andrew. From John.Coomes at sun.com Thu Dec 4 10:53:34 2008 From: John.Coomes at sun.com (John Coomes) Date: Thu, 4 Dec 2008 10:53:34 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <4937C17F.3090904@redhat.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> Message-ID: <18744.10030.107701.463469@sun.com> Andrew Haley (aph at redhat.com) wrote: > Martin Buchholz wrote: > > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > >> The source bundle for OpenJDK 6 build 14 is available for download from: > >> > >> http://download.java.net/openjdk/jdk6/ > > > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > > Ubuntu dapper system as follows: > > > > cc1plus: warnings being treated as errors > > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > > In member function 'bool networkStream::connect(const char*, short > > int)': > > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > > warning: comparison is always false due to limited range of data type > > > > 32-bit systems are unaffected (not sure why). > > It's a bug. The code is basically this: > ... This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the trivial fix is in jdk7: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 Joe, I can try to get this into jdk6-open, but not until next week at the earliest. Let me know. -John From Joe.Darcy at Sun.COM Thu Dec 4 11:14:47 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 04 Dec 2008 11:14:47 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18744.10030.107701.463469@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> Message-ID: <49382C27.1010102@sun.com> John Coomes wrote: > Andrew Haley (aph at redhat.com) wrote: > >> Martin Buchholz wrote: >> >>> On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: >>> >>>> The source bundle for OpenJDK 6 build 14 is available for download from: >>>> >>>> http://download.java.net/openjdk/jdk6/ >>>> >>> The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) >>> Ubuntu dapper system as follows: >>> >>> cc1plus: warnings being treated as errors >>> /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: >>> In member function 'bool networkStream::connect(const char*, short >>> int)': >>> /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: >>> warning: comparison is always false due to limited range of data type >>> >>> 32-bit systems are unaffected (not sure why). >>> >> It's a bug. The code is basically this: >> ... >> > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > trivial fix is in jdk7: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 > > Joe, I can try to get this into jdk6-open, but not until next week at > the earliest. Let me know. > > -John > > John, Yes, please get the fix back into the OpenJDK 6 HotSpot Mercurial repository, once it is open for business. -Joe From Kelly.Ohair at Sun.COM Thu Dec 4 16:36:51 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 04 Dec 2008 16:36:51 -0800 Subject: hg: jdk7/jdk7: 6750229: Upgrade Recommended Linux and Windows Build OS In-Reply-To: <20081202200225.5FD87DEAF@hg.openjdk.java.net> References: <20081202200225.5FD87DEAF@hg.openjdk.java.net> Message-ID: <493877A3.7020608@sun.com> FYI... This change to the jdk7 README-build.html file was a bit premature with regards to Windows Visual Studio 2008. I jumped the gun a bit on the README with regards to that. Sorry, my fault. The necessary jdk7 changes to build with Visual Studio 2008 are almost ready and should be pushed soon. Tim Bell has been driving this effort and it's getting very close, a big thanks to Tim for his work on this. Also to clarify, these recommended build machine changes do not mean that jdk7 won't continue to build on older systems for a while, however, some of the new features planned for jdk7 will have a build dependency on newer files or features of the build systems. So as jdk7 progresses, eventually it is very likely that Linux systems based on 2.4 kernels, Solaris 8&9 systems, and Windows 2000 systems may not be able to build the entire jdk7. Just some fair warning well ahead of time. -kto Xiomara.Jayasena at Sun.COM wrote: > Changeset: 541bdc5ad32f > Author: ohair > Date: 2008-12-01 15:28 -0800 > URL: http://hg.openjdk.java.net/jdk7/jdk7/rev/541bdc5ad32f > > 6750229: Upgrade Recommended Linux and Windows Build OS > Reviewed-by: xdono > > ! README-builds.html > From mark at klomp.org Fri Dec 5 01:13:36 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 05 Dec 2008 10:13:36 +0100 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18744.10030.107701.463469@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> Message-ID: <1228468416.3521.13.camel@dijkstra.wildebeest.org> Hi John, On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: > > > 32-bit systems are unaffected (not sure why). > > > > It's a bug. The code is basically this: > > ... > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > trivial fix is in jdk7: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 In the icedtea-signed-types.patch (part of the PPC work for zero and cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), which seems slightly cleaner to me since you already have that as typedef. Cheers, Mark [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-November/000562.html From John.Coomes at sun.com Fri Dec 5 10:22:03 2008 From: John.Coomes at sun.com (John Coomes) Date: Fri, 5 Dec 2008 10:22:03 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1228468416.3521.13.camel@dijkstra.wildebeest.org> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> <1228468416.3521.13.camel@dijkstra.wildebeest.org> Message-ID: <18745.29003.253664.806959@sun.com> Mark Wielaard (mark at klomp.org) wrote: > Hi John, > > On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: > > > > 32-bit systems are unaffected (not sure why). > > > > > > It's a bug. The code is basically this: > > > ... > > > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > > trivial fix is in jdk7: > > > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 > > In the icedtea-signed-types.patch (part of the PPC work for zero and > cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), > which seems slightly cleaner to me since you already have that as > typedef. Hi Mark, IIRC, the in_addr_t typedef is missing on windows. I'll double check before submitting a fix. -John > [1] > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-November/000562.html > From aph at redhat.com Fri Dec 5 10:26:53 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Dec 2008 18:26:53 +0000 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18745.29003.253664.806959@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> <1228468416.3521.13.camel@dijkstra.wildebeest.org> <18745.29003.253664.806959@sun.com> Message-ID: <4939726D.1060503@redhat.com> John Coomes wrote: > Mark Wielaard (mark at klomp.org) wrote: >> Hi John, >> >> On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: >>>>> 32-bit systems are unaffected (not sure why). >>>> It's a bug. The code is basically this: >>>> ... >>> This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the >>> trivial fix is in jdk7: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 >> In the icedtea-signed-types.patch (part of the PPC work for zero and >> cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), >> which seems slightly cleaner to me since you already have that as >> typedef. > > Hi Mark, > > IIRC, the in_addr_t typedef is missing on windows. I'll double check > before submitting a fix. Probably is. Maybe int32_t is the best portable solution, unpleasant tho' it is. Andrew. From kelly.ohair at sun.com Fri Dec 5 17:22:58 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Dec 2008 01:22:58 +0000 Subject: hg: jdk7/build: 6781784: Fix ant link in build readme Message-ID: <20081206012258.AB932D287@hg.openjdk.java.net> Changeset: 60aab86966e9 Author: ohair Date: 2008-12-05 17:18 -0800 URL: http://hg.openjdk.java.net/jdk7/build/rev/60aab86966e9 6781784: Fix ant link in build readme Reviewed-by: michaelm ! README-builds.html From twisti at complang.tuwien.ac.at Tue Dec 9 03:25:33 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 09 Dec 2008 12:25:33 +0100 Subject: forward-port IMPORT_BINARY_PLUGS to OpenJDK7 In-Reply-To: <49008D5E.1040300@sun.com> References: <1224601541.27098.8.camel@cthalinger.lan> <48FE70D9.4060900@sun.com> <1224663058.9315.2.camel@cthalinger.lan> <49008D5E.1040300@sun.com> Message-ID: <1228821933.20039.2.camel@localhost.localdomain> On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote: > Hi guys, > > I could take care of applying the same patch than what I did > a few months ago for OpenJDK 6. > > Namely, if you compile OpenJDK with the binary plugs, the SNMP > runtime will be compiled and included in rt.jar. If you compile > without the binary plugs, the SNMP runtime will not be included. > > If you try to activate the SNMP agent on an OpenJDK instance that > doesn't have the SNMP runtime in rt.jar then you will get an > exception. > > This was integrated in OpenJDK 6 b06. > 6661448: Make the SNMP agent optional when OPENJDK=true > and IMPORT_BINARY_PLUGS=false > > Would that help? Ping? - Christian From eng.tamerabdo at gmail.com Fri Dec 12 09:05:15 2008 From: eng.tamerabdo at gmail.com (tamer abd el-lateef) Date: Fri, 12 Dec 2008 19:05:15 +0200 Subject: Compiler build Question Message-ID: Dear Members; I downloaded the openJDK "openjdk-7-ea-src-b40-20_nov_2008.zip" then i added the compiler peoject "Javac" to the Netbeans IDE ver 6.5 . - in the build.properties file i updated the "target.java.home" property to my JDK path. then when i tried to copile the project i got the following error : where Mypath is my Installed JDK path. Please find the attached snapshot. and i am waiting for your advice. thank you in advance -- Tamer Mohamed Abd El-lateef Senior Software Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081212/d5fc6899/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Compiler Build.JPG Type: image/jpeg Size: 99630 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081212/d5fc6899/attachment.jpe From Daniel.Fuchs at Sun.COM Fri Dec 12 10:28:11 2008 From: Daniel.Fuchs at Sun.COM (Daniel Fuchs) Date: Fri, 12 Dec 2008 19:28:11 +0100 Subject: Compiler build Question In-Reply-To: References: Message-ID: <4942AD3B.2000503@sun.com> I Tamer, I believe you need to define this variable: bootstrap.jdk= in $HOME/.openjdk/build.properties. see make/netbeans/README http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d782143219d6/make/netbeans/README Best regards, -- daniel http://blogs.sun.com/jmxetc tamer abd el-lateef wrote: > Dear Members; > > I downloaded the openJDK "openjdk-7-ea-src-b40-20_nov_2008.zip" then i > added the compiler peoject "Javac" to the Netbeans IDE ver 6.5 . > > - in the build.properties file i updated the "target.java.home" property > to my JDK path. > > then when i tried to copile the project i got the following error : > > > where Mypath is my Installed JDK path. > > Please find the attached snapshot. > > and i am waiting for your advice. > > thank you in advance > > > > -- > Tamer Mohamed Abd El-lateef > Senior Software Developer > > ------------------------------------------------------------------------ > From Jonathan.Gibbons at Sun.COM Fri Dec 12 10:48:04 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 12 Dec 2008 10:48:04 -0800 Subject: Compiler build Question In-Reply-To: <4942AD3B.2000503@sun.com> References: <4942AD3B.2000503@sun.com> Message-ID: Tamar, I'm not sure what you mean by "the compiler project 'javac'". The sources for javac are in the "compiler" project in the langtools repository. It seems there may be problems using the standard projects with NetBeans 6.5. You might also want to try NB 6.1. The problem is how well NetBeans handles (or doesn't handle) overlapping sources in sibling projects, which is a characteristic of the langtools projects, and of the jdk projects as well, I believe. -- Jon On Dec 12, 2008, at 10:28 AM, Daniel Fuchs wrote: > I Tamer, > > I believe you need to define this variable: > > bootstrap.jdk= > > in $HOME/.openjdk/build.properties. > > see make/netbeans/README > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d782143219d6/make/netbeans/README > > Best regards, > > -- daniel > http://blogs.sun.com/jmxetc > > > > tamer abd el-lateef wrote: >> Dear Members; >> I downloaded the openJDK "openjdk-7-ea-src-b40-20_nov_2008.zip" >> then i added the compiler peoject "Javac" to the Netbeans IDE ver >> 6.5 . >> - in the build.properties file i updated the "target.java.home" >> property to my JDK path. >> then when i tried to copile the project i got the following error : >> >> where Mypath is my Installed JDK path. >> Please find the attached snapshot. >> and i am waiting for your advice. >> thank you in advance >> -- >> Tamer Mohamed Abd El-lateef >> Senior Software Developer >> ------------------------------------------------------------------------ > From Jonathan.Gibbons at Sun.COM Fri Dec 12 11:49:37 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 12 Dec 2008 11:49:37 -0800 Subject: Compiler build Question In-Reply-To: References: Message-ID: <4942C051.6030409@sun.com> Tamer, Did you also set boot.java.home, which appears slightly earlier in the file than is shown in your screenshot. You need to set two, potentially different, values for installed versions of Java. You need a version of Java to build the compiler. Set boot.java.home for this. It can be JDK 6 or later. You also need a version of Java to run the (tests for the) compiler. Set target.java.home for this. It should be JDK 7 or later. -- Jon tamer abd el-lateef wrote: > Dear Members; > > I downloaded the openJDK "openjdk-7-ea-src-b40-20_nov_2008.zip" then i > added the compiler peoject "Javac" to the Netbeans IDE ver 6.5 . > > - in the build.properties file i updated the "target.java.home" > property to my JDK path. > > then when i tried to copile the project i got the following error : > > > where Mypath is my Installed JDK path. > > Please find the attached snapshot. > > and i am waiting for your advice. > > thank you in advance > > > > -- > Tamer Mohamed Abd El-lateef > Senior Software Developer > > ------------------------------------------------------------------------ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081212/6c3660bd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 99630 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081212/6c3660bd/attachment.jpe From xiomara.jayasena at sun.com Mon Dec 15 10:31:29 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:31:29 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20081215183129.5445ED83C@hg.openjdk.java.net> Changeset: a20db75d7f33 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/rev/a20db75d7f33 Added tag jdk7-b41 for changeset 541bdc5ad32f ! .hgtags Changeset: 94052b872873 Author: xdono Date: 2008-12-15 10:24 -0800 URL: http://hg.openjdk.java.net/jdk7/build/rev/94052b872873 Merge From xiomara.jayasena at sun.com Mon Dec 15 10:33:36 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:33:36 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b41 for changeset c90eeda9594e Message-ID: <20081215183337.2BAE8D841@hg.openjdk.java.net> Changeset: d9a0ca94dcf8 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/d9a0ca94dcf8 Added tag jdk7-b41 for changeset c90eeda9594e ! .hgtags From xiomara.jayasena at sun.com Mon Dec 15 10:37:04 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:37:04 +0000 Subject: hg: jdk7/build/hotspot: 24 new changesets Message-ID: <20081215183750.7E014D846@hg.openjdk.java.net> Changeset: 2e4f74ff86a1 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2e4f74ff86a1 Added tag jdk7-b41 for changeset f9d938ede196 ! .hgtags Changeset: 2b42b31e7928 Author: coleenp Date: 2008-11-21 08:09 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2b42b31e7928 6676175: BigApps crash JVM Client VM (build 10.0-b22, mixed mode, sharing) with SIGSEGV (0xb) Summary: Add test for biased locking epoch before walking own thread stack in case of rare race Reviewed-by: phh, never ! src/share/vm/runtime/biasedLocking.cpp Changeset: ba7f9d894282 Author: kamg Date: 2008-11-21 15:10 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ba7f9d894282 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 171e581e8161 Author: xlu Date: 2008-11-22 00:16 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/171e581e8161 6554406: Change switch UseVMInterruptibleIO default to false (sol) Summary: The default value of UseVMInterruptibleIO is changed to false for JDK 7, but the default isn't changed for JDK 6 and earlier. Reviewed-by: never, acorn, dholmes, kamg, alanb ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b22701a8b88f Author: coleenp Date: 2008-11-24 14:45 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b22701a8b88f 6474243: suspicious jvmti code that uses oop unsafely across GC point Summary: oop stored in unsafely in Lscratch noticed by visual inspection will not be updated by GC. Reviewed-by: kamg, never, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: a60eabc24e2c Author: kamg Date: 2008-11-25 15:59 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a60eabc24e2c Merge Changeset: 00b023ae2d78 Author: ysr Date: 2008-11-20 12:27 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/00b023ae2d78 6722113: CMS: Incorrect overflow handling during precleaning of Reference lists Summary: When we encounter marking stack overflow during precleaning of Reference lists, we were using the overflow list mechanism, which can cause problems on account of mutating the mark word of the header because of conflicts with mutator accesses and updates of that field. Instead we should use the usual mechanism for overflow handling in concurrent phases, namely dirtying of the card on which the overflowed object lies. Since precleaning effectively does a form of discovered list processing, albeit with discovery enabled, we needed to adjust some code to be correct in the face of interleaved processing and discovery. Reviewed-by: apetrusenko, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: c96030fff130 Author: ysr Date: 2008-11-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c96030fff130 6684579: SoftReference processing can be made more efficient Summary: For current soft-ref clearing policies, we can decide at marking time if a soft-reference will definitely not be cleared, postponing the decision of whether it will definitely be cleared to the final reference processing phase. This can be especially beneficial in the case of concurrent collectors where the marking is usually concurrent but reference processing is usually not. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/macros.hpp Changeset: df4305d4c1a1 Author: ysr Date: 2008-11-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/df4305d4c1a1 6774607: SIGSEGV or (!is_null(v),"oop value can never be zero") assertion when running with CMS and COOPs Summary: Use the more permissive set_klass_or_null() and klass_or_null() interfaces in ParNew's workqueue overflow code that manipulates the klass-word. Reviewed-by: coleenp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: 434912c745cf Author: iveresov Date: 2008-11-26 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/434912c745cf Merge ! src/share/vm/runtime/globals.hpp Changeset: b6272ef4a18f Author: poonam Date: 2008-11-27 18:19 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b6272ef4a18f 6743339: Enable building sa-jdi.jar and sawindbg.dll on Windows with hotspot build Summary: These changes enable the SA binaries build with hotspot build on Windows Reviewed-by: swamyv ! make/windows/build.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: 27a80744a83b Author: ysr Date: 2008-12-01 23:25 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/27a80744a83b 6778647: snap(), snap_policy() should be renamed setup(), setup_policy() Summary: Renamed Reference{Policy,Pocessor} methods from snap{,_policy}() to setup{,_policy}() Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 95cad1ab2510 Author: jmasa Date: 2008-12-03 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/95cad1ab2510 Merge Changeset: 3a86a8dcf27c Author: never Date: 2008-11-25 13:14 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3a86a8dcf27c 6756768: C1 generates invalid code Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.hpp + test/compiler/6756768/Test6756768.java + test/compiler/6756768/Test6756768_2.java Changeset: 424f9bfe6b96 Author: kvn Date: 2008-12-03 13:41 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/424f9bfe6b96 6775880: EA +DeoptimizeALot: assert(mon_info->owner()->is_locked(),"object must be locked now") Summary: Create new "eliminated" BoxLock node for monitor debug info when corresponding locks are eliminated. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/output.cpp + test/compiler/6775880/Test.java Changeset: 1f54ed41d6ae Author: kvn Date: 2008-12-04 08:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1f54ed41d6ae Merge Changeset: 85f1b9537f70 Author: iveresov Date: 2008-12-03 14:18 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/85f1b9537f70 6779436: NUMA allocator: libnuma expects certain size of the buffer in numa_node_to_cpus() Summary: In os::Linux::rebuild_cpu_to_node_map() fix the size of the CPU bitmap. Fixed arithmetic in MutableNUMASpace::adaptive_chunk_size() that could cause overflows and underflows of the chunk_size variable. Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/runtime/globals.hpp Changeset: ab25f609be4a Author: jmasa Date: 2008-12-04 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ab25f609be4a Merge Changeset: 8a0c882e46d6 Author: jmasa Date: 2008-12-04 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8a0c882e46d6 Merge Changeset: dc16daa0329d Author: poonam Date: 2008-12-04 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dc16daa0329d 6739363: Xcheck jni doesn't check native function arguments Summary: Fix adds support for verifying arguments with -Xcheck:jni. Reviewed-by: coleenp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 63d1bf926938 Author: poonam Date: 2008-12-04 17:48 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/63d1bf926938 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 8724fb00c422 Author: blacklion Date: 2008-12-05 15:06 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8724fb00c422 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core Changeset: 7cee1a61ffd7 Author: trims Date: 2008-12-05 15:32 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7cee1a61ffd7 Merge Changeset: 3c4d36b4a7ac Author: trims Date: 2008-12-05 15:45 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3c4d36b4a7ac 6781742: Bump HS14 build number to 09 Summary: Update Hotspot 14 build number to b09 Reviewed-by: jcoomes ! make/hotspot_version From xiomara.jayasena at sun.com Mon Dec 15 10:41:33 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:41:33 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b41 for changeset 0758bd3e2852 Message-ID: <20081215184135.6C08AD84D@hg.openjdk.java.net> Changeset: 036e0dca841a Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/036e0dca841a Added tag jdk7-b41 for changeset 0758bd3e2852 ! .hgtags From xiomara.jayasena at sun.com Mon Dec 15 10:43:41 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:43:41 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b41 for changeset a8379d24aa03 Message-ID: <20081215184343.433A9D854@hg.openjdk.java.net> Changeset: 621c02d83abc Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/621c02d83abc Added tag jdk7-b41 for changeset a8379d24aa03 ! .hgtags From xiomara.jayasena at sun.com Mon Dec 15 10:46:00 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:46:00 +0000 Subject: hg: jdk7/build/jdk: 14 new changesets Message-ID: <20081215184845.2B715D85B@hg.openjdk.java.net> Changeset: b213ea31bcb3 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b213ea31bcb3 Added tag jdk7-b41 for changeset 44941f893cea ! .hgtags Changeset: 4f985ba72055 Author: sherman Date: 2008-11-19 14:29 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4f985ba72055 6714428: 'os.name' system property shows wrong value on 64-bit Windows XP Summary: update to detect the correct os.name for 64-bit XP Reviewed-by: darcy ! src/windows/native/java/lang/java_props_md.c Changeset: 098e456e860e Author: emcmanus Date: 2008-11-20 10:10 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/098e456e860e 6772779: @NotificationInfo does not create MBeanNotificationInfo in the MBean's MBeanInfo 6773593: CompositeDataSupport constructor javadoc is not in sync with the implementation Reviewed-by: sjiang ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 9df22bc448a3 Author: sherman Date: 2008-11-20 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9df22bc448a3 6745216: missing 4 chraset aliases in sun.nio.cs package Summary: added "834" into x-IBM834's aliase list. Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java Changeset: 97e2e87aa035 Author: dfuchs Date: 2008-11-21 18:18 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/97e2e87aa035 6774170: LocalRMIServerSocketFactory should protect against ServerSocket.accept().getInetAddress() being null Reviewed-by: emcmanus, jfdenise ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java + test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: ce2d0938ea27 Author: tbell Date: 2008-11-21 20:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ce2d0938ea27 Merge Changeset: d7b0a715bd3b Author: martin Date: 2008-11-23 09:56 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d7b0a715bd3b 6775152: freetype version check program problem main arg order Summary: Fix all compiler warnings Reviewed-by: ohair, tbell ! make/common/shared/Sanity.gmk Changeset: 31cb1c17f524 Author: mullan Date: 2008-11-25 10:17 -0500 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/31cb1c17f524 6728890: Add SwissSign root certificates to the JDK 6732157: Add VeriSign TSA Root Cert to the JDK 6754779: Add Camerfirma root certificates to the JDK 6768559: Add t-systems root CA certificate (Deutsche Telekom Root CA 2) to the JRE Reviewed-by: vinnie ! test/lib/security/cacerts/VerifyCACerts.java Changeset: b1620482689a Author: sherman Date: 2008-11-25 10:09 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b1620482689a 6774710: spp.sh used by genBasic.sh/genCopyDirectMemory.sh Summary: update the scripts to use java version of spp Reviewed-by: alanb ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh Changeset: b7c47f49a53d Author: alanb Date: 2008-11-25 19:26 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b7c47f49a53d 6593946: (bf) X-Buffer.compact() does not discard mark as specified Summary: InvalidMarkException now correctly thrown. Thanks to keiths at redhat.com for the bug report and initial fix. Reviewed-by: sherman, darcy ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh Changeset: a0709a172b6d Author: chegar Date: 2008-11-26 15:37 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a0709a172b6d 6720866: Slow performance using HttpURLConnection for upload Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java Changeset: 24a31530683d Author: emcmanus Date: 2008-11-27 15:44 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/24a31530683d 6776225: JMX.isNotificationSource wrong when DynamicWrapperMBean + SendNotification injection Reviewed-by: dfuchs, jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/StandardMBean.java ! test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java Changeset: 3d110bb4dc19 Author: sherman Date: 2008-11-29 20:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3d110bb4dc19 6725399: (ch) Channels.newInputStream should check for null Summary: update to check null arg for all Channels methods Reviewed-by: alanb ! src/share/classes/java/nio/channels/Channels.java ! test/java/nio/channels/Channels/Basic.java Changeset: d782143219d6 Author: tbell Date: 2008-12-05 09:51 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d782143219d6 Merge From xiomara.jayasena at sun.com Mon Dec 15 10:53:50 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 15 Dec 2008 18:53:50 +0000 Subject: hg: jdk7/build/langtools: 4 new changesets Message-ID: <20081215185357.37DB3D860@hg.openjdk.java.net> Changeset: 1d4f01925bd0 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/1d4f01925bd0 Added tag jdk7-b41 for changeset ded6b40f558e ! .hgtags Changeset: 1d1f34b36535 Author: mcimadamore Date: 2008-11-26 11:07 +0000 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/1d1f34b36535 6776289: Regression: javac7 doesnt resolve method calls properly Summary: Superclass' private methods shouldn't be considered during method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/6711619/T6711619a.out + test/tools/javac/overload/T6776289.java Changeset: 6210fb7e7544 Author: jjg Date: 2008-12-01 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/6210fb7e7544 6778493: Fix (langtools) ant build to honor fcs MILESTONE setting Reviewed-by: ohair Contributed-by: mjw at redhat.com ! make/Makefile Changeset: 4674298aaf3b Author: tbell Date: 2008-12-05 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/4674298aaf3b Merge From xiomara.jayasena at sun.com Mon Dec 15 17:27:59 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 16 Dec 2008 01:27:59 +0000 Subject: hg: jdk7/build/corba: 6785258: Update copyright year Message-ID: <20081216012800.0A44DD8D0@hg.openjdk.java.net> Changeset: ccd6a16502e0 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/ccd6a16502e0 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk From xiomara.jayasena at sun.com Mon Dec 15 17:29:58 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 16 Dec 2008 01:29:58 +0000 Subject: hg: jdk7/build/hotspot: 6785258: Update copyright year Message-ID: <20081216013000.74B3AD8D5@hg.openjdk.java.net> Changeset: ad8c8ca4ab0f Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ad8c8ca4ab0f 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/cpu/x86/vm/vm_version_x86_32.hpp ! src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/globals_linux.hpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.cpp From xiomara.jayasena at sun.com Mon Dec 15 17:32:07 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 16 Dec 2008 01:32:07 +0000 Subject: hg: jdk7/build/jdk: 6785258: Update copyright year Message-ID: <20081216013219.25688D8DE@hg.openjdk.java.net> Changeset: 3ef0bdfa7609 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3ef0bdfa7609 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/javax/swing/Makefile ! make/netbeans/jmx/build.xml ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/share/classes/com/sun/jmx/defaults/ServiceName.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/SecureClassLoaderRepository.java ! src/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java ! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/share/classes/com/sun/jmx/remote/internal/Unmarshal.java ! src/share/classes/com/sun/jmx/remote/util/ClassLoaderWithRepository.java ! src/share/classes/com/sun/jmx/remote/util/ClassLogger.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/ClientContext.java ! src/share/classes/javax/management/DefaultLoaderRepository.java ! src/share/classes/javax/management/JMRuntimeException.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/Notification.java ! src/share/classes/javax/management/NotificationListener.java ! src/share/classes/javax/management/loading/DefaultLoaderRepository.java ! src/share/classes/javax/management/loading/MLetObjectInputStream.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/relation/MBeanServerNotificationFilter.java ! src/share/classes/javax/management/relation/Role.java ! src/share/classes/javax/management/relation/RoleList.java ! src/share/classes/javax/management/relation/RoleResult.java ! src/share/classes/javax/management/relation/RoleUnresolved.java ! src/share/classes/javax/management/relation/RoleUnresolvedList.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnection.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/AbstractSpinnerModel.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LayoutComparator.java ! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/share/classes/javax/swing/MultiUIDefaults.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DragRecognitionSupport.java ! src/share/classes/javax/swing/plaf/basic/LazyActionMap.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBumps.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/DefaultSynthStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/ImagePainter.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthContext.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/LayoutQueue.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/SegmentCache.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/HRuleView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/Map.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/TagStack.java ! src/share/classes/javax/swing/text/rtf/MockAttributeSet.java ! src/share/classes/javax/swing/text/rtf/RTFParser.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/StateEdit.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/UndoableEditSupport.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java ! src/share/classes/sun/net/ProgressEvent.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/swing/AccessibleMethod.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! src/share/native/sun/font/bidi/ubidi.c ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh ! test/java/nio/channels/Channels/Basic.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/javax/management/Introspector/AnnotationTest.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java ! test/javax/management/context/ContextTest.java ! test/javax/management/context/LocaleTest.java ! test/javax/management/context/LocalizableTest.java ! test/javax/management/context/localizable/MBeanDescriptions_fr.java ! test/javax/management/context/localizable/Whatsit.java ! test/javax/management/context/localizable/WhatsitMBean.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SimpleStandard.java ! test/javax/swing/RepaintManager/6608456/bug6608456.java ! test/javax/swing/text/html/HRuleView/Test5062055.java ! test/javax/xml/crypto/dsig/GenerationTests.java From xiomara.jayasena at sun.com Mon Dec 15 17:34:14 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 16 Dec 2008 01:34:14 +0000 Subject: hg: jdk7/build/langtools: 2 new changesets Message-ID: <20081216013417.70929D8E3@hg.openjdk.java.net> Changeset: fdfed22db054 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/fdfed22db054 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/javax/tools/FileObject.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testSupplementary/TestSupplementary.java ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/apt/Discovery/discovery.sh ! test/tools/apt/mirror/declaration/AnnoMirror.java ! test/tools/apt/mirror/declaration/AnnoTypeDecl.java ! test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java ! test/tools/apt/mirror/declaration/AnnoVal.java ! test/tools/apt/mirror/declaration/ClassDecl.java ! test/tools/apt/mirror/declaration/ConstExpr.java ! test/tools/apt/mirror/declaration/ConstructorDecl.java ! test/tools/apt/mirror/declaration/EnumDecl.java ! test/tools/apt/mirror/declaration/FieldDecl.java ! test/tools/apt/mirror/declaration/GetAnno.java ! test/tools/apt/mirror/declaration/InterfaceDecl.java ! test/tools/apt/mirror/declaration/MethodDecl.java ! test/tools/apt/mirror/declaration/PackageDecl.java ! test/tools/apt/mirror/declaration/ParameterDecl.java ! test/tools/apt/mirror/type/AnnoTyp.java ! test/tools/apt/mirror/type/ArrayTyp.java ! test/tools/apt/mirror/type/ClassTyp.java ! test/tools/apt/mirror/type/EnumTyp.java ! test/tools/apt/mirror/type/InterfaceTyp.java ! test/tools/apt/mirror/type/PrimitiveTyp.java ! test/tools/apt/mirror/type/TypeVar.java ! test/tools/apt/mirror/type/WildcardTyp.java ! test/tools/apt/mirror/util/Overrides.java ! test/tools/apt/mirror/util/TypeCreation.java ! test/tools/javac/6457284/T6457284.java ! test/tools/javac/links/T.java ! test/tools/javac/links/links.sh ! test/tools/javac/policy/test1/A.java ! test/tools/javac/policy/test1/D.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/processing/6348193/T6348193.java ! test/tools/javadoc/BooleanConst.java ! test/tools/javadoc/BreakIteratorWarning.java ! test/tools/javadoc/FlagsTooEarly.java ! test/tools/javadoc/InlineTagsWithBraces.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/MethodLinks.java ! test/tools/javadoc/NoStar.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javadoc/XWerror.java ! test/tools/javadoc/completionFailure/CompletionFailure.java ! test/tools/javadoc/dupOk/DupOk.java ! test/tools/javadoc/imports/MissingImport.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/nestedClass/NestedClass.java ! test/tools/javadoc/sourceOnly/p/SourceOnly.java ! test/tools/javadoc/sourceOption/SourceOption.java ! test/tools/javadoc/subpackageIgnore/SubpackageIgnore.java Changeset: 5e5567c2db56 Author: xdono Date: 2008-12-15 17:13 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/5e5567c2db56 Merge From martinrb at google.com Fri Dec 19 00:52:47 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2008 00:52:47 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <490938A9.9050201@sun.com> References: <490938A9.9050201@sun.com> Message-ID: <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> build 42 has come, and the JDK binaries no longer work on my system (32-bit Ubuntu dapper). java -version gives an instant crash with "floating point exception". Not very friendly. I have always liked the fact that in the past Sun's JDK engineers put in great effort to ensure that JDK binaries work on a large variety of systems, generally by being built on some old unloved machine in the closet. I believe using Fedora 9 for official binaries is excessively aggressive. Like the JDK itself, operating systems (like Ubuntu "Long Term Support") tend to have about a 5-year support lifespan. Fedora 9 is just too young. I suggest using a build machine that, like Ubuntu dapper, has a glibc 2.3, which was the first release with NPTL. More specifically, I recommend glibc 2.3.6. Or more generally, try to support popular platforms for at least 5 years of life. Martin On Wed, Oct 29, 2008 at 20:31, Xiomara Jayasena wrote: > > Hi, > > The official Release Engineering builds for JDK 7 will be moving from the > following OSs: > > *32 bit builds* > ========== > *From: *RH AS 2.1 to Fedora 9 > > *64 bit builds* > ========== > *From: *SUSE 8 to: Fedora 9 > > All required Makefile changes are in place, there are still other items > that are still being investigated for this OS upgrade to happen but wanted > to inform of the changes that are on the way. > *When:* It is expected that this change will happen by build 42. > > Please let me know if there are any questions. > > Thanks, > -Xiomara > > From Weijun.Wang at Sun.COM Fri Dec 19 01:15:50 2008 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Fri, 19 Dec 2008 17:15:50 +0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> Message-ID: <494B6646.2040309@sun.com> +10^10^10 Martin Buchholz wrote: > build 42 has come, and the JDK binaries no longer work on my > system (32-bit Ubuntu dapper). java -version gives > an instant crash with "floating point exception". > Not very friendly. > > I have always liked the fact that in the past Sun's JDK engineers > put in great effort to ensure that JDK binaries work on > a large variety of systems, generally by being built on > some old unloved machine in the closet. > > I believe using Fedora 9 for official binaries is > excessively aggressive. > Like the JDK itself, operating systems (like Ubuntu > "Long Term Support") tend to have about a > 5-year support lifespan. Fedora 9 is just too young. > > I suggest using a build machine that, like Ubuntu dapper, > has a glibc 2.3, which was the first release with NPTL. > More specifically, I recommend glibc 2.3.6. > > Or more generally, try to support popular platforms > for at least 5 years of life. > > Martin > > On Wed, Oct 29, 2008 at 20:31, Xiomara Jayasena > wrote: >> Hi, >> >> The official Release Engineering builds for JDK 7 will be moving from the >> following OSs: >> >> *32 bit builds* >> ========== >> *From: *RH AS 2.1 to Fedora 9 >> >> *64 bit builds* >> ========== >> *From: *SUSE 8 to: Fedora 9 >> >> All required Makefile changes are in place, there are still other items >> that are still being investigated for this OS upgrade to happen but wanted >> to inform of the changes that are on the way. >> *When:* It is expected that this change will happen by build 42. >> >> Please let me know if there are any questions. >> >> Thanks, >> -Xiomara >> >> From mark at klomp.org Fri Dec 19 01:57:10 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 10:57:10 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> Message-ID: <1229680630.3344.46.camel@dijkstra.wildebeest.org> Hi Martin, On Fri, 2008-12-19 at 00:52 -0800, Martin Buchholz wrote: > build 42 has come, and the JDK binaries no longer work on my > system (32-bit Ubuntu dapper). java -version gives > an instant crash with "floating point exception". > Not very friendly. > > I have always liked the fact that in the past Sun's JDK engineers > put in great effort to ensure that JDK binaries work on > a large variety of systems, generally by being built on > some old unloved machine in the closet. > > I believe using Fedora 9 for official binaries is > excessively aggressive. Are there any "official" GPL binaries for OpenJDK these days? If there are it would be interesting to use these for testing against distro produced binaries. But how would be tag these builds as "official"? Thanks, Mark From aph at redhat.com Fri Dec 19 03:39:00 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Dec 2008 11:39:00 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> Message-ID: <494B87D4.6070700@redhat.com> Martin Buchholz wrote: > build 42 has come, and the JDK binaries no longer work on my > system (32-bit Ubuntu dapper). java -version gives > an instant crash with "floating point exception". > Not very friendly. > > I have always liked the fact that in the past Sun's JDK engineers > put in great effort to ensure that JDK binaries work on > a large variety of systems, generally by being built on > some old unloved machine in the closet. > > I believe using Fedora 9 for official binaries is > excessively aggressive. Does this failure to run on Ubuntu dapper have anything to do with Fedora 9? Andrew. From twisti at complang.tuwien.ac.at Fri Dec 19 08:58:27 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Fri, 19 Dec 2008 17:58:27 +0100 Subject: forward-port IMPORT_BINARY_PLUGS to OpenJDK7 In-Reply-To: <1228821933.20039.2.camel@localhost.localdomain> References: <1224601541.27098.8.camel@cthalinger.lan> <48FE70D9.4060900@sun.com> <1224663058.9315.2.camel@cthalinger.lan> <49008D5E.1040300@sun.com> <1228821933.20039.2.camel@localhost.localdomain> Message-ID: <1229705908.8229.54.camel@localhost.localdomain> On Tue, 2008-12-09 at 12:25 +0100, Christian Thalinger wrote: > On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote: > > Hi guys, > > > > I could take care of applying the same patch than what I did > > a few months ago for OpenJDK 6. > > > > Namely, if you compile OpenJDK with the binary plugs, the SNMP > > runtime will be compiled and included in rt.jar. If you compile > > without the binary plugs, the SNMP runtime will not be included. > > > > If you try to activate the SNMP agent on an OpenJDK instance that > > doesn't have the SNMP runtime in rt.jar then you will get an > > exception. > > > > This was integrated in OpenJDK 6 b06. > > 6661448: Make the SNMP agent optional when OPENJDK=true > > and IMPORT_BINARY_PLUGS=false > > > > Would that help? > > Ping? Too little time to port that patch? - Christian From martinrb at google.com Fri Dec 19 09:32:07 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2008 09:32:07 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229680630.3344.46.camel@dijkstra.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> Message-ID: <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> On Fri, Dec 19, 2008 at 01:57, Mark Wielaard wrote: > Are there any "official" GPL binaries for OpenJDK these days? No, but I encourage Sun and encourage others to encourage Sun to provide those, at least for Linux where there is a community that cares. > If there > are it would be interesting to use these for testing against distro > produced binaries. That is the primary purpose for me - comparative testing. (For the same reason, "proprietary" JDK builds are also valuable for open source developers) > But how would be tag these builds as "official"? I'm not sure I understand the question. Here "official" means there's been some release engineering love and an expectation of a minimal level of quality. Martin From martinrb at google.com Fri Dec 19 09:41:08 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2008 09:41:08 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494B87D4.6070700@redhat.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> Message-ID: <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> On Fri, Dec 19, 2008 at 03:39, Andrew Haley wrote: > Does this failure to run on Ubuntu dapper have anything to do with > Fedora 9? Since it appears to have been caused by building on Fedora 9, the answer is very likely "yes". In particular, Fedora 9 very likely has a glibc version > 2.3, and apps built on such a system tend to have linker dependencies on symbols introduced in glibc 2.4, causing libc.so.6: version `GLIBC_2.4' not found load-time errors. I also suspect compiler runtime incompatibilities. (I've never used Fedora, and I'm not suggesting there's anything wrong with Fedora 9, aside from being too new.) Martin From mark at klomp.org Fri Dec 19 09:53:09 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 18:53:09 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> Message-ID: <1229709189.3344.110.camel@dijkstra.wildebeest.org> Hi Martin, On Fri, 2008-12-19 at 09:32 -0800, Martin Buchholz wrote: > On Fri, Dec 19, 2008 at 01:57, Mark Wielaard wrote: > > Are there any "official" GPL binaries for OpenJDK these days? > > No, but I encourage Sun and encourage others to encourage Sun > to provide those, at least for Linux where there is a community that cares. To be honest I think it will be easier to get the distros to do this for us. They are much better at it and it saves you from endless discussion of which architectures, platforms, compilers, libraries, configure/build options, etc need to be supported. Still, if they were around I would indeed take a look and compare stuff a bit with my local builds if I had any strange test failures for example. Fedora 9 binaries would be fine for me, I am on Fedora 10 already :) Although my servers are a mix of Debian stable and CentOS 5. > > But how would be tag these builds as "official"? > > I'm not sure I understand the question. > Here "official" means there's been some release engineering love > and an expectation of a minimal level of quality. Sorry, typo in my question. s/be/we/. But that answer does indeed start to answer my question. It would need a certain level of support from the community. How much love would be needed? Just setting up an autobuilder? Or running all jtreg tests (what about the manual ones?). How and where to store them, for how long? What build platform and architecture to use? etc. I'll try and make some time during the vacation to get a build going on Debian stable (that should certainly be old enough :) But getting things bootstrapping on such old distros is pretty challenging. We have a builder machine in the classpath.org domain, but I am not sure it has enough capacity at the moment. Cheers, Mark From aph at redhat.com Fri Dec 19 10:27:27 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Dec 2008 18:27:27 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> Message-ID: <494BE78F.1020405@redhat.com> Martin Buchholz wrote: > On Fri, Dec 19, 2008 at 03:39, Andrew Haley wrote: >> Does this failure to run on Ubuntu dapper have anything to do with >> Fedora 9? > > Since it appears to have been caused by building on Fedora 9, > the answer is very likely "yes". > > In particular, Fedora 9 very likely has a glibc version > 2.3, > and apps built on such a system tend to have linker > dependencies on symbols introduced in glibc 2.4, > causing > libc.so.6: version `GLIBC_2.4' not found > load-time errors. > > I also suspect compiler runtime incompatibilities. > > (I've never used Fedora, and I'm not suggesting there's anything > wrong with Fedora 9, aside from being too new.) I guess it depends on what the builds are for. OpenJDK is the future, and builds of OpenJDK are forward-looking. Yea, even OpenJDK 6. At some point you have to admit that you *need* to build on something more recent. As an example of the cost of building on old boxes, OpenJDK contains prototypes for epoll(7) that are incorrect for some arches. These prototypes exist because epoll didn't come into existence before Kernel 2.6(ish), and OpenJDK was being built on an old box, so the prototypes were copied from the kernel headers on (I think) an x86 box. This bug causes bizarre and hard to debug behaviour on non-x86 arches. At some point you have to get rid of cruft like this. If not now, when? Andrew. From martinrb at google.com Fri Dec 19 10:37:40 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2008 10:37:40 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229709189.3344.110.camel@dijkstra.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> <1229709189.3344.110.camel@dijkstra.wildebeest.org> Message-ID: <1ccfd1c10812191037g5eb19ee1v78306a17516828c9@mail.gmail.com> Hi Mark, On Fri, Dec 19, 2008 at 09:53, Mark Wielaard wrote: > To be honest I think it will be easier to get the distros to do this for > us. They are much better at it and it saves you from endless discussion > of which architectures, platforms, compilers, libraries, configure/build > options, etc need to be supported. There's the old debate over the "one true binary" vs. a set of binaries optimized for every particular platform. Each has their advantages. > Still, if they were around I would indeed take a look and compare stuff > a bit with my local builds if I had any strange test failures for > example. > > Fedora 9 binaries would be fine for me, I am on Fedora 10 already :) > Although my servers are a mix of Debian stable and CentOS 5. > >> > But how would be tag these builds as "official"? >> >> I'm not sure I understand the question. >> Here "official" means there's been some release engineering love >> and an expectation of a minimal level of quality. Let me expand on that a little. Every "build" coming from Sun has already had a significant amount of testing applied to it. For comparative testing, I would like to try the very same binaries that Sun must have already created. Martin From gnu_andrew at member.fsf.org Fri Dec 19 10:53:20 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 19 Dec 2008 18:53:20 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> Message-ID: <17c6771e0812191053h1861c60dk57d84859ef077879@mail.gmail.com> 2008/12/19 Martin Buchholz : > On Fri, Dec 19, 2008 at 01:57, Mark Wielaard wrote: >> Are there any "official" GPL binaries for OpenJDK these days? > > No, but I encourage Sun and encourage others to encourage Sun > to provide those, at least for Linux where there is a community that cares. > No, it's still not even possible to build Free binaries with raw OpenJDK as the sound and SNMP plugs are required. IcedTea7 fixes this of course and provides Gervill. For OpenJDK6, it's definitely possible and should be being done to properly promote the spirit of OpenJDK. If you're going to use a proprietary plug with OpenJDK6, you may as well just use 6u10 or whatever anyway. >> If there >> are it would be interesting to use these for testing against distro >> produced binaries. > > That is the primary purpose for me - comparative testing. > (For the same reason, "proprietary" JDK builds are also valuable > for open source developers) > Hmmm I wonder why -- is this for some real need or because they don't realise what is being shipped in their distro these days? >> But how would be tag these builds as "official"? > > I'm not sure I understand the question. > Here "official" means there's been some release engineering love > and an expectation of a minimal level of quality. > Sounds like a distro build IMO. > Martin > Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Dec 19 10:55:10 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 19 Dec 2008 18:55:10 +0000 Subject: forward-port IMPORT_BINARY_PLUGS to OpenJDK7 In-Reply-To: <1229705908.8229.54.camel@localhost.localdomain> References: <1224601541.27098.8.camel@cthalinger.lan> <48FE70D9.4060900@sun.com> <1224663058.9315.2.camel@cthalinger.lan> <49008D5E.1040300@sun.com> <1228821933.20039.2.camel@localhost.localdomain> <1229705908.8229.54.camel@localhost.localdomain> Message-ID: <17c6771e0812191055x65a29966p3953444b211a165c@mail.gmail.com> 2008/12/19 Christian Thalinger : > On Tue, 2008-12-09 at 12:25 +0100, Christian Thalinger wrote: >> On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote: >> > Hi guys, >> > >> > I could take care of applying the same patch than what I did >> > a few months ago for OpenJDK 6. >> > >> > Namely, if you compile OpenJDK with the binary plugs, the SNMP >> > runtime will be compiled and included in rt.jar. If you compile >> > without the binary plugs, the SNMP runtime will not be included. >> > >> > If you try to activate the SNMP agent on an OpenJDK instance that >> > doesn't have the SNMP runtime in rt.jar then you will get an >> > exception. >> > >> > This was integrated in OpenJDK 6 b06. >> > 6661448: Make the SNMP agent optional when OPENJDK=true >> > and IMPORT_BINARY_PLUGS=false >> > >> > Would that help? >> >> Ping? > > Too little time to port that patch? > > - Christian > > I've not seen any more on it yet. And would it really help given Gervill hasn't made it into 7 either AFAIK? But very disappointing that (raw) OpenJDK is not actually Free yet after all this time. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From martinrb at google.com Fri Dec 19 10:55:49 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2008 10:55:49 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494BE78F.1020405@redhat.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> Message-ID: <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> On Fri, Dec 19, 2008 at 10:27, Andrew Haley wrote: > As an example of the cost of building on old boxes, OpenJDK contains > prototypes for epoll(7) that are incorrect for some arches. These We are changing the subject slightly from portability of binaries to portability of sources. > prototypes exist because epoll didn't come into existence before > Kernel 2.6(ish), and OpenJDK was being built on an old box, so the > prototypes were copied from the kernel headers on (I think) an x86 > box. This bug causes bizarre and hard to debug behaviour on non-x86 > arches. > > At some point you have to get rid of cruft like this. If not now, > when? Obviously opinions differ on how long to support older platforms. "Kids these days..." think 2 years is old. When I was maintaining an open source project, I tried to maintain a portability horizon of at least 10 years. Seriously. I would like people to be able to build my software on that old Irix machine they picked up at a garage sale. For problems like changing prototypes, we have configure. Sure the following example is ugly cruft, but we can wait one more decade before nuking it. dnl If `getpgrp' takes no argument (the POSIX.1 version), define dnl `GETPGRP_VOID'. Otherwise, it is the BSD version, which takes a dnl process ID as an argument. AC_CHECK_FUNCS(getpgrp) AC_FUNC_GETPGRP Martin From Kelly.Ohair at Sun.COM Fri Dec 19 11:39:26 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 19 Dec 2008 11:39:26 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> Message-ID: <494BF86E.7000400@sun.com> These are not official product binaries but early access binary snapshots, you can't expect these binaries to be perfect by any means. They are also not OpenJDK7 builds but JDK7 builds. It was decided that we needed to update our JDK7 Linux build systems, so we had to do something to move out of the Dark Ages. The Linux systems we have been using were setup for jdk1.4.2, and used through jdk6. They were 2.4 kernel based systems. To minimize our packaging effort an rpm based system made the most sense, and Fedora9 seemed like the right choice at the time. This could change, we can build on a variety of systems, but jumping from ship to ship probably won't help matters without understanding why things don't work. We knew this was an experiment and we ran the risk of some Linux systems not working, for a multitude of reasons. And we also know that we cannot possible make everyone happy in whatever we pick. So what we need to do is figure out if there is a way to build on Fedora9 that allows the product to work better on other systems, or if we need to change to something other than Fedora9. Constructive suggestions are welcome. -kto Martin Buchholz wrote: > On Fri, Dec 19, 2008 at 10:27, Andrew Haley wrote: >> As an example of the cost of building on old boxes, OpenJDK contains >> prototypes for epoll(7) that are incorrect for some arches. These > > We are changing the subject slightly from portability of binaries > to portability of sources. > >> prototypes exist because epoll didn't come into existence before >> Kernel 2.6(ish), and OpenJDK was being built on an old box, so the >> prototypes were copied from the kernel headers on (I think) an x86 >> box. This bug causes bizarre and hard to debug behaviour on non-x86 >> arches. >> >> At some point you have to get rid of cruft like this. If not now, >> when? > > Obviously opinions differ on how long to support older platforms. > > "Kids these days..." think 2 years is old. > > When I was maintaining an open source project, > I tried to maintain a portability horizon of at least 10 years. > Seriously. I would like people to be able to build my > software on that old Irix machine they picked up at a > garage sale. > > For problems like changing prototypes, we have configure. > > Sure the following example is ugly cruft, > but we can wait one more decade before nuking it. > > dnl If `getpgrp' takes no argument (the POSIX.1 version), define > dnl `GETPGRP_VOID'. Otherwise, it is the BSD version, which takes a > dnl process ID as an argument. > AC_CHECK_FUNCS(getpgrp) > AC_FUNC_GETPGRP > > Martin From aph at redhat.com Fri Dec 19 11:52:20 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Dec 2008 19:52:20 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> Message-ID: <494BFB74.9050601@redhat.com> Martin Buchholz wrote: > On Fri, Dec 19, 2008 at 10:27, Andrew Haley wrote: >> As an example of the cost of building on old boxes, OpenJDK contains >> prototypes for epoll(7) that are incorrect for some arches. These > > We are changing the subject slightly from portability of binaries > to portability of sources. > >> prototypes exist because epoll didn't come into existence before >> Kernel 2.6(ish), and OpenJDK was being built on an old box, so the >> prototypes were copied from the kernel headers on (I think) an x86 >> box. This bug causes bizarre and hard to debug behaviour on non-x86 >> arches. >> >> At some point you have to get rid of cruft like this. If not now, >> when? > > Obviously opinions differ on how long to support older platforms. > > "Kids these days..." think 2 years is old. > > When I was maintaining an open source project, > I tried to maintain a portability horizon of at least 10 years. > Seriously. I would like people to be able to build my > software on that old Irix machine they picked up at a > garage sale. Well, we have to distinguish between what you like and what is best for the project as a whole! There's a nice note by Dijkstra called "On the fact that the Atlantic Ocean has two sides" where he ruminates about the Buxton Index: "A very useful measure is ?called after its inventor? the "Buxton Index". John N. Buxton discovered that the most important one-dimensional scale along which persons are institutions to be compared, can be placed is the length of the period of time in the future for which a person or institution plans. This period, measured in years, gives the Buxton Index. "The great significance of the Buxton Index is not its depth, but its objectivity. The point is that when people with drastically different Buxton Indices have to cooperate while unaware of the concept of the Buxton Index, they tend to make moral accusations against each other. The man with the shorter Buxton Index accuses the other of neglect of duty, the man with the larger one accuses the other of shortsightedness. The notion of the Buxton Index takes the moral flavour away and enables people to discuss such differences among themselves dispassionately. There is nothing wrong with having different Buxton Indices! It takes many people to make a world. There is clearly no moral value attached to either a long or a short Buxton Index." I am aware that we are here talking about time projected into the past, not the future, but I think the situation is very similar. You might think that I am very aggressive with obsoleting old versions, while I might think you are hanging onto dead softwtare for no good reason. > For problems like changing prototypes, we have configure. > > Sure the following example is ugly cruft, > but we can wait one more decade before nuking it. We can, but should we? :-) Andrew. From mark at klomp.org Fri Dec 19 12:11:38 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 21:11:38 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1ccfd1c10812191037g5eb19ee1v78306a17516828c9@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> <1229709189.3344.110.camel@dijkstra.wildebeest.org> <1ccfd1c10812191037g5eb19ee1v78306a17516828c9@mail.gmail.com> Message-ID: <1229717498.3626.9.camel@hermans.wildebeest.org> Hi Martin, On Fri, 2008-12-19 at 10:37 -0800, Martin Buchholz wrote: > On Fri, Dec 19, 2008 at 09:53, Mark Wielaard wrote: > > Still, if they were around I would indeed take a look and compare stuff > > a bit with my local builds if I had any strange test failures for > > example. > > > > Fedora 9 binaries would be fine for me, I am on Fedora 10 already :) > > Although my servers are a mix of Debian stable and CentOS 5. > > > >> > But how would be tag these builds as "official"? > >> > >> I'm not sure I understand the question. > >> Here "official" means there's been some release engineering love > >> and an expectation of a minimal level of quality. > > Let me expand on that a little. > Every "build" coming from Sun has already had > a significant amount of testing applied to it. > For comparative testing, I would like to try the very same binaries > that Sun must have already created. Sure. But you need something that is completely automated and completely reproducible by the rest of the community. For example in icedtea we integrated all the tests in such a way that a simple make && make check runs them. Producing binary artifacts only makes sense really if you can do it methodically, otherwise you risk publishing things that depend on some individual's setup. That also means having enough capacity to do it on an ongoing basis. I'll see if we can finally expand builder.classpath.org to provide something like this over the next weeks, or that we would need to throw more hardware at it (which I think we will need seeing that we are already using the servers mostly at their capacity and having a build-bot for openjdk/icedtea will be pushing it a bit I am afraid). Another issue is that we aren't currently at zero-fail (ignoring the non-automated tests). It would be nice make this a requirement. Cheers, Mark From mlists at juma.me.uk Fri Dec 19 12:32:39 2008 From: mlists at juma.me.uk (Ismael Juma) Date: Fri, 19 Dec 2008 20:32:39 +0000 (UTC) Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <1229680630.3344.46.camel@dijkstra.wildebeest.org> <1ccfd1c10812190932l4c9c30e9od878c87c21b70976@mail.gmail.com> <1229709189.3344.110.camel@dijkstra.wildebeest.org> <1ccfd1c10812191037g5eb19ee1v78306a17516828c9@mail.gmail.com> <1229717498.3626.9.camel@hermans.wildebeest.org> Message-ID: Mark Wielaard writes: > Sure. But you need something that is completely automated and completely > reproducible by the rest of the community. Yes, this is very important indeed. Ismael From mark at klomp.org Fri Dec 19 13:01:51 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 22:01:51 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494BF86E.7000400@sun.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> Message-ID: <1229720511.3626.12.camel@hermans.wildebeest.org> Hi Kelly, On Fri, 2008-12-19 at 11:39 -0800, Kelly O'Hair wrote: > These are not official product binaries but early access binary > snapshots, you can't expect these binaries to be perfect by any > means. They are also not OpenJDK7 builds but JDK7 builds. What is the difference between these kinds of builds? Would it be hard to expand these snapshots to include OpenJDK? If you already happen to have an automated build setup around could you share it so others can also use it? Thanks, Mark From gnu_andrew at member.fsf.org Fri Dec 19 13:07:08 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 19 Dec 2008 21:07:08 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229720511.3626.12.camel@hermans.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> Message-ID: <17c6771e0812191307s18d3f04m4d4c672cd5d3adad@mail.gmail.com> 2008/12/19 Mark Wielaard : > Hi Kelly, > > On Fri, 2008-12-19 at 11:39 -0800, Kelly O'Hair wrote: >> These are not official product binaries but early access binary >> snapshots, you can't expect these binaries to be perfect by any >> means. They are also not OpenJDK7 builds but JDK7 builds. > > What is the difference between these kinds of builds? Would it be hard > to expand these snapshots to include OpenJDK? If you already happen to > have an automated build setup around could you share it so others can > also use it? > > Thanks, > > Mark > > Well presumably it means it still has all the old proprietary cruft which was ejected from OpenJDK about a year ago... -- Andrew :-) 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 David.Herron at Sun.COM Fri Dec 19 13:46:05 2008 From: David.Herron at Sun.COM (David Herron @ Sun) Date: Fri, 19 Dec 2008 13:46:05 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <17c6771e0812191307s18d3f04m4d4c672cd5d3adad@mail.gmail.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <17c6771e0812191307s18d3f04m4d4c672cd5d3adad@mail.gmail.com> Message-ID: <494C161D.6000100@sun.com> Andrew John Hughes wrote: > 2008/12/19 Mark Wielaard : > >> Hi Kelly, >> >> On Fri, 2008-12-19 at 11:39 -0800, Kelly O'Hair wrote: >> >>> These are not official product binaries but early access binary >>> snapshots, you can't expect these binaries to be perfect by any >>> means. They are also not OpenJDK7 builds but JDK7 builds. >>> >> What is the difference between these kinds of builds? Would it be hard >> to expand these snapshots to include OpenJDK? If you already happen to >> have an automated build setup around could you share it so others can >> also use it? >> >> Thanks, >> >> Mark >> > Well presumably it means it still has all the old proprietary cruft > which was ejected from OpenJDK about a year ago... > That's essentially correct. Further when we say OpenJDK7 gets a lot of testing, the testing occurs on JDK7 binary bundles. We don't explicitly test OpenJDK7 but rely on the extreme similarity of the two to assure quality of OpenJDK7. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081219/2476e0c7/attachment.html From mark at klomp.org Fri Dec 19 13:57:13 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 22:57:13 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494C161D.6000100@sun.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <17c6771e0812191307s18d3f04m4d4c672cd5d3adad@mail.gmail.com> <494C161D.6000100@sun.com> Message-ID: <1229723833.3626.19.camel@hermans.wildebeest.org> Hi David, On Fri, 2008-12-19 at 13:46 -0800, David Herron @ Sun wrote: > Further when we say OpenJDK7 gets a lot of testing, the testing occurs > on JDK7 binary bundles. We don't explicitly test OpenJDK7 but rely on > the extreme similarity of the two to assure quality of OpenJDK7. So what would it take to extend this to OpenJDK proper? And why don't you directly test and build binaries for OpenJDK? Could you share your test setup with the rest of the community so we can do more coordinated support and testing? Thanks, Mark From gnu_andrew at member.fsf.org Fri Dec 19 14:03:21 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 19 Dec 2008 22:03:21 +0000 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229723833.3626.19.camel@hermans.wildebeest.org> References: <490938A9.9050201@sun.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <17c6771e0812191307s18d3f04m4d4c672cd5d3adad@mail.gmail.com> <494C161D.6000100@sun.com> <1229723833.3626.19.camel@hermans.wildebeest.org> Message-ID: <17c6771e0812191403x27a2f585ufad346858f99b0c2@mail.gmail.com> 2008/12/19 Mark Wielaard : > Hi David, > > On Fri, 2008-12-19 at 13:46 -0800, David Herron @ Sun wrote: >> Further when we say OpenJDK7 gets a lot of testing, the testing occurs >> on JDK7 binary bundles. We don't explicitly test OpenJDK7 but rely on >> the extreme similarity of the two to assure quality of OpenJDK7. > > So what would it take to extend this to OpenJDK proper? And why don't > you directly test and build binaries for OpenJDK? > > Could you share your test setup with the rest of the community so we can > do more coordinated support and testing? > > Thanks, > > Mark > > +1 -- Andrew :-) 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 Dec 19 14:21:49 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 19 Dec 2008 14:21:49 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229720511.3626.12.camel@hermans.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> Message-ID: <494C1E7D.9090308@sun.com> The JDK7 early access binary snapshot builds are built from the OpenJDK7 sources, plus additional files and repositories we either cannot or haven't opened up yet (for various reasons). This build process has been created over the years around the Sun JDK product releases, the official build process takes many hours and involves things like virus scans etc. Not sure it's worth exposing, seems low priority to me anyway. Other than the freetype font logic (and maybe the sound code that is coming in at some point), there is little in the OpenJDK7 sources NOT built by the formal Sun JDK7 builds. To guarantee that a OpenJDK7 build only contained OpenJDK7 we would have to do a completely separate build. Justifying this is difficult when the standard open source procedure is to effectively roll-yer-own, not use any built bits from Sun. -kto Mark Wielaard wrote: > Hi Kelly, > > On Fri, 2008-12-19 at 11:39 -0800, Kelly O'Hair wrote: >> These are not official product binaries but early access binary >> snapshots, you can't expect these binaries to be perfect by any >> means. They are also not OpenJDK7 builds but JDK7 builds. > > What is the difference between these kinds of builds? Would it be hard > to expand these snapshots to include OpenJDK? If you already happen to > have an automated build setup around could you share it so others can > also use it? > > Thanks, > > Mark > From mark at klomp.org Fri Dec 19 14:56:34 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 19 Dec 2008 23:56:34 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494C1E7D.9090308@sun.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> Message-ID: <1229727394.3626.35.camel@hermans.wildebeest.org> Hi Kelly, On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: > The JDK7 early access binary snapshot builds are built from the > OpenJDK7 sources, plus additional files and repositories we either > cannot or haven't opened up yet (for various reasons). Do you have a list of these additional files and repositories? Is there anything for which there still isn't a free replacement available? > This build process has been created over the years around the Sun > JDK product releases, the official build process takes many hours > and involves things like virus scans etc. > Not sure it's worth exposing, seems low priority to me anyway. Yeah, it probably depends on the etc. But build systems have a tendency to get entangled with all kinds of local setups and installation issues. Having a standardized shared build system that people can copy and setup for their own particular environment does have its advantages though. It helps the community feel in control of their own niches. > To guarantee that a OpenJDK7 build only contained OpenJDK7 > we would have to do a completely separate build. > Justifying this is difficult when the standard open source > procedure is to effectively roll-yer-own, not use any built bits > from Sun. Yes, that is the route we took with IcedTea of course. But now that we have proven that you can bootstrap the whole system starting with only free bits it would be nice to unify the standard builds again though, so that the default is the same for all of the community. Cheers, Mark From Dmitri.Trembovetski at Sun.COM Fri Dec 19 17:00:59 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 19 Dec 2008 17:00:59 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229727394.3626.35.camel@hermans.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> Message-ID: <494C43CB.6050203@Sun.COM> Mark Wielaard wrote: > Hi Kelly, > > On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: >> The JDK7 early access binary snapshot builds are built from the >> OpenJDK7 sources, plus additional files and repositories we either >> cannot or haven't opened up yet (for various reasons). > > Do you have a list of these additional files and repositories? Is there > anything for which there still isn't a free replacement available? For some of these free replacements are available in the openjdk tree, but they aren't yet of satisfactory quality (like the antialiasing rasterizer), so Sun's proprietary builds won't be switching to those components for a while. Thanks, Dmitri From Kelly.Ohair at Sun.COM Fri Dec 19 17:45:51 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 19 Dec 2008 17:45:51 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <1229727394.3626.35.camel@hermans.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> Message-ID: <494C4E4F.9090601@sun.com> I'm just a small (maybe medium sized) cog in the machinery around here. ;^) Mark Wielaard wrote: > Hi Kelly, > > On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: >> The JDK7 early access binary snapshot builds are built from the >> OpenJDK7 sources, plus additional files and repositories we either >> cannot or haven't opened up yet (for various reasons). > > Do you have a list of these additional files and repositories? Is there > anything for which there still isn't a free replacement available? > Priority one, we wanted to either open source or get open source replacements for the binary plugs (openjdk6 only has snmp left?). I know we need to apply these changes to the openjdk7 repos now. And we have a way to build without snmp that we will try and put in place in openjdk7, and maybe get to the point of being able to build both openjdk6 and openjdk7 without those annoying binary plugs. Tests that have not been open sourced require a review for possible legal issues, this takes time, an annoyingly long time. Some sources have been slowly opened up, I think hotspot added the linux sparc sources which used to be closed sources. So some of the sources are moving to the open area as the review process and decisions are made. Yes, progress is slow, but it is progress. The plugin remains the hot potato. I won't go there. :^( >> This build process has been created over the years around the Sun >> JDK product releases, the official build process takes many hours >> and involves things like virus scans etc. >> Not sure it's worth exposing, seems low priority to me anyway. > > Yeah, it probably depends on the etc. But build systems have a tendency > to get entangled with all kinds of local setups and installation issues. > This one is extremely dependent on the internal Sun network, and is mostly home grown. I just can't see any value in spending our time opening this up. > Having a standardized shared build system that people can copy and setup > for their own particular environment does have its advantages though. It > helps the community feel in control of their own niches. > It has been my opinion that we should invest in setting up a Hudson (http://hudson.dev.java.net) system (or equivalent open source build setup). But the idea and any effort is in a pre-infancy stage. If and when we did something like that, we would certainly make the configuration or setup procedure public. >> To guarantee that a OpenJDK7 build only contained OpenJDK7 >> we would have to do a completely separate build. >> Justifying this is difficult when the standard open source >> procedure is to effectively roll-yer-own, not use any built bits >> from Sun. > > Yes, that is the route we took with IcedTea of course. But now that we > have proven that you can bootstrap the whole system starting with only > free bits it would be nice to unify the standard builds again though, so > that the default is the same for all of the community. The Sun JDK product build procedures will likely always be different I can't see them ever being completely the same. When you have something that works, it's hard to justify tearing it apart and risking the stability you have. -kto > > Cheers, > > Mark > From martinrb at google.com Sat Dec 20 01:07:15 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 20 Dec 2008 01:07:15 -0800 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494BF86E.7000400@sun.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> Message-ID: <1ccfd1c10812200107g63cacaddkab5bca80aa8bddfa@mail.gmail.com> On Fri, Dec 19, 2008 at 11:39, Kelly O'Hair wrote: > So what we need to do is figure out if there is a way to build > on Fedora9 that allows the product to work better on other systems, > or if we need to change to something other than Fedora9. > > Constructive suggestions are welcome. I suggest not trying to use Fedora9 for release engineering builds. Let individual developers use Fedora, if they wish. Use one of the stable supported releases (or their clones) that include glibc 2.3. Either RHEL 4 or Ubuntu dapper would qualify. Martin From hwadechandler-openjdk at yahoo.com Sat Dec 20 08:01:09 2008 From: hwadechandler-openjdk at yahoo.com (hwadechandler-openjdk at yahoo.com) Date: Sat, 20 Dec 2008 08:01:09 -0800 (PST) Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1ccfd1c10812200107g63cacaddkab5bca80aa8bddfa@mail.gmail.com> Message-ID: <719889.11538.qm@web33804.mail.mud.yahoo.com> CentOS would be good in that case. It is a binary compatible, as it is built from the same sources, RH. Ubuntu is based on Debian is it not? But definitely with RHx or CentOSx you'll get a longer release cycle of the OS itself. Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: Martin Buchholz > To: Kelly O'Hair > Cc: discuss at openjdk.java.net; build-dev ; Xiomara Jayasena > Sent: Saturday, December 20, 2008 4:07:15 AM > Subject: Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9 > > On Fri, Dec 19, 2008 at 11:39, Kelly O'Hair wrote: > > So what we need to do is figure out if there is a way to build > > on Fedora9 that allows the product to work better on other systems, > > or if we need to change to something other than Fedora9. > > > > Constructive suggestions are welcome. > > I suggest not trying to use Fedora9 for release engineering builds. > Let individual developers use Fedora, if they wish. > > Use one of the stable supported releases (or their clones) that > include glibc 2.3. Either RHEL 4 or Ubuntu dapper would qualify. > > Martin From mark at klomp.org Sun Dec 21 03:26:51 2008 From: mark at klomp.org (Mark Wielaard) Date: Sun, 21 Dec 2008 12:26:51 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494C43CB.6050203@Sun.COM> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> <494C43CB.6050203@Sun.COM> Message-ID: <1229858811.3443.14.camel@dijkstra.wildebeest.org> Hi Dmitri, On Fri, 2008-12-19 at 17:00 -0800, Dmitri Trembovetski wrote: > Mark Wielaard wrote: > > On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: > >> The JDK7 early access binary snapshot builds are built from the > >> OpenJDK7 sources, plus additional files and repositories we either > >> cannot or haven't opened up yet (for various reasons). > > > > Do you have a list of these additional files and repositories? Is there > > anything for which there still isn't a free replacement available? > > For some of these free replacements are available in the openjdk > tree, but they aren't yet of satisfactory quality (like the > antialiasing rasterizer) Do you have a list of quality improvements (or maybe test cases) that are needed for these components? Do you know if someone is already working on those improvements? Thanks, Mark From mark at klomp.org Sun Dec 21 03:46:34 2008 From: mark at klomp.org (Mark Wielaard) Date: Sun, 21 Dec 2008 12:46:34 +0100 Subject: Heads Up: JDK 7 Linux platforms moving to Fedora 9 In-Reply-To: <494C4E4F.9090601@sun.com> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> <494C4E4F.9090601@sun.com> Message-ID: <1229859994.3443.34.camel@dijkstra.wildebeest.org> Hi Kelly, On Fri, 2008-12-19 at 17:45 -0800, Kelly O'Hair wrote: > I'm just a small (maybe medium sized) cog in the machinery around > here. ;^) We small and medium sized cogs need to work together to turn this into a well functioning coding machine! > Mark Wielaard wrote: > Priority one, we wanted to either open source or get open source > replacements for the binary plugs (openjdk6 only has snmp left?). About snmp. Do you happen to know an example program that uses this functionality? That would probably encourage people to get free replacement code to enable such an app. There are two (failing of course) tests in the jtreg jdk suite. Are there any more tests that could be liberated to help implementing this? > Some sources have been slowly opened up, I think hotspot added the > linux > sparc sources which used to be closed sources. Yes, that was very nice! IcedTea6 has this backported and various GNU/Linux distros now come with a hotspot based sparc variant (I know of at least Fedora and Debian). > So some of the sources are moving to the open area as the review > process and decisions are made. Yes, progress is slow, but it is > progress. And thanks a lot for all the progress. I don't want to sound as if I don't see the enormous progress that is being made (and it really is enormous, just the fact that 99% of the whole code base is out there is probably one, if not the, largest liberation of formerly proprietary code ever done!) The reason I do ask questions like these however is to help form an inclusive community. It is hard for those outside Sun to relate at times because there are no roadmaps for some of the progress (and no idea if some of the remaining proprietary stuff will ever be liberated or what the holdup really is). And no roadmap means we have no idea if we are duplicating work or that we are accelerating it. > The plugin remains the hot potato. I won't go there. :^( I don't think that is a very high priority item since we have free replacement code around already anyway that is shipped with all distros now anyway. It could be improvement for sure, since it seems to be missing some of the newer functionality. But basic applets and webstart just work now. Lots of juicy bugs remain however for those wanting to help improve it. Cheers, Mark From Dmitri.Trembovetski at Sun.COM Mon Dec 22 10:06:45 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 22 Dec 2008 10:06:45 -0800 Subject: lcms and pisces quality [was: Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9] In-Reply-To: <1229858811.3443.14.camel@dijkstra.wildebeest.org> References: <490938A9.9050201@sun.com> <1ccfd1c10812190052g1afb570cr6bfbd069bdfdd1d2@mail.gmail.com> <494B87D4.6070700@redhat.com> <1ccfd1c10812190941t681bc817j24366e20b80fad8c@mail.gmail.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> <494C43CB.6050203@Sun.COM> <1229858811.3443.14.camel@dijkstra.wildebeest.org> Message-ID: <494FD735.5040504@Sun.COM> Hi Mark, Mark Wielaard wrote: > Hi Dmitri, > > On Fri, 2008-12-19 at 17:00 -0800, Dmitri Trembovetski wrote: >> Mark Wielaard wrote: >>> On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: >>>> The JDK7 early access binary snapshot builds are built from the >>>> OpenJDK7 sources, plus additional files and repositories we either >>>> cannot or haven't opened up yet (for various reasons). >>> Do you have a list of these additional files and repositories? Is there >>> anything for which there still isn't a free replacement available? >> For some of these free replacements are available in the openjdk >> tree, but they aren't yet of satisfactory quality (like the >> antialiasing rasterizer) > > Do you have a list of quality improvements (or maybe test cases) that > are needed for these components? Do you know if someone is already > working on those improvements? The engineers who integrated lcms and pisces rendering library may pitch in (they're cc-ed), I know of a few bugs for lcms: http://bugs.sun.com/view_bug.do?bug_id=6523398 http://bugs.sun.com/view_bug.do?bug_id=6523402 I believe there are some performance issues as well but I couldn't find the bug ids. Also, I know that pisces has some quality issues especially with large coordinate handling. Performance as well but I couldn't find any filed bugs. Thanks, Dmitri From gnu_andrew at member.fsf.org Mon Dec 22 10:35:09 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 22 Dec 2008 18:35:09 +0000 Subject: lcms and pisces quality [was: Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9] In-Reply-To: <494FD735.5040504@Sun.COM> References: <490938A9.9050201@sun.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> <494C43CB.6050203@Sun.COM> <1229858811.3443.14.camel@dijkstra.wildebeest.org> <494FD735.5040504@Sun.COM> Message-ID: <17c6771e0812221035j72857e24p5d7f3cbd999cf093@mail.gmail.com> 2008/12/22 Dmitri Trembovetski : > > Hi Mark, > > Mark Wielaard wrote: >> >> Hi Dmitri, >> >> On Fri, 2008-12-19 at 17:00 -0800, Dmitri Trembovetski wrote: >>> >>> Mark Wielaard wrote: >>>> >>>> On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: >>>>> >>>>> The JDK7 early access binary snapshot builds are built from the >>>>> OpenJDK7 sources, plus additional files and repositories we either >>>>> cannot or haven't opened up yet (for various reasons). >>>> >>>> Do you have a list of these additional files and repositories? Is there >>>> anything for which there still isn't a free replacement available? >>> >>> For some of these free replacements are available in the openjdk >>> tree, but they aren't yet of satisfactory quality (like the >>> antialiasing rasterizer) >> >> Do you have a list of quality improvements (or maybe test cases) that >> are needed for these components? Do you know if someone is already >> working on those improvements? > > The engineers who integrated lcms and pisces rendering library > may pitch in (they're cc-ed), I know of a few bugs for lcms: > http://bugs.sun.com/view_bug.do?bug_id=6523398 > http://bugs.sun.com/view_bug.do?bug_id=6523402 > > I believe there are some performance issues as well but I couldn't > find the bug ids. > > Also, I know that pisces has some quality issues especially > with large coordinate handling. Performance as well but I couldn't > find any filed bugs. > > Thanks, > Dmitri > 6523398 is fixed by Keith Seitz's patch in IcedTea (see the discussion on this recently on distro-pkg-dev; we need a more widespread fix so that the system lcms can be used). I think 6523402 has also been discussed in the past on the java2d mailing list. -- Andrew :-) 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 Dmitri.Trembovetski at Sun.COM Mon Dec 22 11:39:15 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 22 Dec 2008 11:39:15 -0800 Subject: lcms and pisces quality [was: Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9] In-Reply-To: <17c6771e0812221035j72857e24p5d7f3cbd999cf093@mail.gmail.com> References: <490938A9.9050201@sun.com> <494BE78F.1020405@redhat.com> <1ccfd1c10812191055lb78d440qb2c5a2263da04327@mail.gmail.com> <494BF86E.7000400@sun.com> <1229720511.3626.12.camel@hermans.wildebeest.org> <494C1E7D.9090308@sun.com> <1229727394.3626.35.camel@hermans.wildebeest.org> <494C43CB.6050203@Sun.COM> <1229858811.3443.14.camel@dijkstra.wildebeest.org> <494FD735.5040504@Sun.COM> <17c6771e0812221035j72857e24p5d7f3cbd999cf093@mail.gmail.com> Message-ID: <494FECE3.3070409@Sun.COM> Other pisces issues mentioned by Jim in http://bugs.sun.com/view_bug.do?bug_id=6610080 - Performance is not as good as the Ductus library - Fixed point is used with little or no overflow protection - No support for the STROKE_CONTROL hint Thanks, Dmitri Andrew John Hughes wrote: > 2008/12/22 Dmitri Trembovetski : >> Hi Mark, >> >> Mark Wielaard wrote: >>> Hi Dmitri, >>> >>> On Fri, 2008-12-19 at 17:00 -0800, Dmitri Trembovetski wrote: >>>> Mark Wielaard wrote: >>>>> On Fri, 2008-12-19 at 14:21 -0800, Kelly O'Hair wrote: >>>>>> The JDK7 early access binary snapshot builds are built from the >>>>>> OpenJDK7 sources, plus additional files and repositories we either >>>>>> cannot or haven't opened up yet (for various reasons). >>>>> Do you have a list of these additional files and repositories? Is there >>>>> anything for which there still isn't a free replacement available? >>>> For some of these free replacements are available in the openjdk >>>> tree, but they aren't yet of satisfactory quality (like the >>>> antialiasing rasterizer) >>> Do you have a list of quality improvements (or maybe test cases) that >>> are needed for these components? Do you know if someone is already >>> working on those improvements? >> The engineers who integrated lcms and pisces rendering library >> may pitch in (they're cc-ed), I know of a few bugs for lcms: >> http://bugs.sun.com/view_bug.do?bug_id=6523398 >> http://bugs.sun.com/view_bug.do?bug_id=6523402 >> >> I believe there are some performance issues as well but I couldn't >> find the bug ids. >> >> Also, I know that pisces has some quality issues especially >> with large coordinate handling. Performance as well but I couldn't >> find any filed bugs. >> >> Thanks, >> Dmitri >> > > 6523398 is fixed by Keith Seitz's patch in IcedTea (see the discussion > on this recently on distro-pkg-dev; we need a more widespread fix so > that the system lcms can be used). I think 6523402 has also been > discussed in the past on the java2d mailing list. From eng_tamerabdo at hotmail.com Tue Dec 30 08:22:31 2008 From: eng_tamerabdo at hotmail.com (tamer mohamed) Date: Tue, 30 Dec 2008 18:22:31 +0200 Subject: building the openjdk problem Message-ID: Dear Members; I downloaded the openJDK "openjdk-7-ea-src-b40-20_nov_2008.zip" then i added the compiler peoject "Javac" to the Netbeans IDE ver 6.5 (in Windows XP platform). - in the build.properties file i updated the "target.java.home" property to my JDK path. then when i tried to copile the project i got the following error : where Mypath is my Installed JDK path. Note : i installed the ''jdk-6u10-nb-6_5-windows-ml.exe' jdk version. The following is the sbapshot of the 'build.properties' file : ------------------------------------------------------The following is the build.properties-------------- # # Copyright 2007-2008 Sun Microsystems, Inc. All Rights Reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License version 2 only, as # published by the Free Software Foundation. Sun designates this # particular file as subject to the "Classpath" exception as provided # by Sun in the LICENSE file that accompanied this code. # # This code is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # version 2 for more details (a copy is included in the LICENSE file that # accompanied this code). # # You should have received a copy of the GNU General Public License version # 2 along with this work; if not, write to the Free Software Foundation, # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. # # Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, # CA 95054 USA or visit www.sun.com if you need additional information or # have any questions. # # This is the JDK used to build and run the bootstrap version of javac. # The bootstrap javac is used to compile both boostrap versions of the # other tools, and product versions of all the tools. # Override this path as needed, either on the command line or in # one of the standard user build.properties files (see build.xml) boot.java.home = "C:\\Program Files\\Java\\jdk1.6.0_10" boot.java = ${boot.java.home}\\bin\\java boot.javac = ${boot.java.home}\\bin\\javac boot.javac.target = 5 # This is the JDK used to run the product version of the tools, # for example, for testing. If you're building a complete JDK, specify that. # Override this path as needed, either on the command line or in # one of the standard user build.properties files (see build.xml) target.java.home = "C:\\Program Files\\Java\\jdk1.6.0_10" target.java = ${target.java.home}\\bin\\java bootstrap.jdk="C:\\Program Files\\Java\\jdk1.6.0_10" # Version info -- override as needed jdk.version = 1.7.0 build.number = b00 milestone = internal # FIXME -- these need to match the standard values # If we include date in full.version (ie for developer build) # we will need to make sure the build is idempotent (i.e. # repeated builds don't rebuild the tools, because of new # timestamps # FIXME -- need to include openjdk as needed release = ${jdk.version}-${milestone} bootstrap.release = ${release}_bootstrap full.version = ${release}-${build.number} bootstrap.full.version = ${bootstrap.release}-${build.number} # options for the tasks used to compile the tools javac.target = 6 javac.debug = true javac.debuglevel = source,lines javac.no.jdk.warnings = -XDignore.symbol.file=true # set the following to -version to verify the versions of javac being used javac.version.opt = # in time, there should be no exceptions to -Xlint:all javac.lint.opts = -Xlint:all,-deprecation,-fallthrough,-serial,-unchecked,-cast,-rawtypes # options for the task for javac javadoc.jls3.url=http://java.sun.com/docs/books/jls/ javadoc.jls3.cite=<a href="${javadoc.jls3.url}">The Java Language Specification, Third Edition</a> javadoc.jls3.option=-tag "jls3:a:See <cite>${javadoc.jls3.cite}</cite>:" # jtreg, used to run the JDK regression tests # Override this path as needed, either on the command line or in # one of the standard user build.properties files (see build.xml) # jtreg.home = /opt/jtreg/3.2.2_02 # findbugs # Override this path as needed, either on the command line or in # one of the standard user build.properties files (see build.xml) # findbugs.home = /opt/findbugs/1.2.1 #------------------------------------------------------------ # The following properties define the packages for each of the tools. # Syntactically, they should be suitable as arguments for the "includes" # parameter of Ant filesets. In particular, note the trailing '/'. javac.includes = \ javax/annotation/processing/ \ javax/lang/model/ \ javax/tools/ \ com/sun/source/ com/sun/tools/javac/ javac.tests = \ tools/javac javadoc.includes = \ com/sun/javadoc/ \ com/sun/tools/javadoc/ javadoc.tests = \ tools/javadoc/ doclets.includes = \ com/sun/tools/doclets/ doclets.tests = \ com/sun/javadoc/ javah.includes = \ com/sun/tools/javah/ javah.tests = \ tools/javah/ javap.includes = \ com/sun/tools/classfile/ \ com/sun/tools/javap/ \ sun/tools/javap/ javap.tests = \ tools/javap/ apt.includes = \ com/sun/mirror/ \ com/sun/tools/apt/ apt.tests = \ tools/apt/ ------------------------------------------------------------------------------------------------------ please tell me if i missed anything. and i am waiting for your advice. thank you in advance Tamer Mohamed Abd El-lateef Software Team Leader _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20081230/b6f0b7b2/attachment.html