From dfabulich at warpmail.net Wed May 9 06:27:46 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Tue, 8 May 2007 23:27:46 -0700 (Pacific Daylight Time) Subject: Missing t2k.lib, critical bug in Windows binary plugs Message-ID: I'm sad to announce that today's buildable JDK does not build successfully on Windows, because the binary plugs are missing "t2k.lib", part of the graphics rasterizer. Specifically, when you run "make sanity", you'll see this error message: ERROR: Can't locate t2k import library. Please check your access to /c/devtools/jdk-7-binary-plugs/jre/bin/t2k.lib and/or check your value of ALT_CLOSED_LIB_DIR. That file is indeed missing from the Windows binary plugs. We have a t2k.dll, t2k.pdb, and t2k.map, but no t2k.lib. At JavaOne today Dmitri confirmed that this was a real issue. I've filed a bug on bugs.sun.com, (though I was not assigned a bug number so I can't quote it here). Dmitri also suggested a workaround, which I'm not too excited about but which would probably work: you could, if you wanted, go get the JRL JDK 7, accept the JRL, and build a t2k.lib from *that* source. I'm concerned about my contaminating the new GPL'd Java by doing that, so I think I don't want to do that. Instead, someone at Sun should probably release another version of the binary plugs archive with the necessary file(s) included. Thanks! -Dan Fabulich From Tim.Bell at Sun.COM Wed May 9 07:25:46 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 09 May 2007 00:25:46 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: References: Message-ID: <4641777A.8020508@sun.com> Dan Fabulich wrote: > > I'm sad to announce that today's buildable JDK does not build > successfully on Windows, because the binary plugs are missing "t2k.lib", > part of the graphics rasterizer. I filed bug-ID 6555215 based on this email message. I couldn't get to your bugs.sun.com report due to internal network problems. Report 6555215 should be visible on bugs.sun.com in one or two working days. When the time comes (not now), it will be visible here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 Thanks- Tim From Phil.Race at Sun.COM Wed May 9 07:36:33 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 00:36:33 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: <4641777A.8020508@sun.com> References: <4641777A.8020508@sun.com> Message-ID: <46417A01.8040105@sun.com> copying from openjdk-discuss .. I am now on the build list, Dan Fabulich wrote: > > As I just pointed out on the build-dev list, the buildable JDK doesn't > build on Windows (missing t2k.lib). It wasn't overlooked. I'm not on that build alias but the need for t2k.lib complicated matters as the binary builds used as the source of the plugs don't contain these. If you look for the make-closed-binaries target you'll see it builds a directory 'closed' which contains just the binary plug pieces. Rather than using that and having to put that out, the decision was made to use the full builds so we didn't have to add another download and complication. The tradeoff is windows doesn't build but that will be addressed by removing the dependency on t2k . -phil. Tim Bell wrote: > Dan Fabulich wrote: >> >> I'm sad to announce that today's buildable JDK does not build >> successfully on Windows, because the binary plugs are missing >> "t2k.lib", part of the graphics rasterizer. > > I filed bug-ID 6555215 based on this email message. I couldn't get to > your > bugs.sun.com report due to internal network problems. > > Report 6555215 should be visible on bugs.sun.com in one or two working > days. > > When the time comes (not now), it will be visible here: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 > > Thanks- Tim From Phil.Race at Sun.COM Wed May 9 13:59:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 06:59:52 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.46816.842265.565325@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> Message-ID: <4641D3D8.8080401@sun.com> This very probably should be sent to the build-dev list instead but .. Andrew Haley wrote: > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > apparently no problems. Changes to jdk_generic_profile.sh control > were needed as below: > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > @@ -109,8 +109,12 @@ > fi > export COMPUTERNAME > > +unset LD_LIBRARY_PATH > We generally consider any shell setting of LD_LIBRARY_PATH to be evil I don't mean JDK I mean much more generally than that Having said that I haven't heard of it causing build problems before. What is the problem it caused you? +export LANG=C I think Kelly mentioned some problems in some locales .. is that what this is for? > + > # Boot jdk > -bootjdk=jdk1.6.0 > +bootjdk=jdk1.6.0_01 > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > these are intended to be changed/set via envt variables passed to make -phil. > importjdk=jdk1.7.0 > > # Uses 'uname -s', but only expect SunOS or Linux, assume Windows otherwise. > @@ -155,7 +159,7 @@ > elif [ "${osname}" = Linux ] ; then > > # System place where JDK installed images are stored? > - jdk_instances=/opt/java > + jdk_instances=/usr/java > > # Use compilers from /usr/bin > path4sdk=/usr/bin:/bin:/usr/sbin:/sbin > > Installed packages to satisfy the build requirements were: > > jdk-1.6.0_01-fcs > cups-libs.x86_64 1:1.2.10-3.fc6 > cups.x86_64 1:1.2.10-3.fc6 > gnutls-devel.x86_64 1.4.1-2 > cups-devel.i386 1:1.2.10-3.fc6 > cups-devel.x86_64 1:1.2.10-3.fc6 > libXp.i386 1.0.0-8 > libXp-devel.i386 1.0.0-8 > libXp-devel.x86_64 1.0.0-8 > > Andrew. > > From flameeyes at gmail.com Wed May 9 15:42:27 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Wed, 9 May 2007 17:42:27 +0200 Subject: Mix of CFLAGS and CXXFLAGS Message-ID: <20070509174227.7ed3f668@enterprise.flameeyes.is-a-geek.org> (I've submitted this on bugs.sun.com originally, not sure how to report the problem, but probably here is more appropriate.) I've been trying to build OpenJDK with Gentoo's ebuild, and I found a little flaw in the hotspot build system. My CFLAGS and CXXFLAGS variables are set in different ways, as I usually want to enable a few more warnings on C code; this causes the build process to spit these warnings: [exec] cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++ [exec] cc1plus: warning: command line option "-Wno-format-zero-length" is valid for C/ObjC but not for C++ The problem seems to be in openjdk/hotspot/build/linux/makefiles/rules.make: the rule to compile C++ source code uses CFLAGS exactly as the C source code compile. I've been working on a tentative patch (attached) that tries to make sure that CFLAGS and CXXFLAGS are differentiated, by moving the defines to CPPFLAGS, by adding the C++-only options only to CXXFLAGS, and by duplicating the flags that re common. Unfortunately as it is it doesn't work, as CPPFLAGS is reset and ignored, probably because of CPPFLAGS being set somewhere in the process, not sure where yet (I would have bet on vm.make, but changing that to += didn't help. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-cxxflags.patch Type: text/x-patch Size: 6317 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dfabulich at warpmail.net Wed May 9 16:03:49 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Wed, 9 May 2007 09:03:49 -0700 (Pacific Daylight Time) Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: <46417A01.8040105@sun.com> References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> Message-ID: Oops, I also posted on openjdk-discuss when I meant to post here: Phil Race wrote: > copying from openjdk-discuss .. I am now on the build list, > > > Dan Fabulich wrote: >> >> As I just pointed out on the build-dev list, the buildable JDK doesn't >> build on Windows (missing t2k.lib). > It wasn't overlooked. > I'm not on that build alias but the need for t2k.lib complicated matters > as the binary builds used as the source of the plugs don't contain > these. If you look for the make-closed-binaries target you'll see it > builds a directory 'closed' which contains just the binary plug pieces. > Rather than using that and having to put that out, the decision was made > to use the full builds so we didn't have to add another download and > complication. > > The tradeoff is windows doesn't build but that will be addressed by > removing the dependency on t2k . I'm not sure I quite understand that decision. Why provide binary plugs on Windows at all if we're not providing the binary files necessary to build the OpenJDK? It also sounds like this decision means that we don't intend to fix the Windows binary plugs, but simply wait until the binary plugs are no longer necessary. But replacing t2k could take months of hard effort. Wouldn't it be easier to release a new binary plug archive with the necessary files? Or even just to provide the necessary files as a separate download? I realize that this is more "complicated," but I think we all agree that it's better to have a complicated build that works than an uncomplicated build that doesn't work! :-) -Dan From Phil.Race at Sun.COM Wed May 9 16:09:24 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 09:09:24 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> Message-ID: <4641F234.6010401@sun.com> Dan Fabulich wrote: > Oops, I also posted on openj > It also sounds like this decision means that we don't intend to fix > the Windows binary plugs, but simply wait until the binary plugs are > no longer necessary. But replacing t2k could take months of hard > effort. Wouldn't it be easier to release a new binary plug archive > with the necessary files? Or even just to provide the necessary files > as a separate download? > > I realize that this is more "complicated," but I think we all agree > that it's better to have a complicated build that works than an > uncomplicated build that doesn't work! :-) > > replacing T2k will take months of hard effort but that is mostly behind us so its more like a few weeks of effort .. and some inevitable build cycle time lag. Time is the cruch matter. Getting these bits out has been tight And its more legally complicated too .. suppose we can't reship the binaries except as part of Java .. not sure of the answer to that but putting out the plug directory separately means more work for legal and that is a bigger bottleneck than might be apparent. -phil. From Kelly.Ohair at Sun.COM Wed May 9 16:57:52 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 09:57:52 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.64056.890139.107208@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> Message-ID: <4641FD90.2070208@sun.com> Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file makse sense, I'll take care of that. This .sh file is only for use when building the jdk, so it seems reasonable to change this file. The LANG setting is necessary to prevent builds from getting locked into the wrong locale, I forget the details, but builds with ja locale fail as I recall, and I decided that only C locale builds made sense. The LD_LIBRARY_PATH unset might be a problem for some, not for me, but in general you don't want stray libraries loaded from this PATH. The build should only rely on the libraries in /lib and /usr/lib. There have been numerous build failures in the past related to this. The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where the binary plugs got downloaded, so it depends on the builder. It was intended that this be manually set and specifically, it needs to be pointing at one of the Binary Plugs provided on the openjdk.java.net site. Legal issues involved here, e.g. great pains. :^( A builder could just add this one to their own ENV variables, or create a my_jdk_profile.sh file that just does: . j2se/make/jdk_generic_profile.sh export ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ Hope this helps. When JavaOne is over and I recover from all this openjsk mania, I'll get the LANG/LD_LIBRARY_PATH changes in. -kto Andrew Haley wrote: > Phil Race writes: > > This very probably should be sent to the build-dev list instead but .. > > > > > > Andrew Haley wrote: > > > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > > > apparently no problems. Changes to jdk_generic_profile.sh control > > > were needed as below: > > > > > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > > > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > > > @@ -109,8 +109,12 @@ > > > fi > > > export COMPUTERNAME > > > > > > +unset LD_LIBRARY_PATH > > > > > > > We generally consider any shell setting of LD_LIBRARY_PATH to be evil > > I don't mean JDK I mean much more generally than that > > Having said that I haven't heard of it causing build problems before. > > What is the problem it caused you? > > None at all, except that the sanity check whined about it. > > > +export LANG=C > > I think Kelly mentioned some problems in some locales .. is that what > > this is for? > > As above. > > > > + > > > # Boot jdk > > > -bootjdk=jdk1.6.0 > > > +bootjdk=jdk1.6.0_01 > > > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > > > > these are intended to be changed/set via envt variables passed to make > > Well, yes, but dk_generic_profile.sh sets those environment variables. > I'm presuming that you're not saying that there should be yet another > variable-setting script that should be run before running this script. > :-) > > Andrew. > From flameeyes at gmail.com Wed May 9 18:14:23 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Wed, 9 May 2007 20:14:23 +0200 Subject: Mix of CFLAGS and CXXFLAGS Message-ID: <20070509201423.0995ef6f@enterprise.flameeyes.is-a-geek.org> On Wed, 9 May 2007 17:42:27 +0200 Diego 'Flameeyes' Petten? wrote: > Unfortunately as it is it doesn't work, as CPPFLAGS is reset and > ignored, probably because of CPPFLAGS being set somewhere in the > process, not sure where yet (I would have bet on vm.make, but changing > that to += didn't help. I think I found the problem I didn't find last night: the output I was looking at was for adlc, so adlc.make was rewriting CPPFLAGS; I think I've fixed it now, and my CFLAGS and CXXFLAGS are respected; unfortunately this also means my extra warnings are enabled (-Wformat=2 in particular) and -Werror makes the build fail because of some non-literal format strings. But beside that, the build proceed (to stop later on as with vanilla openjdk). -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-cxxflags.patch Type: text/x-patch Size: 6504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-cxxflags.patch Type: text/x-patch Size: 7100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Wed May 9 16:43:36 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 17:43:36 +0100 Subject: Building on Fedora 6 In-Reply-To: <4641D3D8.8080401@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> Message-ID: <17985.64056.890139.107208@zebedee.pink> Phil Race writes: > This very probably should be sent to the build-dev list instead but .. > > > Andrew Haley wrote: > > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > > apparently no problems. Changes to jdk_generic_profile.sh control > > were needed as below: > > > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > > @@ -109,8 +109,12 @@ > > fi > > export COMPUTERNAME > > > > +unset LD_LIBRARY_PATH > > > > We generally consider any shell setting of LD_LIBRARY_PATH to be evil > I don't mean JDK I mean much more generally than that > Having said that I haven't heard of it causing build problems before. > What is the problem it caused you? None at all, except that the sanity check whined about it. > +export LANG=C > I think Kelly mentioned some problems in some locales .. is that what > this is for? As above. > > + > > # Boot jdk > > -bootjdk=jdk1.6.0 > > +bootjdk=jdk1.6.0_01 > > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > > these are intended to be changed/set via envt variables passed to make Well, yes, but dk_generic_profile.sh sets those environment variables. I'm presuming that you're not saying that there should be yet another variable-setting script that should be run before running this script. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Wed May 9 17:04:14 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 18:04:14 +0100 Subject: Building on Fedora 6 In-Reply-To: <4641FD90.2070208@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> Message-ID: <17985.65294.281233.214824@zebedee.pink> Kelly O'Hair writes: > Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file > makse sense, I'll take care of that. This .sh file is only for use when > building the jdk, so it seems reasonable to change this file. > > The LANG setting is necessary to prevent builds from getting locked > into the wrong locale, I forget the details, but builds with ja locale > fail as I recall, and I decided that only C locale builds made sense. > > The LD_LIBRARY_PATH unset might be a problem for some, not for me, but > in general you don't want stray libraries loaded from this PATH. > The build should only rely on the libraries in /lib and /usr/lib. > There have been numerous build failures in the past related to this. > > The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where > the binary plugs got downloaded, so it depends on the builder. > It was intended that this be manually set and specifically, it needs to be > pointing at one of the Binary Plugs provided on the openjdk.java.net site. > Legal issues involved here, e.g. great pains. :^( Which reminds me: is there any need for JDK 1.6 in all of this? The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of the "binary blobs" is a full JDK, is it not? So it could be used as the bootstrap JDK -- there's no need for JDK 1.6. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From flameeyes at gmail.com Wed May 9 18:49:34 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Wed, 9 May 2007 20:49:34 +0200 Subject: Build path has a 54/55 characters limit Message-ID: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> Another problem I've seen with OpenJDK build on Gentoo Linux AMD64 is with the limit of the path for the build directory. With a one on a million chance, the default path used by Portage (/var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk) to extract the sources and then to build, is long the exact limit for that path. On x86 the path is good enough to complete the build, but as on amd64 the name used to identify the build is "amd64", whereas on x86 is "i486", the single extra character there makes the build fail in a few calls to javac with "Argument list too long" error from execve(). If the path is longer, there are even more calls to fail. At first I thought it was an use case for xargs, but the problem comes from execve() so it might be just impossible to solve the issue as it is. Maybe the link stages might be split up in intermediate files? -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From neugens at limasoftware.net Wed May 9 19:04:53 2007 From: neugens at limasoftware.net (Mario Torre) Date: Wed, 09 May 2007 21:04:53 +0200 Subject: OpenJDK on Fedora Message-ID: <1178737493.46421b55c87e0@cp.tophost.it> Hello! I had some troubles building OpenJDK on Fedora, because it needs openmotif, while on fedora there is only lesstif available. This was not a problem with the build itself, but with the sanity check. I had to apply this patch in order to pass the sanity check on my system. The patch simply checks for the real included file in the awt code, I hope it is useful to everyone. Ciao, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: build.patch Type: text/x-patch Size: 661 bytes Desc: not available URL: From Kelly.Ohair at Sun.COM Wed May 9 19:06:22 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 12:06:22 -0700 Subject: Build path has a 54/55 characters limit In-Reply-To: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> References: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> Message-ID: <46421BAE.7040109@sun.com> Most javac compiles in the OpenJDK build use the @ option and the java filelists are in a separate file, so the command line length should not be a problem. And I've never seen it a problem on any Linux or Solaris system I've used, ever, just Windows has had this issue for me. Can you provide more details as to where these long javac compile lines are coming from? -kto Diego 'Flameeyes' Petten? wrote: > Another problem I've seen with OpenJDK build on Gentoo Linux AMD64 is > with the limit of the path for the build directory. > With a one on a million chance, the default path used by Portage > (/var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk) to > extract the sources and then to build, is long the exact limit for that > path. > On x86 the path is good enough to complete the build, but as on amd64 > the name used to identify the build is "amd64", whereas on x86 is > "i486", the single extra character there makes the build fail in a few > calls to javac with "Argument list too long" error from execve(). > If the path is longer, there are even more calls to fail. > > At first I thought it was an use case for xargs, but the problem comes > from execve() so it might be just impossible to solve the issue as it > is. Maybe the link stages might be split up in intermediate files? > From Da at m-01.th.seeweb.it Wed May 9 18:56:01 2007 From: Da at m-01.th.seeweb.it (Da at m-01.th.seeweb.it) Date: Wed, 09 May 2007 20:56:01 +0200 Subject: No subject Message-ID: <1178736961.46421941b09a2@cp.tophost.it> Hello! I had some troubles building OpenJDK on Fedora, because it needs openmotif, while on fedora there is only lesstif available. This was not a problem with the build itself, but with the sanity check. I had to apply this patch in order to pass the sanity check on my system. The patch simply checks for the real included file in the awt code, I hope it is useful to everyone. Ciao, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From betelgeuse at gentoo.org Wed May 9 19:12:24 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 09 May 2007 22:12:24 +0300 Subject: Build path has a 54/55 characters limit In-Reply-To: <46421BAE.7040109@sun.com> References: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> <46421BAE.7040109@sun.com> Message-ID: <46421D18.5010003@gentoo.org> Kelly O'Hair kirjoitti: > Most javac compiles in the OpenJDK build use the @ option and the java > filelists are in a separate file, so the command line length should > not be a problem. And I've never seen it a problem on any Linux > or Solaris system I've used, ever, just Windows has had this issue for me. > > Can you provide more details as to where these long javac compile lines > are coming from? > > -kto > [exec] make[6]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] /bin/sh: /bin/ls: Argument list too long [exec] make[6]: Entering directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] if [ -d /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/agent -a "i486" != "ia64" ] ; then \ [exec] make -f sa.make /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar; \ [exec] fi [exec] /bin/sh: /bin/ls: Argument list too long [exec] make[7]: Entering directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] if [ "/opt/sun-jdk-1.6.0" = "" ]; then \ [exec] echo "ALT_BOOTDIR, BOOTDIR or JAVA_HOME needs to be defined to build SA"; \ [exec] exit 1; \ [exec] fi [exec] echo "Making /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar" [exec] Making /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar [exec] if [ ! -d /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses ] ; then \ [exec] mkdir -p /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses; \ [exec] fi [exec] /opt/sun-jdk-1.6.0/bin/javac -source 1.4 -classpath /opt/sun-jdk-1.6.0/lib/tools.jar -g -d /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses [exec] javac: no source files [exec] Usage: javac [exec] use -help for a list of possible options [exec] make[7]: *** [/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar] Error 2 [exec] make[7]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] make[6]: *** [all] Error 2 [exec] make[6]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] make[5]: *** [sa_stuff] Error 2 [exec] make[5]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' [exec] make[4]: *** [product] Error 2 [exec] make[4]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir' [exec] make[3]: *** [generic_build2] Error 2 [exec] make[3]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/make' [exec] make[2]: *** [product] Error 2 [exec] make[2]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/make' [exec] make[1]: *** [hotspot-build] Error 2 [exec] make[1]: Leaving directory `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/make' [exec] make: *** [dev-build] Error 2 BUILD FAILED /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/j2se/make/netbeans/world/build.xml:37: The following error occurred while executing this line: /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/j2se/make/netbeans/common/make.xml:61: exec returned: 2 Regards, Petteri -- Gentoo/Java Project lead -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From flameeyes at gmail.com Wed May 9 19:15:25 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Wed, 9 May 2007 21:15:25 +0200 Subject: Build path has a 54/55 characters limit In-Reply-To: <46421BAE.7040109@sun.com> References: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> <46421BAE.7040109@sun.com> Message-ID: <20070509211525.695a3a7a@enterprise.flameeyes.is-a-geek.org> On Wed, 09 May 2007 12:06:22 -0700 "Kelly O'Hair" wrote: > Can you provide more details as to where these long javac compile > lines are coming from? One failure comes before this (passing the call is a big difficult considering the size): [exec] execve(): Argument list too long [exec] Error trying to exec /opt/sun-jdk-1.7.0.0_alpha12/bin/javac. [exec] Check if file exists and permissions are set correctly. [exec] make[7]: *** [/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/hotspot/outputdir/linux_amd64_compil er2/product/../generated/sa-jdi.jar] Error 1 [exec] make[7]: Leaving directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/hotspot/outputdir/linu x_amd64_compiler2/product' [exec] make[6]: *** [all] Error 2 This is just one though, there are a few others long calls that I can see while proceeding the build (after changing /var/tmp/portage with /var/tmp/portag, one less character, and all is fine), and if the base path is even longer (like adding one more "portage/portage" to the path), there are failures on calling /bin/ls too. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Kelly.Ohair at Sun.COM Wed May 9 22:41:18 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 15:41:18 -0700 Subject: Build path has a 54/55 characters limit In-Reply-To: <46421D18.5010003@gentoo.org> References: <20070509204934.34a7a180@enterprise.flameeyes.is-a-geek.org> <46421BAE.7040109@sun.com> <46421D18.5010003@gentoo.org> Message-ID: <46424E0E.5030809@sun.com> Ah... javac compiles from the Hotspot build. I'll file a bug on this. The Hotspot makefiles are completely independent from the j2se makefiles, for better or worse. I'll make sure this gets fixed. Thanks for the details. -kto Petteri R?ty wrote: > Kelly O'Hair kirjoitti: >> Most javac compiles in the OpenJDK build use the @ option and the java >> filelists are in a separate file, so the command line length should >> not be a problem. And I've never seen it a problem on any Linux >> or Solaris system I've used, ever, just Windows has had this issue for me. >> >> Can you provide more details as to where these long javac compile lines >> are coming from? >> >> -kto >> > > [exec] make[6]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] /bin/sh: /bin/ls: Argument list too long > [exec] make[6]: Entering directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] if [ -d > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/agent > -a "i486" != "ia64" ] ; then \ > [exec] make -f sa.make > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar; > \ > [exec] fi > [exec] /bin/sh: /bin/ls: Argument list too long > [exec] make[7]: Entering directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] if [ "/opt/sun-jdk-1.6.0" = "" ]; then \ > [exec] echo "ALT_BOOTDIR, BOOTDIR or JAVA_HOME needs to be > defined to build SA"; \ > [exec] exit 1; \ > [exec] fi > [exec] echo "Making > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar" > [exec] Making > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar > [exec] if [ ! -d > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses > ] ; then \ > [exec] mkdir -p > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses; > \ > [exec] fi > [exec] /opt/sun-jdk-1.6.0/bin/javac -source 1.4 -classpath > /opt/sun-jdk-1.6.0/lib/tools.jar -g -d > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/saclasses > [exec] javac: no source files > [exec] Usage: javac > [exec] use -help for a list of possible options > [exec] make[7]: *** > [/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/../generated/sa-jdi.jar] > Error 2 > [exec] make[7]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] make[6]: *** [all] Error 2 > [exec] make[6]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] make[5]: *** [sa_stuff] Error 2 > [exec] make[5]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product' > [exec] make[4]: *** [product] Error 2 > [exec] make[4]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/build/linux-i586/hotspot/outputdir' > [exec] make[3]: *** [generic_build2] Error 2 > [exec] make[3]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/make' > [exec] make[2]: *** [product] Error 2 > [exec] make[2]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/hotspot/make' > [exec] make[1]: *** [hotspot-build] Error 2 > [exec] make[1]: Leaving directory > `/mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/control/make' > [exec] make: *** [dev-build] Error 2 > > BUILD FAILED > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/j2se/make/netbeans/world/build.xml:37: > The following error occurred while executing this line: > /mnt/checkouts/foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar/openjdk-trunk/j2se/make/netbeans/common/make.xml:61: > exec returned: 2 > > Regards, > Petteri > -- > Gentoo/Java Project lead > From dfabulich at warpmail.net Wed May 9 22:51:14 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Wed, 9 May 2007 15:51:14 -0700 (Pacific Daylight Time) Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: <4641F234.6010401@sun.com> References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> <4641F234.6010401@sun.com> Message-ID: Phil Race wrote: > replacing T2k will take months of hard effort but that is mostly behind us so > its more like a few weeks > of effort .. and some inevitable build cycle time lag. Naturally, I have no idea how far we are along with replacing T2K with unencumbered code. I assume that Sun developers are working on that in the Sun proprietary source control system, since the public OpenJDK svn is read-only, even to Sun developers, right? If that's so, am I right in thinking that developers from the community (such as myself) won't be able to build a Windows OpenJDK until June, at the earliest? If THAT'S so, could we perhaps at least make that clearer on the openjdk.java.net website? If we're as close as you say we are to eliminating T2K encumberances, maybe we should just withdraw the Windows binary plugs from the website altogether ... it's not like anyone can use them until this issue gets resolved. Maybe update the source bundle so that the Windows documentation is clearly deprecated. ("THIS DOES NOT WORK YET.") Or modify "make sanity" to print out an apology instead of an error message when running on Windows. :-) > And its more legally complicated too .. suppose we can't reship the > binaries except as part of Java .. not sure of the answer to that but > putting out the plug directory separately means more work for legal and > that is a bigger bottleneck than might be apparent. It's surprising to me that t2k.dll, t2k.pdb, and t2k.map can all ship in the binary plugs, but adding t2k.lib would be a big legal hassle. Of course, I'm not a lawyer, but it would certainly be nice if we could get somebody in legal to confirm this, since, as far as I can tell, we're just one file away from success. :-( -Dan From Kelly.Ohair at Sun.COM Wed May 9 23:11:20 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 16:11:20 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.65294.281233.214824@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> Message-ID: <46425518.6020900@sun.com> Andrew Haley wrote: > Kelly O'Hair writes: > > Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file > > makse sense, I'll take care of that. This .sh file is only for use when > > building the jdk, so it seems reasonable to change this file. > > > > The LANG setting is necessary to prevent builds from getting locked > > into the wrong locale, I forget the details, but builds with ja locale > > fail as I recall, and I decided that only C locale builds made sense. > > > > The LD_LIBRARY_PATH unset might be a problem for some, not for me, but > > in general you don't want stray libraries loaded from this PATH. > > The build should only rely on the libraries in /lib and /usr/lib. > > There have been numerous build failures in the past related to this. > > > > The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where > > the binary plugs got downloaded, so it depends on the builder. > > It was intended that this be manually set and specifically, it needs to be > > pointing at one of the Binary Plugs provided on the openjdk.java.net site. > > Legal issues involved here, e.g. great pains. :^( > > Which reminds me: is there any need for JDK 1.6 in all of this? The > openjdk-7-ea-src-b12-06_may_2007.zip used as the source of the "binary > blobs" is a full JDK, is it not? So it could be used as the bootstrap > JDK -- there's no need for JDK 1.6. > Officially, we boot from the previous FCS jdk (1.6.0), unofficially, jdk 1.5 or jdk 1.7 would work as a boot jdk. I suppose it may become an issue later if we somehow become dependent on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any issue like that on the horizon. A jdk 1.5 might be already available on your system. Using a boot of jdk 1.7 may have some risks, but should in general work. Note that the "binary plugs" are indeed full jdk 7 images right now, but none of the files will have execute permissions. The binary plugs are distributed with a different license that allows their use as 'binary plugs'. I'd probably keep the binary plugs separate from the boot jdk, but that's just me. Also the binary plugs will need to be updated every time you freshen up your openjdk sources, the boot jdk is a pretty static thing. -kto > Andrew. > From Kelly.Ohair at Sun.COM Wed May 9 23:16:21 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 16:16:21 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.47222.767406.158499@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.42893.809665.95128@zebedee.pink> <17985.47222.767406.158499@zebedee.pink> Message-ID: <46425645.1020506@sun.com> 'make -j' is not recommended. The makefile dependencies cannot be trusted to be 100% accurate. -kto Andrew Haley wrote: > It's worth mentioning somewhere in the instructions that "make -j" > doesn't work when building openjdk. The actual parallelism is > supposed to be controlled by HOTSPOT_BUILD_JOBS, but it doesn't seem > to be very effective. On a dual-processor box with > HOTSPOT_BUILD_JOBS=4 I get: > > Control build finished: 07-05-09 13:00 > 1729.91user 166.63system 23:53.03elapsed 132%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (1002major+40812683minor)pagefaults 0swaps > > which is not bad, but it would be nice to increase the parallalism. > > Andrew. > From Phil.Race at Sun.COM Thu May 10 00:23:50 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 17:23:50 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> <4641F234.6010401@sun.com> Message-ID: <46426616.9040609@sun.com> Dan Fabulich wrote: > Phil Race wrote: > >> replacing T2k will take months of hard effort but that is mostly >> behind us so its more like a few weeks >> of effort .. and some inevitable build cycle time lag. > > Naturally, I have no idea how far we are along with replacing T2K with > unencumbered code. I assume that Sun developers are working on that > in the Sun proprietary source control system, since the public OpenJDK > svn is read-only, even to Sun developers, right? Actually the 2D openjdk component page documents the status of this work. > > If that's so, am I right in thinking that developers from the > community (such as myself) won't be able to build a Windows OpenJDK > until June, at the earliest? With the current approach, that's a fair estimate. >> And its more legally complicated too .. suppose we can't reship the >> binaries except as part of Java .. not sure of the answer to that but >> putting out the plug directory separately means more work for legal >> and that is a bigger bottleneck than might be apparent. > > It's surprising to me that t2k.dll, t2k.pdb, and t2k.map can all ship > in the binary plugs, but adding t2k.lib would be a big legal hassle. That it was mentioned as a possibility but we don't ship any .lib files there so I think it would be an oddity. I meant shipping a 'zip' of the directory 'closed' built by the closed-binaries-dir as another download bundle. In other words the code to make a buildable windows JDK was done, its just that the bits aren't built and shipped. So this isn't an engineering/bug type issue .. its more a matter of as you say documenting it, or getting it resolved that another bundle can be shipped or cleared. -phil From dfabulich at warpmail.net Thu May 10 04:52:47 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Wed, 9 May 2007 21:52:47 -0700 (Pacific Daylight Time) Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: <46426616.9040609@sun.com> References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> <4641F234.6010401@sun.com> <46426616.9040609@sun.com> Message-ID: Phil Race wrote: > Dan Fabulich wrote: >> >> Naturally, I have no idea how far we are along with replacing T2K with >> unencumbered code. I assume that Sun developers are working on that in the >> Sun proprietary source control system, since the public OpenJDK svn is >> read-only, even to Sun developers, right? > > Actually the 2D openjdk component page documents the status of this work. Right, but I can't see what you're up to in the source code, can I? Even if someone at Sun swapped out t2k for freetype tomorrow, I wouldn't be able to build on Windows until I got a source drop. How/when would that happen? Maybe this is a better conversation for the "discuss" list... -Dan From Phil.Race at Sun.COM Thu May 10 05:03:47 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 22:03:47 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> <4641F234.6010401@sun.com> <46426616.9040609@sun.com> Message-ID: <4642A7B3.3050205@sun.com> If you are interested in the specifics of the freetype work then the best list is actually font-scaler-dev -phil. Dan Fabulich wrote: > Phil Race wrote: > >> Dan Fabulich wrote: >>> >>> Naturally, I have no idea how far we are along with replacing T2K >>> with unencumbered code. I assume that Sun developers are working on >>> that in the Sun proprietary source control system, since the public >>> OpenJDK svn is read-only, even to Sun developers, right? >> >> Actually the 2D openjdk component page documents the status of this >> work. > > Right, but I can't see what you're up to in the source code, can I? > Even if someone at Sun swapped out t2k for freetype tomorrow, I > wouldn't be able to build on Windows until I got a source drop. > How/when would that happen? Maybe this is a better conversation for > the "discuss" list... > > -Dan From aph at redhat.com Thu May 10 11:05:55 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 May 2007 12:05:55 +0100 Subject: Building on Fedora 6 In-Reply-To: <46425518.6020900@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> Message-ID: <17986.64659.451226.280513@zebedee.pink> Kelly O'Hair writes: > Andrew Haley wrote: > > Which reminds me: is there any need for JDK 1.6 in all of this? > > The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of > > the "binary blobs" is a full JDK, is it not? So it could be used > > as the bootstrap JDK -- there's no need for JDK 1.6. > > > > Officially, we boot from the previous FCS jdk (1.6.0), unofficially, > jdk 1.5 or jdk 1.7 would work as a boot jdk. > I suppose it may become an issue later if we somehow become dependent > on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any > issue like that on the horizon. A jdk 1.5 might be already available > on your system. > > Using a boot of jdk 1.7 may have some risks, but should in general > work. > Note that the "binary plugs" are indeed full jdk 7 images right now, > but none of the files will have execute permissions. OK, so I had to chmod -R +x /home/aph/openjdk/jdk1.7.0//bin > The binary plugs are distributed with a different license that allows > their use as 'binary plugs'. I'd probably keep the binary plugs > separate from the boot jdk, but that's just me. > Also the binary plugs will need to be updated every time you freshen > up your openjdk sources, the boot jdk is a pretty static thing. OK. Anyway, this works Just Fine. It's only necessary for developers on GNU/Linux to download jdk-7-ea-plug-b12-linux-amd64-06_may_2007.jar and openjdk-7-ea-src-b12-06_may_2007.zip: gcj is quite capable of running the self-extracting Jar file. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Phil.Race at Sun.COM Thu May 10 13:55:44 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 10 May 2007 06:55:44 -0700 Subject: Missing t2k.lib, critical bug in Windows binary plugs In-Reply-To: References: <4641777A.8020508@sun.com> <46417A01.8040105@sun.com> Message-ID: <46432460.6020104@sun.com> Dan Fabulich wrote: > Oops, I also posted on openjdk-discuss when I meant t > I'm not sure I quite understand that decision. Why provide binary > plugs on Windows at all if we're not providing the binary files > necessary to build the OpenJDK? It just dawned on me (some of) what you are on about. Until I started reading later emails I had no idea we were putting out .jars of the whole JRE as binary plugs rather than pointing to the regular executables. The idea we'd has for months as far as I know is that it would be just the regular binary snapshots, hence no extra download bundle. I guess its the legal mumbo jumbo again but in that case it was truly wrong to put out the jars for windows. They should simply be withdrawn as they just make it look like it'll work when it won't. Or put out the closed.jar files containing 'just' the plugs for all platforms but that most likely is the legal mumbo jumbo problem., -phil. From flameeyes at gmail.com Fri May 11 01:12:39 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 03:12:39 +0200 Subject: [PATCH] Fix building of j2se with OTHER_CXXFLAGS set in environment Message-ID: <20070511031239.36c31658@enterprise.flameeyes.is-a-geek.org> When OTHER_CXXFLAGS is set in environment, as seems to be suggested in the makefiles to set extra CFLAGS/CXXFLAGS, the build fails with this error: [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /unpack.o: In function `unpacker::redirect_stdio()': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/unpack.cpp:4665: warning: the use of `tempnam' is dangerous, better use `mkstemp' [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /main.o: In function `setup_gzin': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/main.cpp:129: undefined reference to `gunzip::init(unpacker*)' [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /main.o: In function `unpacker::run(int, char**)': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/main.cpp:377: undefined reference to `gunzip::start(int)' [exec] collect2: ld returned 1 exit status [exec] make[7]: *** [/var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/bin/unpack200] Error 1 The problem is that -DNO_ZLIB is set on a first pass, where STANDALONE=yes is used on the make call; with OTHER_CXXFLAGS being an environment variable, the value is not removed when getting out of that pass, and is kept over during unpack200 build. The attached patch uses CXXFLAGS_COMMON instead, and allows the build to complete safely when setting the the value in environment. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From flameeyes at gmail.com Fri May 11 01:14:06 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 03:14:06 +0200 Subject: [PATCH] Fix building of j2se with OTHER_CXXFLAGS set in environment Message-ID: <20070511031406.22893e92@enterprise.flameeyes.is-a-geek.org> When OTHER_CXXFLAGS is set in environment, as seems to be suggested in the makefiles to set extra CFLAGS/CXXFLAGS, the build fails with this error: [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /unpack.o: In function `unpacker::redirect_stdio()': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/unpack.cpp:4665: warning: the use of `tempnam' is dangerous, better use `mkstemp' [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /main.o: In function `setup_gzin': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/main.cpp:129: undefined reference to `gunzip::init(unpacker*)' [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64 /main.o: In function `unpacker::run(int, char**)': [exec] /var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/j2se/make/com/sun/java/pack/../../../../../src/share/native/com/sun/java/util /jar/pack/main.cpp:377: undefined reference to `gunzip::start(int)' [exec] collect2: ld returned 1 exit status [exec] make[7]: *** [/var/tmp/portag/dev-java/openjdk-1.7.0.0_alpha12/work/openjdk/control/build/linux-amd64/bin/unpack200] Error 1 The problem is that -DNO_ZLIB is set on a first pass, where STANDALONE=yes is used on the make call; with OTHER_CXXFLAGS being an environment variable, the value is not removed when getting out of that pass, and is kept over during unpack200 build. The attached patch uses CXXFLAGS_COMMON instead, and allows the build to complete safely when setting the the value in environment. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-j2se-cxxflags.patch Type: text/x-patch Size: 459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.schaefer at madplanet.com Fri May 11 04:00:34 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Thu, 10 May 2007 21:00:34 -0700 Subject: OpenJDK Build on OpenSuSE 10.2 Message-ID: <4643EA62.5030401@madplanet.com> Hi Geeks I just managed to build OpenJDK on OpenSuSE 10.2 and here are the steps to accomplish that; - Install JDK 1.6 downloaded from Sun's website - Install Alsa and Cups Devel RPM from the distro - Download and force the installation of Lesstif Devel (0.9.5) RPM downloaded from the lesstiff website (force because we do not need lesstif only the headers) - Create a an empty file called AccColorT.h inside /usr/X11R6/include/Xm because Gmake is testing for that file even though it is not needed - set ALT_MOTIF_DIR=/usr/X11R6 - build it Have fun - Andy From flameeyes at gmail.com Fri May 11 05:39:39 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 07:39:39 +0200 Subject: [PATCH] Allow usage of external zlib copy Message-ID: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> Most distributions have policies about using external copies of libraries whenever possible. OpenJDK ships with a series of libraries that are usually available on a system, like zlib and jpeg, thus breaking such a policy. The attached patch tries to correct part of this by letting use of external zlib copy when passing EXTERNAL_ZLIB=true at the make process. I'm also gonna work on a similar patch to use external jpeg library (that will likely depend on this one because of some of the files touched being the same). -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-zlib.patch Type: text/x-patch Size: 6020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From neugens at limasoftware.net Fri May 11 07:24:31 2007 From: neugens at limasoftware.net (Mario Torre) Date: Fri, 11 May 2007 09:24:31 +0200 Subject: OpenJDK Build on OpenSuSE 10.2 Message-ID: <1178868271.46441a2f92250@cp.tophost.it> Il giorno gio, 10/05/2007 alle 21.00 -0700, Andreas Schaefer ha scritto: > Hi Geeks > - Create a an empty file called AccColorT.h inside /usr/X11R6/include/Xm > because Gmake is testing for that file even though it is not needed You don't need this step, just apply this patch and everything is fine :) http://mail.openjdk.java.net/pipermail/discuss/2007-May/000018.html Is there a way for that to be discussed and maybe included in the OpenJDK distribution? I doubt there is need to sign the Contributor Agreement because it is a one line patch, but indeed, I will be happy to do everything needed to make that easy. Hope that helps, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aph at redhat.com Fri May 11 11:34:57 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 May 2007 12:34:57 +0100 Subject: Building on Fedora 6 In-Reply-To: References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> <17986.64659.451226.280513@zebedee.pink> Message-ID: <17988.21729.292266.844427@zebedee.pink> Max (Weijun) Wang writes: > My 2 cents: > > It's called "binary plugs", which means it's used to provide binaries > for those components whose sources are not included in the OpenJDK > yet. So, even today it looks like a full JDK, tomorrow you may see it > includes only several jars and native libraries, and then one day, it > will disappear completely. Sure, but it's just a way to solve the bootstrapping problem: once you've built a working JDK, you're not going to need the "binary plugs" any more. I'm talking about free software developers' needs over the next week or two. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Phil.Race at Sun.COM Fri May 11 15:40:54 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 08:40:54 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> Message-ID: <46448E86.8000308@sun.com> Diego 'Flameeyes' Petten? wrote: > Most distributions have policies about using external copies of > libraries whenever possible. OpenJDK ships with a series of libraries > that are usually available on a system, like zlib and jpeg, thus > breaking such a policy. > > The attached patch tries to correct part of this by letting use of > external zlib copy when passing EXTERNAL_ZLIB=true at the make process. > > I'm also gonna work on a similar patch to use external jpeg library > (that will likely depend on this one because of some of the files > touched being the same). > The JDK's libjpeg is not the standard IJG one. It has additional stuff in it and exposes only the symbols needed by the JDK. So in no way is it interchangeable. -phil. From flameeyes at gmail.com Fri May 11 17:39:13 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 19:39:13 +0200 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <46448E86.8000308@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> Message-ID: <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> On Fri, 11 May 2007 08:40:54 -0700 Phil Race wrote: > The JDK's libjpeg is not the standard IJG one. It has additional > stuff in it and exposes only the > symbols needed by the JDK. So in no way is it interchangeable. This might be a problem. The exposure of symbols shouldn't be a problem on its own (used as a shared library, the symbols exported are generic enough); the additional stuff instead can be a problem indeed. I can't seem to find a detail of what the changes are, but I can tell that using the jpeg library in Gentoo let OpenJDK build fine at least. I haven't sent any patch yet because I have to find a way to test it out first. (zlib was easier). Note that also Gentoo's jpeg is not totally vanilla, it contains a few patches coming from Debian, and a security fix to keep a large allocation of memory from killing the system. If the additional stuff might be of help, and wouldn't break software written with vanilla jpeg in mind, it might as well be possible to backport those changes in Gentoo's jpeg library. As far as I can see a good deal of the changes replaces the symbol main with _main, the functional changes are at a minimum, I see a change in the way EQTs are emitted, and an error downgraded to warning, and a change in INT32 definition. I see some sprintf() calls changed to jio_snprintf() too. After all, it doesn't seem like a difficult task to get the external jpeg library to work fine with OpenJDK. I've seen there are also copies of libpng and giflib, are those modified in some way, too? I'm now running a build with those used external too. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Phil.Race at Sun.COM Fri May 11 17:54:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 10:54:52 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> Message-ID: <4644ADEC.4090405@sun.com> Diego 'Flameeyes' Petten? wrote: > On Fri, 11 May 2007 08:40:54 -0700 > Phil Race wrote: > > >> The JDK's libjpeg is not the standard IJG one. It has additional >> stuff in it and exposes only the >> symbols needed by the JDK. So in no way is it interchangeable. >> > > This might be a problem. The exposure of symbols shouldn't be a problem > on its own (used as a shared library, the symbols exported are generic > enough); the additional stuff instead can be a problem indeed. > > I can't seem to find a detail of what the changes are, but I can tell > that using the jpeg library in Gentoo let OpenJDK build fine at least. > Building isn't the problem, Running is. The exported symbols in the JDK's libjpeg are accessed via JNI calls so until you get an UnsatisfiedLinkError at runtime when some JDK component tries to use it you won't know there's a problem. > I haven't sent any patch yet because I have to find a way to test it > out first. (zlib was easier). Note that also Gentoo's jpeg is not > totally vanilla, it contains a few patches coming from Debian, and a > security fix to keep a large allocation of memory from killing the > system. If the additional stuff might be of help, and wouldn't break > software written with vanilla jpeg in mind, it might as well be > possible to backport those changes in Gentoo's jpeg library. > > As far as I can see a good deal of the changes replaces the symbol main > with _main, the functional changes are at a minimum, I see a change in > the way EQTs are emitted, and an error downgraded to warning, and a > change in INT32 definition. I see some sprintf() calls changed to > jio_snprintf() too. > > After all, it doesn't seem like a difficult task to get the external > jpeg library to work fine with OpenJDK. > At the very least you'd need to find somewhere else to put the JNI native methods and then have them able to locate libjpeg. Also our build process has to be on all platforms. We need JPEG sources in the JDK since you aren't likely to find it on windows .. Complicating matters further there are some additonal changes not in the 'openjdk' until we sort out more legal issues. If we can't work those out these embedded changes would mean the commercial JDK would simply not be able to use an external libjpeg. and there'd be an annoying difference betwen the two builds A libjpeg has been baked into JDK since 1.0 I really don't think I want to change that now. I just don't see the value. Instead I see a lot of churn > I've seen there are also copies of libpng and giflib, are those > modified in some way, too? I'm now running a build with those used > external too. > > They are not, so far as I know modified, except to remove exraneous stuff. These are used by the AWT splashscreen API, and so only need reading capability, -phil. From Phil.Race at Sun.COM Fri May 11 18:02:58 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 11:02:58 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644ADEC.4090405@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> Message-ID: <4644AFD2.2020200@sun.com> PS .. if these fixes can be contributed into JDK's libjpeg that would be useful 2d-dev is the place .. -phil. >> Note that also Gentoo's jpeg is not >> totally vanilla, it contains a few patches coming from Debian, and a >> security fix to keep a large allocation of memory from killing the >> system. If the additional stuff might be of help, and wouldn't break >> software written with vanilla jpeg in mind, it might as well be >> possible to backport those changes in Gentoo's jpeg library. > From psj at familyjenner.co.uk Fri May 11 18:04:00 2007 From: psj at familyjenner.co.uk (Paul Jenner) Date: Fri, 11 May 2007 19:04:00 +0100 Subject: OpenJDK Build on OpenSuSE 10.2 Message-ID: <1178906640.5872.5.camel@localhost.localdomain> Hi Andreas. On Thu, 2007-05-10 at 21:00 -0700, Andreas Schaefer wrote: > I just managed to build OpenJDK on OpenSuSE 10.2 and here are the steps > to accomplish that; > > - Install JDK 1.6 downloaded from Sun's website You don't need that step either if you download the binary plugs currently available and use them as ALT_BOOTDIR to bootstrap instead of JDK 6. At least that works on Fedora. One step nearer a free toolchain... Paul -- Paul Jenner From flameeyes at gmail.com Fri May 11 18:11:28 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 20:11:28 +0200 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644ADEC.4090405@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> Message-ID: <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> On Fri, 11 May 2007 10:54:52 -0700 Phil Race wrote: > Building isn't the problem, Running is. The exported symbols in the > JDK's libjpeg are accessed via JNI > calls so until you get an UnsatisfiedLinkError at runtime when some > JDK component tries > to use it you won't know there's a problem. I admit I don't know enough of how JNI works myself, but aren't those like Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage ? Those symbols are still present in libjpeg.so library installed by OpenJDK, which links to /usr/lib64/libjpeg.so (in my case) to get the symbols for libjpeg proper. > At the very least you'd need to find somewhere else to put the JNI > native methods and then > have them able to locate libjpeg. > > Also our build process has to be on all platforms. We need JPEG > sources in the JDK > since you aren't likely to find it on windows .. That's why my patches adds an EXTERNAL_$something variable, that needs to be enabled explicitly to use the external copy. The default build would be 100% identical to what it was before, I put this as my top priority for any change I do. > They are not, so far as I know modified, except to remove exraneous > stuff. These are used by the AWT splashscreen API, and so only need > reading capability, Okay, an option would then be to use external jpeg only for the same AWT splashscreen API as it is, and leave the JNI version alone, if that is more feasible for you. What you think about this? -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From flameeyes at gmail.com Fri May 11 18:31:52 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 20:31:52 +0200 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644AFD2.2020200@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <4644AFD2.2020200@sun.com> Message-ID: <20070511203152.085a1b37@enterprise.flameeyes.is-a-geek.org> On Fri, 11 May 2007 11:02:58 -0700 Phil Race wrote: > PS .. if these fixes can be contributed into JDK's libjpeg that would > be useful > 2d-dev is the place .. I'm afraid I can't help there as I'm not the author of those changes and thus I can't submit them under SCA (which, as far as I can see, is needed for any copyrightable change, correct?). I'll try to see if I can track down the original authors of the patches when I have some extra time. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From betelgeuse at gentoo.org Fri May 11 18:35:19 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Fri, 11 May 2007 21:35:19 +0300 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644ADEC.4090405@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> Message-ID: <4644B767.8020102@gentoo.org> Phil Race kirjoitti: > > Complicating matters further there are some additonal changes not in the > 'openjdk' until we > sort out more legal issues. If we can't work those out these embedded > changes would mean > the commercial JDK would simply not be able to use an external libjpeg. > and there'd be > an annoying difference betwen the two builds > But it's important to remember that if OpenJDK is going to be fully embraced by Linux distributions, normal users are not going to be using your builds at all and distributions will be using external libraries if at all possible. Regards, Petteri -- Gentoo/Java project lead -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From Phil.Race at Sun.COM Fri May 11 18:54:12 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 11:54:12 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> Message-ID: <4644BBD4.7020108@sun.com> Diego 'Flameeyes' Petten? wrote: > On Fri, 11 May 2007 10:54:52 -0700 > Phil Race wrote: > > >> Building isn't the problem, Running is. The exported symbols in the >> JDK's libjpeg are accessed via JNI >> calls so until you get an UnsatisfiedLinkError at runtime when some >> JDK component tries >> to use it you won't know there's a problem. >> > > I admit I don't know enough of how JNI works myself, but aren't those > like Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage ? > yes > Those symbols are still present in libjpeg.so library installed by > OpenJDK, which links to /usr/lib64/libjpeg.so (in my case) to get the > symbols for libjpeg proper. > umm so you are stll installing the JDK version .. in that case I am not sure what you did to ensure that those JNI methods invoke the symbols in the gentoo version. Symbol resolution will first look in the same .so. You'd need to not include those .. I don't doubt this can be made to work to a degree but since I expect the OpenJDK libjpeg version to have additional stuff than the gentoo version its not ideal. >> Also our build process has to be on all platforms. We need JPEG >> sources in the JDK >> since you aren't likely to find it on windows .. >> > That's why my patches adds an EXTERNAL_$something variable, that needs > to be enabled explicitly to use the external copy. The default build > would be 100% identical to what it was before, I put this as my top > priority for any change I do. > OK that makes sense. I guess I see this in your ZLIB changes but not for JPEG I assume that's a TBD > >> They are not, so far as I know modified, except to remove exraneous >> stuff. These are used by the AWT splashscreen API, and so only need >> reading capability, >> > Okay, an option would then be to use external jpeg only for the same > AWT splashscreen API as it is, and leave the JNI version alone, if that > is more feasible for you. What you think about this? > An option to build libsplashscreen so that it grabs jpeg, gif and png support from platform libs rather than compiling in its own seems fine to me. They don't need the extra stuff in the JDK version The fact that the splashscreen stuff builds its own JPEG *is* an annoying anomaly. I can't remember or don't know why exactly AWT did this but I've had in the back of my mind to make it point to the libjpeg in the JDK for this. BTW the approach of deferring to the installed version of the library most certainly is something that we do when it makes sense and will do for libfreetype, for example -phil. From Phil.Race at Sun.COM Fri May 11 19:05:26 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 12:05:26 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644B767.8020102@gentoo.org> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <4644B767.8020102@gentoo.org> Message-ID: <4644BE76.9070905@sun.com> Petteri R?ty wrote: > Phil Race kirjoitti: > >> Complicating matters further there are some additonal changes not in the >> 'openjdk' until we >> sort out more legal issues. If we can't work those out these embedded >> changes would mean >> the commercial JDK would simply not be able to use an external libjpeg. >> and there'd be >> an annoying difference betwen the two builds >> >> > > But it's important to remember that if OpenJDK is going to be fully > embraced by Linux distributions, normal users are not going to be using > your builds at all and distributions will be using external libraries if > at all possible. > Right. Where possible. libjpeg happens to be a special case. We do use platform libs for the most part. Taking it to a silly extreme we obviously would not bundle a libX11. Its gotta be there. A big part of the reason things are bundled is when you *do* need them but have no idea if they'll be there. If you are building on gentoo for gentoo you can control that better But we also use libcups, libfontconfig., and we test for them using dlopen so don't explictly link .. if we can't find them we use other approaches. At some point if we use these a whole lot more then dlsym gets tiresome and we'd probably start depending on them at compile time. But our build platforms don't necessarily have them. Also for the font rasteriser we will defer to the platform installed version : that will be a straight compile time link. So the big picture is to use the platform libs, and not duplicate.. there just happen to be exceptions. -phil. > Regards, > Petteri > -- > Gentoo/Java project lead > > From psj at familyjenner.co.uk Fri May 11 19:30:35 2007 From: psj at familyjenner.co.uk (Paul Jenner) Date: Fri, 11 May 2007 20:30:35 +0100 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644BBD4.7020108@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> <4644BBD4.7020108@sun.com> Message-ID: <1178911835.5872.12.camel@localhost.localdomain> Hi Phil. On Fri, 2007-05-11 at 11:54 -0700, Phil Race wrote: > > I admit I don't know enough of how JNI works myself, but aren't those > > like Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage ? > > > yes I am probably missing the point but going forward why aren't the OpenJDK JNI specifics simply split out into a separate OpenJDK specific library (libopenjdkjpeg for argument's sake) which in turn references more standard libjpeg if available? That way building with either included or excluded version works and libjpeg stays as expected? Probably missing the point though :-) Thanks, Paul -- Paul Jenner From flameeyes at gmail.com Fri May 11 19:20:28 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 21:20:28 +0200 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644BBD4.7020108@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> <4644BBD4.7020108@sun.com> Message-ID: <20070511212028.6080ef98@enterprise.flameeyes.is-a-geek.org> On Fri, 11 May 2007 11:54:12 -0700 Phil Race wrote: > umm so you are stll installing the JDK version .. in that case I am > not sure what you did to ensure > that those JNI methods invoke the symbols in the gentoo version. I've simply removed the IJG jpeg's source files from the build, and added a -ljpeg flag (this is still a bit of WIP, as the link don't seem to happen as intended right now, I'm on it though). > OK that makes sense. > I guess I see this in your ZLIB changes but not for JPEG I assume > that's a TBD I haven't sent the other patches as I haven't tested them; I supposed that zlib changes, if done in a wrong way, would have just killed JAR opening, while jpeg/png/gif support needs to be tested somehow. > An option to build libsplashscreen so that it grabs jpeg, gif and png > support from platform > libs rather than compiling in its own seems fine to me. Okay, so I just need to test that part and then I can send it over, I'll split my jpeg patch so that the change to the JNI interface is not included for now. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Phil.Race at Sun.COM Fri May 11 20:30:54 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 13:30:54 -0700 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <1178911835.5872.12.camel@localhost.localdomain> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <20070511201128.062e97a7@enterprise.flameeyes.is-a-geek.org> <4644BBD4.7020108@sun.com> <1178911835.5872.12.camel@localhost.localdomain> Message-ID: <4644D27E.7050003@sun.com> Paul Jenner wrote: > Hi Phil. > > On Fri, 2007-05-11 at 11:54 -0700, Phil Race wrote: > >>> I admit I don't know enough of how JNI works myself, but aren't those >>> like Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage ? >>> >>> >> yes >> > > I am probably missing the point but going forward why aren't the OpenJDK > JNI specifics simply split out into a separate OpenJDK specific library > (libopenjdkjpeg for argument's sake) which in turn references more > standard libjpeg if available? > Because it doesn't use a 'standard' libjpeg. -phil. > That way building with either included or excluded version works and > libjpeg stays as expected? > > Probably missing the point though :-) > > Thanks, > > Paul > > From Weijun.Wang at Sun.COM Fri May 11 06:50:10 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 11 May 2007 14:50:10 +0800 Subject: Building on Fedora 6 In-Reply-To: <17986.64659.451226.280513@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> <17986.64659.451226.280513@zebedee.pink> Message-ID: My 2 cents: It's called "binary plugs", which means it's used to provide binaries for those components whose sources are not included in the OpenJDK yet. So, even today it looks like a full JDK, tomorrow you may see it includes only several jars and native libraries, and then one day, it will disappear completely. Thanks Max On 2007-5-10, at 19:05, Andrew Haley wrote: > Kelly O'Hair writes: > >> Andrew Haley wrote: > >>> Which reminds me: is there any need for JDK 1.6 in all of this? >>> The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of >>> the "binary blobs" is a full JDK, is it not? So it could be used >>> as the bootstrap JDK -- there's no need for JDK 1.6. >>> >> >> Officially, we boot from the previous FCS jdk (1.6.0), unofficially, >> jdk 1.5 or jdk 1.7 would work as a boot jdk. >> I suppose it may become an issue later if we somehow become dependent >> on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any >> issue like that on the horizon. A jdk 1.5 might be already available >> on your system. >> >> Using a boot of jdk 1.7 may have some risks, but should in general >> work. >> Note that the "binary plugs" are indeed full jdk 7 images right now, >> but none of the files will have execute permissions. > > OK, so I had to > > chmod -R +x /home/aph/openjdk/jdk1.7.0//bin > >> The binary plugs are distributed with a different license that allows >> their use as 'binary plugs'. I'd probably keep the binary plugs >> separate from the boot jdk, but that's just me. >> Also the binary plugs will need to be updated every time you freshen >> up your openjdk sources, the boot jdk is a pretty static thing. > > OK. > > Anyway, this works Just Fine. It's only necessary for developers on > GNU/Linux to download jdk-7-ea-plug-b12-linux-amd64-06_may_2007.jar > and openjdk-7-ea-src-b12-06_may_2007.zip: gcj is quite capable of > running the self-extracting Jar file. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, > Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 From Kelly.Ohair at Sun.COM Sat May 12 19:21:48 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 12 May 2007 12:21:48 -0700 Subject: Compilers and Libraries used from the system In-Reply-To: <4644B767.8020102@gentoo.org> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <4644B767.8020102@gentoo.org> Message-ID: <464613CC.5070906@sun.com> Historically the JDK distributed by Sun were built with a set of "build platforms", that are quite old now, but will always be older releases. This is done so that the resulting binaries run on as many platforms as possible, and building on older platforms has provided the best chance for that. Also, fewer builds often translates to lower overhead for the release engineering and quality departments. But using these older platforms has some serious problems, one of those is that the compilers and libraries provided on those platforms aren't ideal or are (were?) quite frankly unstable, unreliable, or unavailable. The goal was to make it as easy as possible for the JDK image to install on most Linux systems and just work, and work reliably. Without having to install any additional OS packages or patches to a system. Unfortunately some of the things we had to do need to be re-visited now, especially as the formal "build platforms" get upgraded for JDK7, but also with regards to OpenJDK. But we need to be very careful here. Native libraries loaded in with a JVM can create a great deal of havoc, and sometimes it is not horribly obvious why. Just compiling a native library with some new gcc/g++ optimization flag could introduce unstabilities, or using a shared library that wasn't mapped&scoped and exposed an extern symbol that conflicted with some other shared library or system call. I'm not saying we shouldn't try and use more external instances of libraries, just saying we need to be very careful and make sure that what we use is secure, mapped&scoped, safe, reliable, and always available. -kto From betelgeuse at gentoo.org Sat May 12 20:00:06 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sat, 12 May 2007 23:00:06 +0300 Subject: Compilers and Libraries used from the system In-Reply-To: <464613CC.5070906@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <4644B767.8020102@gentoo.org> <464613CC.5070906@sun.com> Message-ID: <46461CC6.2020006@gentoo.org> Kelly O'Hair kirjoitti: > > Historically the JDK distributed by Sun were built with a set of "build > platforms", > that are quite old now, but will always be older releases. > This is done so that the resulting binaries run on as many platforms > as possible, and building on older platforms has provided the best chance > for that. Also, fewer builds often translates to lower overhead for > the release engineering and quality departments. > But it also leads to things like: RDEPEND=" ${DEPEND} x86? ( =virtual/libstdc++-3.3 ) But in general I agree that if you are distributing Linux binaries you need to build them on old systems. In other words: betelgeuse at pena ~ $ scanelf -n /opt/sun-jdk-1.6.0/jre/lib/i386/libdeploy.so TYPE NEEDED FILE ET_DYN libc.so.6,libstdc++.so.5,libm.so.6,libgcc_s.so.1 /opt/sun-jdk-1.6.0/jre/lib/i386/libdeploy.so There is not reason why users should be required to have two versions of the C++ standard library installed. Regards, Petteri -- Gentoo/Java project lead -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From andreas.schaefer at madplanet.com Sun May 13 04:03:39 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Sat, 12 May 2007 21:03:39 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution Message-ID: <46468E1B.4040105@madplanet.com> Hi Geeks I moved to my development box which is a dual core AMD64 machine with OpenSuSE 10.2. Firing up the build is failing with: >>>Recursively making policytool all @ Sat May 12 18:25:56 PDT 2007 ... gmake[4]: Entering directory `/home/openjdk/jdk.svn/trunk/j2se/make/sun/security/policytool' Rebuilding /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/bin/policytool because of /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/policytool.o /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/policytool_md.o /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/splashscreen_stubs.o /usr/bin/gcc -o /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/bin/policytool -Xlinker -O1 -L/home/openjdk/jdk.svn/trunk/control/build/linux-amd64/lib/amd64 -Wl,-soname=lib.so -L /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/lib/amd64/jli -z origin -Wl,--allow-shlib-undefined -Wl,-rpath -Wl,\$ORIGIN/../lib/amd64/jli -Wl,-rpath -Wl,\$ORIGIN/../jre/lib/amd64/jli \ /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/policytool.o /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/policytool_md.o /home/openjdk/jdk.svn/trunk/control/build/linux-amd64/tmp/sun/sun.tools.security/policytool/obj64/splashscreen_stubs.o -lpthread -ljli -L/usr/X11R6/lib64 -lX11 -ldl -lc /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status After installing X11-devel and X11-Server I could go with the build even though I have no clue what fixed it. Have fun - Andy From fw at deneb.enyo.de Sun May 13 07:25:14 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 13 May 2007 09:25:14 +0200 Subject: Compilers and Libraries used from the system In-Reply-To: <464613CC.5070906@sun.com> (Kelly O'Hair's message of "Sat, 12 May 2007 12:21:48 -0700") References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> <4644B767.8020102@gentoo.org> <464613CC.5070906@sun.com> Message-ID: <87k5vd89t1.fsf@mid.deneb.enyo.de> * Kelly O'Hair: > I'm not saying we shouldn't try and use more external instances of > libraries, just saying we need to be very careful and make sure that what > we use is secure, mapped&scoped, safe, reliable, and always available. I think ELF linkers support a private, per-DSO namespace nowadays, so the issue of conflicts mostly disappears. It has to be this way because the Gtk Swing theme pulls in tons of system libraries (including zlib, freetype and libpng). From betelgeuse at gentoo.org Sun May 13 15:05:18 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sun, 13 May 2007 18:05:18 +0300 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <46468E1B.4040105@madplanet.com> References: <46468E1B.4040105@madplanet.com> Message-ID: <4647292E.3080002@gentoo.org> Andreas Schaefer kirjoitti: > /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: > cannot find -lX11 See that? > > After installing X11-devel and X11-Server I could go with the build even > though I have no clue what fixed it. > You were missing the libraries so installing them fixed it. Of course it would be better to check for them in the sanity check and fail with a nice error message. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From andreas.schaefer at madplanet.com Sun May 13 17:01:19 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Sun, 13 May 2007 10:01:19 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <4647292E.3080002@gentoo.org> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> Message-ID: <4647445F.6060101@madplanet.com> Hi Petteri R?ty wrote: > Andreas Schaefer kirjoitti: > >> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >> cannot find -lX11 >> > > See that? > Yes, I saw that and that what made me go installing X11. The strange thing is that there was only one X11.so (in ghostscript) and that after installing the additional RPMs I did not found any new X11.* files. It also seems only to happen on AMD64 because with OpenSuSE on Intel 32-bit I did not have to install these packages. > >> After installing X11-devel and X11-Server I could go with the build even >> though I have no clue what fixed it. >> >> > > You were missing the libraries so installing them fixed it. Of course it > would be better to check for them in the sanity check and fail with a > nice error message. > Well, maybe but I am not quite sure if you can check for all dependencies. It is also difficult to keep up as you see with the AccColorT.h file that is not used to build but the sanity check looks for that file. All of that is a strong incentive for me to have a Java-source-only build using Ant. It is way to complicated to build the Java source with the make file. -Andy From betelgeuse at gentoo.org Sun May 13 17:02:53 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Sun, 13 May 2007 20:02:53 +0300 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <4647445F.6060101@madplanet.com> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> Message-ID: <464744BD.7050907@gentoo.org> Andreas Schaefer kirjoitti: > Hi > > Petteri R?ty wrote: >> Andreas Schaefer kirjoitti: >> >>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >>> cannot find -lX11 >>> >> See that? >> > Yes, I saw that and that what made me go installing X11. The strange > thing is that there was only one X11.so (in ghostscript) and that after > installing the additional RPMs I did not found any new X11.* files. > > It also seems only to happen on AMD64 because with OpenSuSE on Intel > 32-bit I did not have to install these packages. >> The file the linker tries to find is libX11.so Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From andreas.schaefer at madplanet.com Sun May 13 20:51:59 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Sun, 13 May 2007 13:51:59 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <464744BD.7050907@gentoo.org> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> <464744BD.7050907@gentoo.org> Message-ID: <46477A6F.2050206@madplanet.com> Hi Geeks I found the RPM that needs to be installed to provide the libX11.so file: xorg-x11-libX11 It is required by any X11-devel RPM or the xorg-x11-server-sdk. Strangely enough the X11-devel packages are installed on my 32-bit installation but not in the 64-bit. -Andy From Kelly.Ohair at Sun.COM Mon May 14 02:01:48 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 13 May 2007 19:01:48 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <4647445F.6060101@madplanet.com> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> Message-ID: <4647C30C.6000208@sun.com> Andreas Schaefer wrote: > Hi > > Petteri R?ty wrote: >> Andreas Schaefer kirjoitti: >> >>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >>> cannot find -lX11 >>> >> See that? >> > Yes, I saw that and that what made me go installing X11. The strange > thing is that there was only one X11.so (in ghostscript) and that after > installing the additional RPMs I did not found any new X11.* files. > > It also seems only to happen on AMD64 because with OpenSuSE on Intel > 32-bit I did not have to install these packages. >> >>> After installing X11-devel and X11-Server I could go with the build even >>> though I have no clue what fixed it. >>> >>> >> You were missing the libraries so installing them fixed it. Of course it >> would be better to check for them in the sanity check and fail with a >> nice error message. >> > Well, maybe but I am not quite sure if you can check for all > dependencies. It is also difficult to keep up as you see with the > AccColorT.h file that is not used to build but the sanity check looks > for that file. > > All of that is a strong incentive for me to have a Java-source-only > build using Ant. It is way to complicated to build the Java source with > the make file. > Not sure what ant vs. make has to do with sanity checks and native libraries missing, seems like they are a pain no matter what you use to build. Just building the java source is worth investigating, but keep in mind that we need to clean up the javac/recompile build ordering issue we have. Right now, we use the boot jdk (stage 1) to build a javac from the jdk sources plus enough runtime for this new first stage2 javac to run. These classes are built by the boot javac, and usually aren't the final ones we want. Then we take the stage2 javac we built and recompile everything javac needs again, this gives us a new javac built from itself so to speak, then we compile all the rest of the java source of the jdk. The fact that we run what we build during the build process means that any java sources that are backed up with JNI native libraries must get their native code compiled after the java classes are built. Since you need the javah headers to compile the native code, you need the classes files first, then run javah, then run the native C/C++ compiler. It's pretty convoluted. But we plan on changing this soon, and in such a way that the entire jdk is built completely, and running the build at all isn't required to get a build. In other words, we remove the javac recompile stage2 compiler and use a prebuilt javac from the javac team. These changes are in the works, and should make things simplier to build, and faster too. The recompile process will be removed and delegated to the javac team. -kto > -Andy From gbenson at redhat.com Mon May 14 12:11:50 2007 From: gbenson at redhat.com (Gary Benson) Date: Mon, 14 May 2007 13:11:50 +0100 Subject: [PATCH] Allow usage of external zlib copy In-Reply-To: <4644ADEC.4090405@sun.com> References: <20070511073939.4d6b60da@enterprise.flameeyes.is-a-geek.org> <46448E86.8000308@sun.com> <20070511193913.33eae3c2@enterprise.flameeyes.is-a-geek.org> <4644ADEC.4090405@sun.com> Message-ID: <20070514121149.GA8855@redhat.com> Phil Race wrote: > A libjpeg has been baked into JDK since 1.0 I really don't think > I want to change that now. I just don't see the value. Instead > I see a lot of churn For distributions the value of not having static copies of libraries shows itself when security issues arise. And coincidentally the best example I of this was a zlib issue. The zlib manual used to say something like "the best way to use zlib is to import a copy into your program sources and build it statically" -- so *everybody* did. And then someone found an exploitable double-free in zlib, CVE-2002-0059. Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again". Having said that I've also been involved in distributing binaries that had to pre-built for different operating systems, and I know there's a great deal of value in simplifying the number of variables you have to deal with. I think the solution here has to be something that allows Sun to continue distributing statically linked stuff while allowing distributions to dynamically link. Even if we can't upstream the libjpeg changes, I'm sure most distributions would prefer shipping an "unofficial", patched version of libjpeg to shipping two copies. Cheers, Gary From gnu_andrew at member.fsf.org Mon May 14 19:46:59 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 14 May 2007 20:46:59 +0100 Subject: JDWP in the recent OpenJDK drop Message-ID: <200705142047.00055.gnu_andrew@member.fsf.org> Hi everyone, I'm currently in the process of trying to build the tools separate from the OpenJDK build, firstly so I have a tools.jar in order to attempt a build of the whole thing without a JDK and secondly so things like javadoc, apt, etc. can be made available separately. I've run across a problem in doing this. In com.sun.tools.jdi, there are numerous references to a com.sun.tools.jdi.JDWP class, but I can't for the life of me seem to find this anywhere in the OpenJDK drop (grep and find searches have proved futile). Is this being shipped, or is it being held back for now? Or am I looking in the wrong place? Any help much appreciated, Cheers, -- Andrew :-) Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } From Tim.Bell at Sun.COM Mon May 14 20:21:20 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Mon, 14 May 2007 13:21:20 -0700 Subject: JDWP in the recent OpenJDK drop In-Reply-To: <200705142047.00055.gnu_andrew@member.fsf.org> References: <200705142047.00055.gnu_andrew@member.fsf.org> Message-ID: <4648C4C0.6030304@sun.com> Greetings Andrew: > I'm currently in the process of trying to build the tools separate from the > OpenJDK build, firstly so I have a tools.jar in order to attempt a build of > the whole thing without a JDK and secondly so things like javadoc, apt, etc. > can be made available separately. > > I've run across a problem in doing this. In com.sun.tools.jdi, there are > numerous references to a com.sun.tools.jdi.JDWP class, but I can't for the > life of me seem to find this anywhere in the OpenJDK drop (grep and find > searches have proved futile). Is this being shipped, or is it being held > back for now? Or am I looking in the wrong place? The JDWP documentation and the .java files are generated during the build. That's why you don't find it when looking through the source files. This was not a move to obfuscate anything, but to make sure the doc and the code are always in agreement. The input file is j2se/src/share/classes/com/sun/tools/jdwpgen/jdwp.spec Look at j2se/make/jpda/jdwpgen/Makefile The transformation tool is defined here: j2se/src/share/classes/com/sun/tools/jdwpgen/*.java Hope this helps - Tim Bell From flameeyes at gmail.com Mon May 14 22:53:47 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Tue, 15 May 2007 00:53:47 +0200 Subject: [PATCH] Add a BUILD_DISTRIBUTOR variable to the build process Message-ID: <20070515005347.7b391f2e@enterprise.flameeyes.is-a-geek.org> As OpenJDK is likely to get packaged by a few distributions, it might be useful to add an indication of the distribution used on the -version output for the java command. As all the variables available in Defs.gmk don't seem to put a string before the full version, I've prepared the attached patch. With this, by passing BUILD_DISTRIBUTOR=Gentoo, I get the following output: flame at enterprise ~ % java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build Gentoo-1.7.0-internal-portage_14_may_2007_23_47-b00) OpenJDK 64-Bit Server VM (build Gentoo-1.7.0-internal-portage_14_may_2007_23_47-b00, mixed mode) Hope this might help to make sure that the eventually patched versions are not mistaken for a vanilla version. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-tag-distributor.patch Type: text/x-patch Size: 585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.schaefer at madplanet.com Mon May 14 23:30:03 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Mon, 14 May 2007 16:30:03 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <4647C30C.6000208@sun.com> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> <4647C30C.6000208@sun.com> Message-ID: <4648F0FB.2090103@madplanet.com> Kelly O'Hair wrote: > > > Andreas Schaefer wrote: >> Hi >> >> Petteri R?ty wrote: >>> Andreas Schaefer kirjoitti: >>> >>>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >>>> >>>> cannot find -lX11 >>>> >>> See that? >>> >> Yes, I saw that and that what made me go installing X11. The strange >> thing is that there was only one X11.so (in ghostscript) and that after >> installing the additional RPMs I did not found any new X11.* files. >> >> It also seems only to happen on AMD64 because with OpenSuSE on Intel >> 32-bit I did not have to install these packages. >>> >>>> After installing X11-devel and X11-Server I could go with the build >>>> even >>>> though I have no clue what fixed it. >>>> >>>> >>> You were missing the libraries so installing them fixed it. Of >>> course it >>> would be better to check for them in the sanity check and fail with a >>> nice error message. >>> >> Well, maybe but I am not quite sure if you can check for all >> dependencies. It is also difficult to keep up as you see with the >> AccColorT.h file that is not used to build but the sanity check looks >> for that file. >> >> All of that is a strong incentive for me to have a Java-source-only >> build using Ant. It is way to complicated to build the Java source with >> the make file. >> > > Not sure what ant vs. make has to do with sanity checks and native > libraries > missing, seems like they are a pain no matter what you use to build. > > Just building the java source is worth investigating, but keep in mind > that we need to clean up the javac/recompile build ordering issue we > have. > Right now, we use the boot jdk (stage 1) to build a javac from the jdk > sources plus > enough runtime for this new first stage2 javac to run. These classes are > built by the boot javac, and usually aren't the final ones we want. > Then we take the stage2 javac we built and recompile everything javac > needs again, this gives us a new javac built from itself so to speak, > then we compile all the rest of the java source of the jdk. > The fact that we run what we build during the build process means that > any java sources that are backed up with JNI native libraries must > get their native code compiled after the java classes are built. > Since you need the javah headers to compile the native code, you need > the classes files first, then run javah, then run the native C/C++ > compiler. > It's pretty convoluted. > > But we plan on changing this soon, and in such a way that the entire > jdk is built completely, and running the build at all isn't required > to get > a build. In other words, we remove the javac recompile stage2 compiler > and use a prebuilt javac from the javac team. > These changes are in the works, and should make things simplier to > build, and faster too. > The recompile process will be removed and delegated to the javac > team. > > -kto My primary goal is to create a build script that only builds the Java part to make life easier for "Java-only" developers. That said I agree that it would not make much sense to have a build in Make and Ant but for now that is were I will start just to find the pitfalls and traps. Right now it takes way to long for my little change in the URLConnection to build before I can fire up a test. Maybe Java is called so because I can get a few cups of Joe when Java is building - just kidding. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: andreas.schaefer.vcf Type: text/x-vcard Size: 417 bytes Desc: not available URL: From Kelly.Ohair at Sun.COM Tue May 15 01:11:14 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 14 May 2007 18:11:14 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <4648F0FB.2090103@madplanet.com> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> <4647C30C.6000208@sun.com> <4648F0FB.2090103@madplanet.com> Message-ID: <464908B2.5090509@sun.com> Keep in mind that there are some java sources that are templates for generated code, and there are several other ways java source is generated during the build process. So a simple ant script just isn't going to be possible. Look in the build/*/gensrc directory after a build for all the generated java sources. -kto Andreas Schaefer wrote: > Kelly O'Hair wrote: >> >> >> Andreas Schaefer wrote: >>> Hi >>> >>> Petteri R?ty wrote: >>>> Andreas Schaefer kirjoitti: >>>> >>>>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >>>>> >>>>> cannot find -lX11 >>>>> >>>> See that? >>>> >>> Yes, I saw that and that what made me go installing X11. The strange >>> thing is that there was only one X11.so (in ghostscript) and that after >>> installing the additional RPMs I did not found any new X11.* files. >>> >>> It also seems only to happen on AMD64 because with OpenSuSE on Intel >>> 32-bit I did not have to install these packages. >>>> >>>>> After installing X11-devel and X11-Server I could go with the build >>>>> even >>>>> though I have no clue what fixed it. >>>>> >>>>> >>>> You were missing the libraries so installing them fixed it. Of >>>> course it >>>> would be better to check for them in the sanity check and fail with a >>>> nice error message. >>>> >>> Well, maybe but I am not quite sure if you can check for all >>> dependencies. It is also difficult to keep up as you see with the >>> AccColorT.h file that is not used to build but the sanity check looks >>> for that file. >>> >>> All of that is a strong incentive for me to have a Java-source-only >>> build using Ant. It is way to complicated to build the Java source with >>> the make file. >>> >> >> Not sure what ant vs. make has to do with sanity checks and native >> libraries >> missing, seems like they are a pain no matter what you use to build. >> >> Just building the java source is worth investigating, but keep in mind >> that we need to clean up the javac/recompile build ordering issue we >> have. >> Right now, we use the boot jdk (stage 1) to build a javac from the jdk >> sources plus >> enough runtime for this new first stage2 javac to run. These classes are >> built by the boot javac, and usually aren't the final ones we want. >> Then we take the stage2 javac we built and recompile everything javac >> needs again, this gives us a new javac built from itself so to speak, >> then we compile all the rest of the java source of the jdk. >> The fact that we run what we build during the build process means that >> any java sources that are backed up with JNI native libraries must >> get their native code compiled after the java classes are built. >> Since you need the javah headers to compile the native code, you need >> the classes files first, then run javah, then run the native C/C++ >> compiler. >> It's pretty convoluted. >> >> But we plan on changing this soon, and in such a way that the entire >> jdk is built completely, and running the build at all isn't required >> to get >> a build. In other words, we remove the javac recompile stage2 compiler >> and use a prebuilt javac from the javac team. >> These changes are in the works, and should make things simplier to >> build, and faster too. >> The recompile process will be removed and delegated to the javac >> team. >> >> -kto > My primary goal is to create a build script that only builds the Java > part to make life easier for "Java-only" developers. That said I agree > that it would not make much sense to have a build in Make and Ant but > for now that is were I will start just to find the pitfalls and traps. > Right now it takes way to long for my little change in the URLConnection > to build before I can fire up a test. > > Maybe Java is called so because I can get a few cups of Joe when Java is > building - just kidding. > > -Andy From andreas.schaefer at madplanet.com Tue May 15 03:43:47 2007 From: andreas.schaefer at madplanet.com (Andreas Schaefer) Date: Mon, 14 May 2007 20:43:47 -0700 Subject: Build Failure on OpenSuSE 10.2 AMD 64 and Solution In-Reply-To: <464908B2.5090509@sun.com> References: <46468E1B.4040105@madplanet.com> <4647292E.3080002@gentoo.org> <4647445F.6060101@madplanet.com> <4647C30C.6000208@sun.com> <4648F0FB.2090103@madplanet.com> <464908B2.5090509@sun.com> Message-ID: <46492C73.9030800@madplanet.com> While trying to contribute to Mustang I already ran into this issue so I am aware of it. I will see if I am going to create an Ant Task or if there is another way to go around it. In addition the sheer number of Java classes making a full build impossible and so I have to consider splitting them up. -Andy Kelly O'Hair wrote: > Keep in mind that there are some java sources that are templates for > generated code, and there are several other ways java source is generated > during the build process. So a simple ant script just isn't going to be > possible. Look in the build/*/gensrc directory after a build for all the > generated java sources. > > -kto > > Andreas Schaefer wrote: >> Kelly O'Hair wrote: >>> >>> >>> Andreas Schaefer wrote: >>>> Hi >>>> >>>> Petteri R?ty wrote: >>>>> Andreas Schaefer kirjoitti: >>>>> >>>>>> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: >>>>>> >>>>>> cannot find -lX11 >>>>>> >>>>> See that? >>>>> >>>> Yes, I saw that and that what made me go installing X11. The strange >>>> thing is that there was only one X11.so (in ghostscript) and that >>>> after >>>> installing the additional RPMs I did not found any new X11.* files. >>>> >>>> It also seems only to happen on AMD64 because with OpenSuSE on Intel >>>> 32-bit I did not have to install these packages. >>>>> >>>>>> After installing X11-devel and X11-Server I could go with the >>>>>> build even >>>>>> though I have no clue what fixed it. >>>>>> >>>>>> >>>>> You were missing the libraries so installing them fixed it. Of >>>>> course it >>>>> would be better to check for them in the sanity check and fail with a >>>>> nice error message. >>>>> >>>> Well, maybe but I am not quite sure if you can check for all >>>> dependencies. It is also difficult to keep up as you see with the >>>> AccColorT.h file that is not used to build but the sanity check looks >>>> for that file. >>>> >>>> All of that is a strong incentive for me to have a Java-source-only >>>> build using Ant. It is way to complicated to build the Java source >>>> with >>>> the make file. >>>> >>> >>> Not sure what ant vs. make has to do with sanity checks and native >>> libraries >>> missing, seems like they are a pain no matter what you use to build. >>> >>> Just building the java source is worth investigating, but keep in mind >>> that we need to clean up the javac/recompile build ordering issue we >>> have. >>> Right now, we use the boot jdk (stage 1) to build a javac from the >>> jdk sources plus >>> enough runtime for this new first stage2 javac to run. These classes >>> are >>> built by the boot javac, and usually aren't the final ones we want. >>> Then we take the stage2 javac we built and recompile everything javac >>> needs again, this gives us a new javac built from itself so to speak, >>> then we compile all the rest of the java source of the jdk. >>> The fact that we run what we build during the build process means that >>> any java sources that are backed up with JNI native libraries must >>> get their native code compiled after the java classes are built. >>> Since you need the javah headers to compile the native code, you need >>> the classes files first, then run javah, then run the native C/C++ >>> compiler. >>> It's pretty convoluted. >>> >>> But we plan on changing this soon, and in such a way that the entire >>> jdk is built completely, and running the build at all isn't required >>> to get >>> a build. In other words, we remove the javac recompile stage2 compiler >>> and use a prebuilt javac from the javac team. >>> These changes are in the works, and should make things simplier to >>> build, and faster too. >>> The recompile process will be removed and delegated to the javac >>> team. >>> >>> -kto >> My primary goal is to create a build script that only builds the Java >> part to make life easier for "Java-only" developers. That said I >> agree that it would not make much sense to have a build in Make and >> Ant but for now that is were I will start just to find the pitfalls >> and traps. Right now it takes way to long for my little change in the >> URLConnection to build before I can fire up a test. >> >> Maybe Java is called so because I can get a few cups of Joe when Java >> is building - just kidding. >> >> -Andy From lhofhansl at yahoo.com Tue May 15 06:22:59 2007 From: lhofhansl at yahoo.com (Lars) Date: Mon, 14 May 2007 23:22:59 -0700 Subject: Why are the binay plugs so big? Message-ID: <464951C3.7070005@yahoo.com> After looking through the Makefiles (mostly Release.gmk) I was able to build OpenJDK on Linux with ~4MB of binary plugs (unpacked), which is only a fraction of a provided plugs which weigh in with over 170MB (unpacked). The following list of files (and contents of rt.jar) should be pretty universal and not just for Linux. rt.jar can even be reduced a little further. So the obvious question: Why are the Sun provided binary plug so huge? Files: jdk1.7.0/ jdk1.7.0/jre jdk1.7.0/jre/COPYRIGHT jdk1.7.0/jre/LICENSE jdk1.7.0/jre/lib jdk1.7.0/jre/lib/jce.jar jdk1.7.0/jre/lib/applet jdk1.7.0/jre/lib/net.properties jdk1.7.0/jre/lib/logging.properties jdk1.7.0/jre/lib/flavormap.properties jdk1.7.0/jre/lib/jvm.hprof.txt jdk1.7.0/jre/lib/i386 jdk1.7.0/jre/lib/i386/jvm.cfg jdk1.7.0/jre/lib/i386/libdcpr.so jdk1.7.0/jre/lib/i386/libjsoundalsa.so jdk1.7.0/jre/lib/i386/libjsound.so jdk1.7.0/jre/lib/i386/libt2k.so jdk1.7.0/jre/lib/images jdk1.7.0/jre/lib/images/cursors jdk1.7.0/jre/lib/images/cursors/motif_LinkNoDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/motif_MoveNoDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/cursors.properties jdk1.7.0/jre/lib/images/cursors/motif_CopyDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/motif_LinkDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/motif_CopyNoDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/motif_MoveDrop32x32.gif jdk1.7.0/jre/lib/images/cursors/invalid32x32.gif jdk1.7.0/jre/lib/classlist jdk1.7.0/jre/lib/security jdk1.7.0/jre/lib/security/java.policy jdk1.7.0/jre/lib/security/US_export_policy.jar jdk1.7.0/jre/lib/security/local_policy.jar jdk1.7.0/jre/lib/security/java.security jdk1.7.0/jre/lib/audio jdk1.7.0/jre/lib/audio/soundbank.gm jdk1.7.0/jre/lib/zi jdk1.7.0/jre/lib/zi/Asia jdk1.7.0/jre/lib/zi/Asia/Dili jdk1.7.0/jre/lib/zi/Asia/Magadan jdk1.7.0/jre/lib/zi/Asia/Muscat jdk1.7.0/jre/lib/zi/Asia/Karachi jdk1.7.0/jre/lib/zi/Asia/Manila jdk1.7.0/jre/lib/zi/Asia/Katmandu jdk1.7.0/jre/lib/zi/Asia/Bahrain jdk1.7.0/jre/lib/zi/Asia/Dushanbe jdk1.7.0/jre/lib/zi/Asia/Saigon jdk1.7.0/jre/lib/zi/Asia/Anadyr jdk1.7.0/jre/lib/zi/Asia/Rangoon jdk1.7.0/jre/lib/zi/Asia/Tashkent jdk1.7.0/jre/lib/zi/Asia/Amman jdk1.7.0/jre/lib/zi/Asia/Oral jdk1.7.0/jre/lib/zi/Asia/Calcutta jdk1.7.0/jre/lib/zi/Asia/Jakarta jdk1.7.0/jre/lib/zi/Asia/Aqtau jdk1.7.0/jre/lib/zi/Asia/Dubai jdk1.7.0/jre/lib/zi/Asia/Ashgabat jdk1.7.0/jre/lib/zi/Asia/Beirut jdk1.7.0/jre/lib/zi/Asia/Hovd jdk1.7.0/jre/lib/zi/Asia/Jayapura jdk1.7.0/jre/lib/zi/Asia/Samarkand jdk1.7.0/jre/lib/zi/Asia/Krasnoyarsk jdk1.7.0/jre/lib/zi/Asia/Aqtobe jdk1.7.0/jre/lib/zi/Asia/Omsk jdk1.7.0/jre/lib/zi/Asia/Seoul jdk1.7.0/jre/lib/zi/Asia/Bishkek jdk1.7.0/jre/lib/zi/Asia/Thimphu jdk1.7.0/jre/lib/zi/Asia/Novosibirsk jdk1.7.0/jre/lib/zi/Asia/Kabul jdk1.7.0/jre/lib/zi/Asia/Baku jdk1.7.0/jre/lib/zi/Asia/Riyadh88 jdk1.7.0/jre/lib/zi/Asia/Tehran jdk1.7.0/jre/lib/zi/Asia/Taipei jdk1.7.0/jre/lib/zi/Asia/Makassar jdk1.7.0/jre/lib/zi/Asia/Yakutsk jdk1.7.0/jre/lib/zi/Asia/Tokyo jdk1.7.0/jre/lib/zi/Asia/Urumqi jdk1.7.0/jre/lib/zi/Asia/Kuala_Lumpur jdk1.7.0/jre/lib/zi/Asia/Riyadh89 jdk1.7.0/jre/lib/zi/Asia/Kuwait jdk1.7.0/jre/lib/zi/Asia/Brunei jdk1.7.0/jre/lib/zi/Asia/Shanghai jdk1.7.0/jre/lib/zi/Asia/Ulaanbaatar jdk1.7.0/jre/lib/zi/Asia/Aden jdk1.7.0/jre/lib/zi/Asia/Choibalsan jdk1.7.0/jre/lib/zi/Asia/Qyzylorda jdk1.7.0/jre/lib/zi/Asia/Tbilisi jdk1.7.0/jre/lib/zi/Asia/Vientiane jdk1.7.0/jre/lib/zi/Asia/Macau jdk1.7.0/jre/lib/zi/Asia/Vladivostok jdk1.7.0/jre/lib/zi/Asia/Yerevan jdk1.7.0/jre/lib/zi/Asia/Gaza jdk1.7.0/jre/lib/zi/Asia/Phnom_Penh jdk1.7.0/jre/lib/zi/Asia/Bangkok jdk1.7.0/jre/lib/zi/Asia/Harbin jdk1.7.0/jre/lib/zi/Asia/Kashgar jdk1.7.0/jre/lib/zi/Asia/Baghdad jdk1.7.0/jre/lib/zi/Asia/Damascus jdk1.7.0/jre/lib/zi/Asia/Nicosia jdk1.7.0/jre/lib/zi/Asia/Jerusalem jdk1.7.0/jre/lib/zi/Asia/Singapore jdk1.7.0/jre/lib/zi/Asia/Pontianak jdk1.7.0/jre/lib/zi/Asia/Qatar jdk1.7.0/jre/lib/zi/Asia/Dhaka jdk1.7.0/jre/lib/zi/Asia/Almaty jdk1.7.0/jre/lib/zi/Asia/Chongqing jdk1.7.0/jre/lib/zi/Asia/Hong_Kong jdk1.7.0/jre/lib/zi/Asia/Yekaterinburg jdk1.7.0/jre/lib/zi/Asia/Riyadh jdk1.7.0/jre/lib/zi/Asia/Pyongyang jdk1.7.0/jre/lib/zi/Asia/Kamchatka jdk1.7.0/jre/lib/zi/Asia/Irkutsk jdk1.7.0/jre/lib/zi/Asia/Riyadh87 jdk1.7.0/jre/lib/zi/Asia/Sakhalin jdk1.7.0/jre/lib/zi/Asia/Kuching jdk1.7.0/jre/lib/zi/Asia/Colombo jdk1.7.0/jre/lib/zi/HST jdk1.7.0/jre/lib/zi/GMT jdk1.7.0/jre/lib/zi/Antarctica jdk1.7.0/jre/lib/zi/Antarctica/DumontDUrville jdk1.7.0/jre/lib/zi/Antarctica/Mawson jdk1.7.0/jre/lib/zi/Antarctica/Davis jdk1.7.0/jre/lib/zi/Antarctica/Rothera jdk1.7.0/jre/lib/zi/Antarctica/McMurdo jdk1.7.0/jre/lib/zi/Antarctica/Palmer jdk1.7.0/jre/lib/zi/Antarctica/Syowa jdk1.7.0/jre/lib/zi/Antarctica/Casey jdk1.7.0/jre/lib/zi/Antarctica/Vostok jdk1.7.0/jre/lib/zi/EST jdk1.7.0/jre/lib/zi/CST6CDT jdk1.7.0/jre/lib/zi/CET jdk1.7.0/jre/lib/zi/MST7MDT jdk1.7.0/jre/lib/zi/Australia jdk1.7.0/jre/lib/zi/Australia/Broken_Hill jdk1.7.0/jre/lib/zi/Australia/Lord_Howe jdk1.7.0/jre/lib/zi/Australia/Melbourne jdk1.7.0/jre/lib/zi/Australia/Brisbane jdk1.7.0/jre/lib/zi/Australia/Darwin jdk1.7.0/jre/lib/zi/Australia/Lindeman jdk1.7.0/jre/lib/zi/Australia/Eucla jdk1.7.0/jre/lib/zi/Australia/Adelaide jdk1.7.0/jre/lib/zi/Australia/Hobart jdk1.7.0/jre/lib/zi/Australia/Perth jdk1.7.0/jre/lib/zi/Australia/Currie jdk1.7.0/jre/lib/zi/Australia/Sydney jdk1.7.0/jre/lib/zi/SystemV jdk1.7.0/jre/lib/zi/SystemV/CST6CDT jdk1.7.0/jre/lib/zi/SystemV/HST10 jdk1.7.0/jre/lib/zi/SystemV/PST8 jdk1.7.0/jre/lib/zi/SystemV/MST7MDT jdk1.7.0/jre/lib/zi/SystemV/AST4ADT jdk1.7.0/jre/lib/zi/SystemV/CST6 jdk1.7.0/jre/lib/zi/SystemV/EST5EDT jdk1.7.0/jre/lib/zi/SystemV/YST9 jdk1.7.0/jre/lib/zi/SystemV/YST9YDT jdk1.7.0/jre/lib/zi/SystemV/MST7 jdk1.7.0/jre/lib/zi/SystemV/EST5 jdk1.7.0/jre/lib/zi/SystemV/AST4 jdk1.7.0/jre/lib/zi/SystemV/PST8PDT jdk1.7.0/jre/lib/zi/MST jdk1.7.0/jre/lib/zi/WET jdk1.7.0/jre/lib/zi/Europe jdk1.7.0/jre/lib/zi/Europe/Amsterdam jdk1.7.0/jre/lib/zi/Europe/Berlin jdk1.7.0/jre/lib/zi/Europe/Brussels jdk1.7.0/jre/lib/zi/Europe/Rome jdk1.7.0/jre/lib/zi/Europe/Sofia jdk1.7.0/jre/lib/zi/Europe/Warsaw jdk1.7.0/jre/lib/zi/Europe/London jdk1.7.0/jre/lib/zi/Europe/Monaco jdk1.7.0/jre/lib/zi/Europe/Kaliningrad jdk1.7.0/jre/lib/zi/Europe/Zaporozhye jdk1.7.0/jre/lib/zi/Europe/Riga jdk1.7.0/jre/lib/zi/Europe/Tirane jdk1.7.0/jre/lib/zi/Europe/Kiev jdk1.7.0/jre/lib/zi/Europe/Istanbul jdk1.7.0/jre/lib/zi/Europe/Belgrade jdk1.7.0/jre/lib/zi/Europe/Paris jdk1.7.0/jre/lib/zi/Europe/Gibraltar jdk1.7.0/jre/lib/zi/Europe/Bucharest jdk1.7.0/jre/lib/zi/Europe/Vienna jdk1.7.0/jre/lib/zi/Europe/Samara jdk1.7.0/jre/lib/zi/Europe/Vaduz jdk1.7.0/jre/lib/zi/Europe/Zurich jdk1.7.0/jre/lib/zi/Europe/Dublin jdk1.7.0/jre/lib/zi/Europe/Madrid jdk1.7.0/jre/lib/zi/Europe/Volgograd jdk1.7.0/jre/lib/zi/Europe/Oslo jdk1.7.0/jre/lib/zi/Europe/Malta jdk1.7.0/jre/lib/zi/Europe/Moscow jdk1.7.0/jre/lib/zi/Europe/Luxembourg jdk1.7.0/jre/lib/zi/Europe/Athens jdk1.7.0/jre/lib/zi/Europe/Prague jdk1.7.0/jre/lib/zi/Europe/Lisbon jdk1.7.0/jre/lib/zi/Europe/Stockholm jdk1.7.0/jre/lib/zi/Europe/Vilnius jdk1.7.0/jre/lib/zi/Europe/Uzhgorod jdk1.7.0/jre/lib/zi/Europe/Tallinn jdk1.7.0/jre/lib/zi/Europe/Helsinki jdk1.7.0/jre/lib/zi/Europe/Minsk jdk1.7.0/jre/lib/zi/Europe/Simferopol jdk1.7.0/jre/lib/zi/Europe/Copenhagen jdk1.7.0/jre/lib/zi/Europe/Budapest jdk1.7.0/jre/lib/zi/Europe/Chisinau jdk1.7.0/jre/lib/zi/Europe/Andorra jdk1.7.0/jre/lib/zi/Africa jdk1.7.0/jre/lib/zi/Africa/Bangui jdk1.7.0/jre/lib/zi/Africa/Windhoek jdk1.7.0/jre/lib/zi/Africa/Sao_Tome jdk1.7.0/jre/lib/zi/Africa/Ouagadougou jdk1.7.0/jre/lib/zi/Africa/Algiers jdk1.7.0/jre/lib/zi/Africa/Ndjamena jdk1.7.0/jre/lib/zi/Africa/Banjul jdk1.7.0/jre/lib/zi/Africa/Ceuta jdk1.7.0/jre/lib/zi/Africa/Djibouti jdk1.7.0/jre/lib/zi/Africa/Nairobi jdk1.7.0/jre/lib/zi/Africa/Kampala jdk1.7.0/jre/lib/zi/Africa/Brazzaville jdk1.7.0/jre/lib/zi/Africa/Lagos jdk1.7.0/jre/lib/zi/Africa/Harare jdk1.7.0/jre/lib/zi/Africa/Lubumbashi jdk1.7.0/jre/lib/zi/Africa/Dakar jdk1.7.0/jre/lib/zi/Africa/Monrovia jdk1.7.0/jre/lib/zi/Africa/Lome jdk1.7.0/jre/lib/zi/Africa/Asmara jdk1.7.0/jre/lib/zi/Africa/Luanda jdk1.7.0/jre/lib/zi/Africa/Lusaka jdk1.7.0/jre/lib/zi/Africa/Libreville jdk1.7.0/jre/lib/zi/Africa/El_Aaiun jdk1.7.0/jre/lib/zi/Africa/Mbabane jdk1.7.0/jre/lib/zi/Africa/Blantyre jdk1.7.0/jre/lib/zi/Africa/Mogadishu jdk1.7.0/jre/lib/zi/Africa/Maputo jdk1.7.0/jre/lib/zi/Africa/Johannesburg jdk1.7.0/jre/lib/zi/Africa/Douala jdk1.7.0/jre/lib/zi/Africa/Maseru jdk1.7.0/jre/lib/zi/Africa/Addis_Ababa jdk1.7.0/jre/lib/zi/Africa/Freetown jdk1.7.0/jre/lib/zi/Africa/Accra jdk1.7.0/jre/lib/zi/Africa/Bamako jdk1.7.0/jre/lib/zi/Africa/Niamey jdk1.7.0/jre/lib/zi/Africa/Bissau jdk1.7.0/jre/lib/zi/Africa/Conakry jdk1.7.0/jre/lib/zi/Africa/Bujumbura jdk1.7.0/jre/lib/zi/Africa/Tunis jdk1.7.0/jre/lib/zi/Africa/Abidjan jdk1.7.0/jre/lib/zi/Africa/Malabo jdk1.7.0/jre/lib/zi/Africa/Cairo jdk1.7.0/jre/lib/zi/Africa/Porto-Novo jdk1.7.0/jre/lib/zi/Africa/Nouakchott jdk1.7.0/jre/lib/zi/Africa/Casablanca jdk1.7.0/jre/lib/zi/Africa/Dar_es_Salaam jdk1.7.0/jre/lib/zi/Africa/Tripoli jdk1.7.0/jre/lib/zi/Africa/Khartoum jdk1.7.0/jre/lib/zi/Africa/Kinshasa jdk1.7.0/jre/lib/zi/Africa/Kigali jdk1.7.0/jre/lib/zi/Africa/Gaborone jdk1.7.0/jre/lib/zi/EET jdk1.7.0/jre/lib/zi/EST5EDT jdk1.7.0/jre/lib/zi/Etc jdk1.7.0/jre/lib/zi/Etc/GMT jdk1.7.0/jre/lib/zi/Etc/GMT+5 jdk1.7.0/jre/lib/zi/Etc/GMT-13 jdk1.7.0/jre/lib/zi/Etc/GMT+12 jdk1.7.0/jre/lib/zi/Etc/GMT+11 jdk1.7.0/jre/lib/zi/Etc/GMT-6 jdk1.7.0/jre/lib/zi/Etc/GMT-4 jdk1.7.0/jre/lib/zi/Etc/GMT-12 jdk1.7.0/jre/lib/zi/Etc/GMT-8 jdk1.7.0/jre/lib/zi/Etc/GMT+1 jdk1.7.0/jre/lib/zi/Etc/GMT+8 jdk1.7.0/jre/lib/zi/Etc/GMT+2 jdk1.7.0/jre/lib/zi/Etc/GMT-10 jdk1.7.0/jre/lib/zi/Etc/GMT-11 jdk1.7.0/jre/lib/zi/Etc/UCT jdk1.7.0/jre/lib/zi/Etc/GMT-3 jdk1.7.0/jre/lib/zi/Etc/GMT+9 jdk1.7.0/jre/lib/zi/Etc/GMT-1 jdk1.7.0/jre/lib/zi/Etc/GMT-2 jdk1.7.0/jre/lib/zi/Etc/GMT-14 jdk1.7.0/jre/lib/zi/Etc/GMT+6 jdk1.7.0/jre/lib/zi/Etc/GMT+3 jdk1.7.0/jre/lib/zi/Etc/GMT-5 jdk1.7.0/jre/lib/zi/Etc/GMT+4 jdk1.7.0/jre/lib/zi/Etc/GMT-9 jdk1.7.0/jre/lib/zi/Etc/GMT+7 jdk1.7.0/jre/lib/zi/Etc/UTC jdk1.7.0/jre/lib/zi/Etc/GMT+10 jdk1.7.0/jre/lib/zi/Etc/GMT-7 jdk1.7.0/jre/lib/zi/Pacific jdk1.7.0/jre/lib/zi/Pacific/Honolulu jdk1.7.0/jre/lib/zi/Pacific/Kiritimati jdk1.7.0/jre/lib/zi/Pacific/Midway jdk1.7.0/jre/lib/zi/Pacific/Nauru jdk1.7.0/jre/lib/zi/Pacific/Johnston jdk1.7.0/jre/lib/zi/Pacific/Ponape jdk1.7.0/jre/lib/zi/Pacific/Galapagos jdk1.7.0/jre/lib/zi/Pacific/Auckland jdk1.7.0/jre/lib/zi/Pacific/Wake jdk1.7.0/jre/lib/zi/Pacific/Tongatapu jdk1.7.0/jre/lib/zi/Pacific/Chatham jdk1.7.0/jre/lib/zi/Pacific/Wallis jdk1.7.0/jre/lib/zi/Pacific/Truk jdk1.7.0/jre/lib/zi/Pacific/Efate jdk1.7.0/jre/lib/zi/Pacific/Fiji jdk1.7.0/jre/lib/zi/Pacific/Port_Moresby jdk1.7.0/jre/lib/zi/Pacific/Marquesas jdk1.7.0/jre/lib/zi/Pacific/Tahiti jdk1.7.0/jre/lib/zi/Pacific/Funafuti jdk1.7.0/jre/lib/zi/Pacific/Niue jdk1.7.0/jre/lib/zi/Pacific/Easter jdk1.7.0/jre/lib/zi/Pacific/Gambier jdk1.7.0/jre/lib/zi/Pacific/Kosrae jdk1.7.0/jre/lib/zi/Pacific/Norfolk jdk1.7.0/jre/lib/zi/Pacific/Fakaofo jdk1.7.0/jre/lib/zi/Pacific/Majuro jdk1.7.0/jre/lib/zi/Pacific/Enderbury jdk1.7.0/jre/lib/zi/Pacific/Kwajalein jdk1.7.0/jre/lib/zi/Pacific/Pitcairn jdk1.7.0/jre/lib/zi/Pacific/Guadalcanal jdk1.7.0/jre/lib/zi/Pacific/Rarotonga jdk1.7.0/jre/lib/zi/Pacific/Noumea jdk1.7.0/jre/lib/zi/Pacific/Guam jdk1.7.0/jre/lib/zi/Pacific/Palau jdk1.7.0/jre/lib/zi/Pacific/Saipan jdk1.7.0/jre/lib/zi/Pacific/Apia jdk1.7.0/jre/lib/zi/Pacific/Tarawa jdk1.7.0/jre/lib/zi/Pacific/Pago_Pago jdk1.7.0/jre/lib/zi/Atlantic jdk1.7.0/jre/lib/zi/Atlantic/Azores jdk1.7.0/jre/lib/zi/Atlantic/Cape_Verde jdk1.7.0/jre/lib/zi/Atlantic/Bermuda jdk1.7.0/jre/lib/zi/Atlantic/Stanley jdk1.7.0/jre/lib/zi/Atlantic/Madeira jdk1.7.0/jre/lib/zi/Atlantic/St_Helena jdk1.7.0/jre/lib/zi/Atlantic/Canary jdk1.7.0/jre/lib/zi/Atlantic/South_Georgia jdk1.7.0/jre/lib/zi/Atlantic/Reykjavik jdk1.7.0/jre/lib/zi/Atlantic/Faroe jdk1.7.0/jre/lib/zi/America jdk1.7.0/jre/lib/zi/America/North_Dakota jdk1.7.0/jre/lib/zi/America/North_Dakota/Center jdk1.7.0/jre/lib/zi/America/North_Dakota/New_Salem jdk1.7.0/jre/lib/zi/America/Anchorage jdk1.7.0/jre/lib/zi/America/Santiago jdk1.7.0/jre/lib/zi/America/Paramaribo jdk1.7.0/jre/lib/zi/America/Godthab jdk1.7.0/jre/lib/zi/America/Detroit jdk1.7.0/jre/lib/zi/America/Rankin_Inlet jdk1.7.0/jre/lib/zi/America/La_Paz jdk1.7.0/jre/lib/zi/America/St_Lucia jdk1.7.0/jre/lib/zi/America/El_Salvador jdk1.7.0/jre/lib/zi/America/Maceio jdk1.7.0/jre/lib/zi/America/Cayenne jdk1.7.0/jre/lib/zi/America/Nassau jdk1.7.0/jre/lib/zi/America/Chicago jdk1.7.0/jre/lib/zi/America/Bogota jdk1.7.0/jre/lib/zi/America/Whitehorse jdk1.7.0/jre/lib/zi/America/Phoenix jdk1.7.0/jre/lib/zi/America/Kentucky jdk1.7.0/jre/lib/zi/America/Kentucky/Louisville jdk1.7.0/jre/lib/zi/America/Kentucky/Monticello jdk1.7.0/jre/lib/zi/America/Rainy_River jdk1.7.0/jre/lib/zi/America/Fortaleza jdk1.7.0/jre/lib/zi/America/Boise jdk1.7.0/jre/lib/zi/America/Barbados jdk1.7.0/jre/lib/zi/America/Bahia jdk1.7.0/jre/lib/zi/America/St_Thomas jdk1.7.0/jre/lib/zi/America/Moncton jdk1.7.0/jre/lib/zi/America/Cambridge_Bay jdk1.7.0/jre/lib/zi/America/Jamaica jdk1.7.0/jre/lib/zi/America/Antigua jdk1.7.0/jre/lib/zi/America/Porto_Velho jdk1.7.0/jre/lib/zi/America/Montevideo jdk1.7.0/jre/lib/zi/America/Hermosillo jdk1.7.0/jre/lib/zi/America/Dominica jdk1.7.0/jre/lib/zi/America/Tijuana jdk1.7.0/jre/lib/zi/America/Guayaquil jdk1.7.0/jre/lib/zi/America/Denver jdk1.7.0/jre/lib/zi/America/Rio_Branco jdk1.7.0/jre/lib/zi/America/Cancun jdk1.7.0/jre/lib/zi/America/Mexico_City jdk1.7.0/jre/lib/zi/America/Port-au-Prince jdk1.7.0/jre/lib/zi/America/Montserrat jdk1.7.0/jre/lib/zi/America/St_Johns jdk1.7.0/jre/lib/zi/America/Inuvik jdk1.7.0/jre/lib/zi/America/Managua jdk1.7.0/jre/lib/zi/America/Martinique jdk1.7.0/jre/lib/zi/America/Regina jdk1.7.0/jre/lib/zi/America/Toronto jdk1.7.0/jre/lib/zi/America/Indiana jdk1.7.0/jre/lib/zi/America/Indiana/Vevay jdk1.7.0/jre/lib/zi/America/Indiana/Knox jdk1.7.0/jre/lib/zi/America/Indiana/Marengo jdk1.7.0/jre/lib/zi/America/Indiana/Vincennes jdk1.7.0/jre/lib/zi/America/Indiana/Indianapolis jdk1.7.0/jre/lib/zi/America/Indiana/Winamac jdk1.7.0/jre/lib/zi/America/Indiana/Petersburg jdk1.7.0/jre/lib/zi/America/Grenada jdk1.7.0/jre/lib/zi/America/Pangnirtung jdk1.7.0/jre/lib/zi/America/St_Kitts jdk1.7.0/jre/lib/zi/America/Caracas jdk1.7.0/jre/lib/zi/America/Atikokan jdk1.7.0/jre/lib/zi/America/Monterrey jdk1.7.0/jre/lib/zi/America/Swift_Current jdk1.7.0/jre/lib/zi/America/Los_Angeles jdk1.7.0/jre/lib/zi/America/Guyana jdk1.7.0/jre/lib/zi/America/Anguilla jdk1.7.0/jre/lib/zi/America/Grand_Turk jdk1.7.0/jre/lib/zi/America/Juneau jdk1.7.0/jre/lib/zi/America/Chihuahua jdk1.7.0/jre/lib/zi/America/Merida jdk1.7.0/jre/lib/zi/America/Lima jdk1.7.0/jre/lib/zi/America/Manaus jdk1.7.0/jre/lib/zi/America/Danmarkshavn jdk1.7.0/jre/lib/zi/America/Eirunepe jdk1.7.0/jre/lib/zi/America/Araguaina jdk1.7.0/jre/lib/zi/America/Belize jdk1.7.0/jre/lib/zi/America/Tegucigalpa jdk1.7.0/jre/lib/zi/America/Miquelon jdk1.7.0/jre/lib/zi/America/Nome jdk1.7.0/jre/lib/zi/America/New_York jdk1.7.0/jre/lib/zi/America/Noronha jdk1.7.0/jre/lib/zi/America/Adak jdk1.7.0/jre/lib/zi/America/Winnipeg jdk1.7.0/jre/lib/zi/America/Thunder_Bay jdk1.7.0/jre/lib/zi/America/Dawson jdk1.7.0/jre/lib/zi/America/Yakutat jdk1.7.0/jre/lib/zi/America/Dawson_Creek jdk1.7.0/jre/lib/zi/America/Blanc-Sablon jdk1.7.0/jre/lib/zi/America/Puerto_Rico jdk1.7.0/jre/lib/zi/America/Cayman jdk1.7.0/jre/lib/zi/America/Thule jdk1.7.0/jre/lib/zi/America/Panama jdk1.7.0/jre/lib/zi/America/Nipigon jdk1.7.0/jre/lib/zi/America/Argentina jdk1.7.0/jre/lib/zi/America/Argentina/Catamarca jdk1.7.0/jre/lib/zi/America/Argentina/Rio_Gallegos jdk1.7.0/jre/lib/zi/America/Argentina/Mendoza jdk1.7.0/jre/lib/zi/America/Argentina/Ushuaia jdk1.7.0/jre/lib/zi/America/Argentina/Tucuman jdk1.7.0/jre/lib/zi/America/Argentina/Buenos_Aires jdk1.7.0/jre/lib/zi/America/Argentina/Jujuy jdk1.7.0/jre/lib/zi/America/Argentina/San_Juan jdk1.7.0/jre/lib/zi/America/Argentina/Cordoba jdk1.7.0/jre/lib/zi/America/Argentina/La_Rioja jdk1.7.0/jre/lib/zi/America/Port_of_Spain jdk1.7.0/jre/lib/zi/America/Campo_Grande jdk1.7.0/jre/lib/zi/America/Goose_Bay jdk1.7.0/jre/lib/zi/America/Cuiaba jdk1.7.0/jre/lib/zi/America/Glace_Bay jdk1.7.0/jre/lib/zi/America/Montreal jdk1.7.0/jre/lib/zi/America/Curacao jdk1.7.0/jre/lib/zi/America/Tortola jdk1.7.0/jre/lib/zi/America/Havana jdk1.7.0/jre/lib/zi/America/Asuncion jdk1.7.0/jre/lib/zi/America/Mazatlan jdk1.7.0/jre/lib/zi/America/Scoresbysund jdk1.7.0/jre/lib/zi/America/Yellowknife jdk1.7.0/jre/lib/zi/America/Aruba jdk1.7.0/jre/lib/zi/America/Edmonton jdk1.7.0/jre/lib/zi/America/Halifax jdk1.7.0/jre/lib/zi/America/Iqaluit jdk1.7.0/jre/lib/zi/America/Guadeloupe jdk1.7.0/jre/lib/zi/America/Costa_Rica jdk1.7.0/jre/lib/zi/America/Belem jdk1.7.0/jre/lib/zi/America/Santo_Domingo jdk1.7.0/jre/lib/zi/America/Sao_Paulo jdk1.7.0/jre/lib/zi/America/Boa_Vista jdk1.7.0/jre/lib/zi/America/Recife jdk1.7.0/jre/lib/zi/America/Guatemala jdk1.7.0/jre/lib/zi/America/St_Vincent jdk1.7.0/jre/lib/zi/America/Menominee jdk1.7.0/jre/lib/zi/America/Vancouver jdk1.7.0/jre/lib/zi/Indian jdk1.7.0/jre/lib/zi/Indian/Chagos jdk1.7.0/jre/lib/zi/Indian/Christmas jdk1.7.0/jre/lib/zi/Indian/Antananarivo jdk1.7.0/jre/lib/zi/Indian/Mayotte jdk1.7.0/jre/lib/zi/Indian/Comoro jdk1.7.0/jre/lib/zi/Indian/Maldives jdk1.7.0/jre/lib/zi/Indian/Cocos jdk1.7.0/jre/lib/zi/Indian/Mauritius jdk1.7.0/jre/lib/zi/Indian/Kerguelen jdk1.7.0/jre/lib/zi/Indian/Reunion jdk1.7.0/jre/lib/zi/Indian/Mahe jdk1.7.0/jre/lib/zi/ZoneInfoMappings jdk1.7.0/jre/lib/zi/MET jdk1.7.0/jre/lib/zi/PST8PDT jdk1.7.0/jre/lib/sound.properties jdk1.7.0/jre/lib/rt.jar jdk1.7.0/jre/lib/content-types.properties jdk1.7.0/jre/lib/management jdk1.7.0/jre/lib/management/jmxremote.access jdk1.7.0/jre/lib/management/snmp.acl.template jdk1.7.0/jre/lib/management/jmxremote.password.template jdk1.7.0/jre/lib/management/management.properties jdk1.7.0/jre/lib/ext jdk1.7.0/jre/lib/ext/sunjce_provider.jar jdk1.7.0/LICENSE rt.jar: META-INF/ META-INF/MANIFEST.MF com/ com/sun/ com/sun/media/ com/sun/media/sound/ com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class com/sun/media/sound/AbstractDataLine.class com/sun/media/sound/ReferenceCountingDevice.class com/sun/media/sound/HeadspaceSample.class com/sun/media/sound/RealTimeSequencer$DataPump.class com/sun/media/sound/StandardMidiFileWriter.class com/sun/media/sound/SimpleInputDevice$InputDevicePort.class com/sun/media/sound/JDK13Services$ProviderCache.class com/sun/media/sound/MidiInDeviceProvider$1.class com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class com/sun/media/sound/PortMixer$BoolCtrl$BCT.class com/sun/media/sound/UlawCodec$UlawCodecStream.class com/sun/media/sound/PortMixerProvider$PortMixerInfo.class com/sun/media/sound/SMFParser.class com/sun/media/sound/AbstractMixer.class com/sun/media/sound/HeadspaceMixer.class com/sun/media/sound/MixerSequencerProvider.class com/sun/media/sound/HeadspaceMixer$MidiLine.class com/sun/media/sound/JSSecurityManager$5.class com/sun/media/sound/MixerClip$1.class com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class com/sun/media/sound/AutoConnectSequencer.class com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class com/sun/media/sound/SunFileWriter.class com/sun/media/sound/MidiInDevice$1.class com/sun/media/sound/AbstractMidiDevice.class com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class com/sun/media/sound/RealTimeSequencer$PlayThread.class com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class com/sun/media/sound/HeadspaceSoundbank.class com/sun/media/sound/AiffFileWriter.class com/sun/media/sound/DirectAudioDevice.class com/sun/media/sound/SimpleInputDevice$1.class com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class com/sun/media/sound/Toolkit.class com/sun/media/sound/MixerSynth$SynthReceiver.class com/sun/media/sound/JDK13Services$1.class com/sun/media/sound/DirectAudioDevice$DirectDL.class com/sun/media/sound/DirectAudioDevice$DirectBAOS.class com/sun/media/sound/StandardMidiFileReader.class com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class com/sun/media/sound/MidiInDevice.class com/sun/media/sound/MidiOutDevice.class com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class com/sun/media/sound/DataPusher.class com/sun/media/sound/AbstractMidiDevice$TransmitterList.class com/sun/media/sound/HeadspaceInstrument.class com/sun/media/sound/MidiUtils$TempoCache.class com/sun/media/sound/PortMixer$FloatCtrl.class com/sun/media/sound/PortMixer$FloatCtrl$FCT.class com/sun/media/sound/JDK13Services.class com/sun/media/sound/HeadspaceMixer$1.class com/sun/media/sound/PortMixer$PortInfo.class com/sun/media/sound/EventDispatcher$EventInfo.class com/sun/media/sound/EventDispatcher$LineMonitor.class com/sun/media/sound/SimpleInputDeviceProvider$1.class com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class com/sun/media/sound/JSSecurityManager$4.class com/sun/media/sound/AlawCodec$AlawCodecStream.class com/sun/media/sound/WaveFileWriter.class com/sun/media/sound/DirectAudioDevice$DirectClip.class com/sun/media/sound/PortMixer.class com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class com/sun/media/sound/JSSecurityManager.class com/sun/media/sound/PortMixer$CompCtrl.class com/sun/media/sound/SimpleInputDeviceProvider.class com/sun/media/sound/HeadspaceMixer$MixerInfo.class com/sun/media/sound/MixerSourceLine.class com/sun/media/sound/MixerClip.class com/sun/media/sound/MidiUtils.class com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class com/sun/media/sound/MixerClip$MixerClipGainControl.class com/sun/media/sound/SunCodec.class com/sun/media/sound/AuFileWriter.class com/sun/media/sound/RealTimeSequencer.class com/sun/media/sound/AiffFileFormat.class com/sun/media/sound/MixerSynth$MixerSynthInfo.class com/sun/media/sound/MixerClip$MixerClipPanControl.class com/sun/media/sound/AbstractMidiDeviceProvider.class com/sun/media/sound/MixerThread.class com/sun/media/sound/RealTimeSequencer$1.class com/sun/media/sound/AuFileReader.class com/sun/media/sound/JavaSoundAudioClip.class com/sun/media/sound/JSSecurityManager$3.class com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class com/sun/media/sound/MidiInDeviceProvider.class com/sun/media/sound/MixerSequencer$ControllerVectorElement.class com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class com/sun/media/sound/JSSecurityManager$7.class com/sun/media/sound/UlawCodec.class com/sun/media/sound/PortMixer$1.class com/sun/media/sound/PortMixer$BoolCtrl.class com/sun/media/sound/MidiOutDeviceProvider$1.class com/sun/media/sound/AbstractMidiDeviceProvider$Info.class com/sun/media/sound/RmfFileReader.class com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class com/sun/media/sound/RealTimeSequencer$RecordingTrack.class com/sun/media/sound/AlawCodec.class com/sun/media/sound/PortMixer$CompCtrl$CCT.class com/sun/media/sound/DirectAudioDeviceProvider.class com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class com/sun/media/sound/PCMtoPCMCodec.class com/sun/media/sound/HsbParser.class com/sun/media/sound/EventDispatcher$ClipInfo.class com/sun/media/sound/MixerMidiChannel.class com/sun/media/sound/DirectAudioDevice$DirectSDL.class com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class com/sun/media/sound/MixerSequencer$RecordingTrack.class com/sun/media/sound/RealTimeSequencer$ControllerListElement.class com/sun/media/sound/MixerSourceLine$1.class com/sun/media/sound/HeadspaceMixerProvider.class com/sun/media/sound/RealTimeSequencerProvider.class com/sun/media/sound/AuFileFormat.class com/sun/media/sound/MixerSynth$1.class com/sun/media/sound/AutoClosingClip.class com/sun/media/sound/EventDispatcher.class com/sun/media/sound/AiffFileReader.class com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class com/sun/media/sound/AbstractPlayer.class com/sun/media/sound/MidiInDevice$MidiInTransmitter.class com/sun/media/sound/MixerSequencer.class com/sun/media/sound/FastSysexMessage.class com/sun/media/sound/JSSecurityManager$6.class com/sun/media/sound/WaveFileReader.class com/sun/media/sound/JSSecurityManager$2.class com/sun/media/sound/MixerSynthProvider.class com/sun/media/sound/SimpleInputDevice.class com/sun/media/sound/AbstractLine.class com/sun/media/sound/DirectAudioDevice$1.class com/sun/media/sound/MixerClip$MixerClipMuteControl.class com/sun/media/sound/SunFileReader.class com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class com/sun/media/sound/Platform.class com/sun/media/sound/DirectAudioDevice$DirectTDL.class com/sun/media/sound/PortMixerProvider.class com/sun/media/sound/CircularBuffer.class com/sun/media/sound/PortMixer$PortMixerPort.class com/sun/media/sound/DirectAudioDevice$DirectDLI.class com/sun/media/sound/MidiOutDeviceProvider.class com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class com/sun/media/sound/Printer.class com/sun/media/sound/MixerSequencer$1.class com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class com/sun/media/sound/MixerSynth.class com/sun/media/sound/FastShortMessage.class com/sun/media/sound/JSSecurityManager$1.class com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class com/sun/media/sound/WaveFileFormat.class com/sun/jmx/ com/sun/jmx/snmp/ com/sun/jmx/snmp/SnmpOpaque.class com/sun/jmx/snmp/SnmpVarBindList.class com/sun/jmx/snmp/SnmpString.class com/sun/jmx/snmp/SnmpUnknownSubSystemException.class com/sun/jmx/snmp/SnmpBadSecurityLevelException.class com/sun/jmx/snmp/BerException.class com/sun/jmx/snmp/SnmpGauge.class com/sun/jmx/snmp/SnmpEngineFactory.class com/sun/jmx/snmp/SnmpTooBigException.class com/sun/jmx/snmp/ServiceName.class com/sun/jmx/snmp/EnumRowStatus.class com/sun/jmx/snmp/SnmpDataTypeEnums.class com/sun/jmx/snmp/SnmpStringFixed.class com/sun/jmx/snmp/SnmpPduPacket.class com/sun/jmx/snmp/SnmpParams.class com/sun/jmx/snmp/SnmpSecurityException.class com/sun/jmx/snmp/SnmpEngineId.class com/sun/jmx/snmp/SnmpUnknownMsgProcModelException.class com/sun/jmx/snmp/Timestamp.class com/sun/jmx/snmp/SnmpPdu.class com/sun/jmx/snmp/SnmpVarBind.class com/sun/jmx/snmp/UserAcl.class com/sun/jmx/snmp/SnmpScopedPduPacket.class com/sun/jmx/snmp/SnmpUnknownModelException.class com/sun/jmx/snmp/SnmpIpAddress.class com/sun/jmx/snmp/SnmpUsmKeyHandler.class com/sun/jmx/snmp/SnmpScopedPduRequest.class com/sun/jmx/snmp/SnmpPduFactory.class com/sun/jmx/snmp/SnmpPduBulkType.class com/sun/jmx/snmp/SnmpPduBulk.class com/sun/jmx/snmp/SnmpPduRequest.class com/sun/jmx/snmp/BerDecoder.class com/sun/jmx/snmp/SnmpEngineParameters.class com/sun/jmx/snmp/SnmpOidTableSupport.class com/sun/jmx/snmp/SnmpOidDatabaseSupport.class com/sun/jmx/snmp/SnmpMsg.class com/sun/jmx/snmp/SnmpScopedPduBulk.class com/sun/jmx/snmp/BerEncoder.class com/sun/jmx/snmp/SnmpDefinitions.class com/sun/jmx/snmp/SnmpAckPdu.class com/sun/jmx/snmp/ThreadContext.class com/sun/jmx/snmp/SnmpUnknownAccContrModelException.class com/sun/jmx/snmp/daemon/ com/sun/jmx/snmp/daemon/SendQ.class com/sun/jmx/snmp/daemon/SnmpMibTree$1.class com/sun/jmx/snmp/daemon/SnmpMibTree$TreeNode.class com/sun/jmx/snmp/daemon/CommunicatorServer.class com/sun/jmx/snmp/daemon/CommunicationException.class com/sun/jmx/snmp/daemon/SnmpRequestHandler.class com/sun/jmx/snmp/daemon/SnmpResponseHandler.class com/sun/jmx/snmp/daemon/SnmpRequestCounter.class com/sun/jmx/snmp/daemon/SnmpSession.class com/sun/jmx/snmp/daemon/SnmpTimerServer.class com/sun/jmx/snmp/daemon/SnmpAdaptorServer.class com/sun/jmx/snmp/daemon/SnmpSendServer.class com/sun/jmx/snmp/daemon/WaitQ.class com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.class com/sun/jmx/snmp/daemon/SnmpInformRequest.class com/sun/jmx/snmp/daemon/SnmpSocket.class com/sun/jmx/snmp/daemon/SnmpSubRequestHandler$NonSyncVector.class com/sun/jmx/snmp/daemon/SnmpMibTree.class com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.class com/sun/jmx/snmp/daemon/ClientHandler.class com/sun/jmx/snmp/daemon/SnmpInformHandler.class com/sun/jmx/snmp/daemon/SnmpQManager.class com/sun/jmx/snmp/daemon/CommunicatorServerMBean.class com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.class com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.class com/sun/jmx/snmp/SnmpStatusException.class com/sun/jmx/snmp/SnmpMessage.class com/sun/jmx/snmp/SnmpV3Message.class com/sun/jmx/snmp/SnmpPduRequestType.class com/sun/jmx/snmp/InetAddressAcl.class com/sun/jmx/snmp/SnmpPeer.class com/sun/jmx/snmp/SnmpInt.class com/sun/jmx/snmp/SnmpCounter64.class com/sun/jmx/snmp/SnmpValue.class com/sun/jmx/snmp/SnmpOid.class com/sun/jmx/snmp/SnmpPduFactoryBER.class com/sun/jmx/snmp/SnmpOidRecord.class com/sun/jmx/snmp/SnmpUnknownSecModelException.class com/sun/jmx/snmp/SnmpNull.class com/sun/jmx/snmp/SnmpTimeticks.class com/sun/jmx/snmp/SnmpUnsignedInt.class com/sun/jmx/snmp/SnmpUnknownModelLcdException.class com/sun/jmx/snmp/SnmpSecurityParameters.class com/sun/jmx/snmp/SnmpParameters.class com/sun/jmx/snmp/SnmpOidDatabase.class com/sun/jmx/snmp/SnmpOidTable.class com/sun/jmx/snmp/Enumerated.class com/sun/jmx/snmp/SnmpPduTrap.class com/sun/jmx/snmp/SnmpCounter.class com/sun/jmx/snmp/SnmpEngine.class java/ java/awt/ java/awt/color/ java/awt/color/ICC_ProfileRGB.class java/awt/color/ICC_Profile$2.class java/awt/color/ICC_ColorSpace.class java/awt/color/ICC_Profile$1.class java/awt/color/ICC_ProfileGray.class java/awt/color/ProfileDataException.class java/awt/color/ICC_Profile.class java/awt/color/CMMException.class java/awt/color/ICC_Profile$3.class java/awt/color/ColorSpace.class java/awt/image/ java/awt/image/MemoryImageSource.class java/awt/image/PixelInterleavedSampleModel.class java/awt/image/ImageObserver.class java/awt/image/RenderedImage.class java/awt/image/renderable/ java/awt/image/renderable/RenderableImageProducer.class java/awt/image/renderable/RenderableImage.class java/awt/image/renderable/ParameterBlock.class java/awt/image/renderable/RenderContext.class java/awt/image/renderable/ContextualRenderedImageFactory.class java/awt/image/renderable/RenderableImageOp.class java/awt/image/renderable/RenderedImageFactory.class java/awt/image/ColorModel.class java/awt/image/AffineTransformOp.class java/awt/image/ImageProducer.class java/awt/image/ImageConsumer.class java/awt/image/LookupTable.class java/awt/image/DataBufferDouble.class java/awt/image/DataBufferFloat.class java/awt/image/ComponentColorModel.class java/awt/image/BandedSampleModel.class java/awt/image/WritableRenderedImage.class java/awt/image/CropImageFilter.class java/awt/image/TileObserver.class java/awt/image/ReplicateScaleFilter.class java/awt/image/BufferedImageFilter.class java/awt/image/VolatileImage.class java/awt/image/RasterFormatException.class java/awt/image/AreaAveragingScaleFilter.class java/awt/image/SinglePixelPackedSampleModel.class java/awt/image/LookupOp.class java/awt/image/ConvolveOp.class java/awt/image/PixelGrabber.class java/awt/image/BufferedImageOp.class java/awt/image/BufferedImage.class java/awt/image/DataBufferUShort.class java/awt/image/ShortLookupTable.class java/awt/image/ImageFilter.class java/awt/image/DataBufferByte.class java/awt/image/MultiPixelPackedSampleModel.class java/awt/image/IndexColorModel.class java/awt/image/RGBImageFilter.class java/awt/image/FilteredImageSource.class java/awt/image/DataBuffer.class java/awt/image/RescaleOp.class java/awt/image/Raster.class java/awt/image/SampleModel.class java/awt/image/WritableRaster.class java/awt/image/ColorConvertOp.class java/awt/image/DirectColorModel.class java/awt/image/Kernel.class java/awt/image/ByteLookupTable.class java/awt/image/DataBufferInt.class java/awt/image/RasterOp.class java/awt/image/ComponentSampleModel.class java/awt/image/BandCombineOp.class java/awt/image/BufferStrategy.class java/awt/image/PackedColorModel.class java/awt/image/DataBuffer$1.class java/awt/image/ImagingOpException.class java/awt/image/DataBufferShort.class sun/ sun/dc/ sun/dc/pr/ sun/dc/pr/PathFiller.class sun/dc/pr/PRException.class sun/dc/pr/PRError.class sun/dc/pr/PathStroker.class sun/dc/pr/Rasterizer$ConsumerDisposer.class sun/dc/pr/Rasterizer.class sun/dc/pr/PathDasher.class sun/dc/path/ sun/dc/path/PathConsumer.class sun/dc/path/FastPathProducer.class sun/dc/path/PathError.class sun/dc/path/PathException.class From Kelly.Ohair at Sun.COM Tue May 15 20:10:28 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 15 May 2007 13:10:28 -0700 Subject: Why are the binay plugs so big? In-Reply-To: <464951C3.7070005@yahoo.com> References: <464951C3.7070005@yahoo.com> Message-ID: <464A13B4.3030903@sun.com> Your observations are correct. Initially it wasn't 100% clear what binary plugs were necessary, and it was easiest to just refer to a previously built jdk install tree. Given more time these bundles would have been stripped down to the bare minimum, and that may still happen in the future. But would you rather we spent our time getting rid of the binary plug dependency, or reducing it's size? -kto Lars wrote: > After looking through the Makefiles (mostly Release.gmk) I was able to > build OpenJDK on Linux with ~4MB of binary plugs (unpacked), which is > only a fraction of a provided plugs which weigh in with over 170MB > (unpacked). > > The following list of files (and contents of rt.jar) should be pretty > universal and not just for Linux. rt.jar can even be reduced a little > further. > > So the obvious question: Why are the Sun provided binary plug so huge? > > Files: > jdk1.7.0/ > jdk1.7.0/jre > jdk1.7.0/jre/COPYRIGHT > jdk1.7.0/jre/LICENSE > jdk1.7.0/jre/lib > jdk1.7.0/jre/lib/jce.jar > jdk1.7.0/jre/lib/applet > jdk1.7.0/jre/lib/net.properties > jdk1.7.0/jre/lib/logging.properties > jdk1.7.0/jre/lib/flavormap.properties > jdk1.7.0/jre/lib/jvm.hprof.txt > jdk1.7.0/jre/lib/i386 > jdk1.7.0/jre/lib/i386/jvm.cfg > jdk1.7.0/jre/lib/i386/libdcpr.so > jdk1.7.0/jre/lib/i386/libjsoundalsa.so > jdk1.7.0/jre/lib/i386/libjsound.so > jdk1.7.0/jre/lib/i386/libt2k.so > jdk1.7.0/jre/lib/images > jdk1.7.0/jre/lib/images/cursors > jdk1.7.0/jre/lib/images/cursors/motif_LinkNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_MoveNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/cursors.properties > jdk1.7.0/jre/lib/images/cursors/motif_CopyDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_LinkDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_CopyNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_MoveDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/invalid32x32.gif > jdk1.7.0/jre/lib/classlist > jdk1.7.0/jre/lib/security > jdk1.7.0/jre/lib/security/java.policy > jdk1.7.0/jre/lib/security/US_export_policy.jar > jdk1.7.0/jre/lib/security/local_policy.jar > jdk1.7.0/jre/lib/security/java.security > jdk1.7.0/jre/lib/audio > jdk1.7.0/jre/lib/audio/soundbank.gm > jdk1.7.0/jre/lib/zi > jdk1.7.0/jre/lib/zi/Asia > jdk1.7.0/jre/lib/zi/Asia/Dili > jdk1.7.0/jre/lib/zi/Asia/Magadan > jdk1.7.0/jre/lib/zi/Asia/Muscat > jdk1.7.0/jre/lib/zi/Asia/Karachi > jdk1.7.0/jre/lib/zi/Asia/Manila > jdk1.7.0/jre/lib/zi/Asia/Katmandu > jdk1.7.0/jre/lib/zi/Asia/Bahrain > jdk1.7.0/jre/lib/zi/Asia/Dushanbe > jdk1.7.0/jre/lib/zi/Asia/Saigon > jdk1.7.0/jre/lib/zi/Asia/Anadyr > jdk1.7.0/jre/lib/zi/Asia/Rangoon > jdk1.7.0/jre/lib/zi/Asia/Tashkent > jdk1.7.0/jre/lib/zi/Asia/Amman > jdk1.7.0/jre/lib/zi/Asia/Oral > jdk1.7.0/jre/lib/zi/Asia/Calcutta > jdk1.7.0/jre/lib/zi/Asia/Jakarta > jdk1.7.0/jre/lib/zi/Asia/Aqtau > jdk1.7.0/jre/lib/zi/Asia/Dubai > jdk1.7.0/jre/lib/zi/Asia/Ashgabat > jdk1.7.0/jre/lib/zi/Asia/Beirut > jdk1.7.0/jre/lib/zi/Asia/Hovd > jdk1.7.0/jre/lib/zi/Asia/Jayapura > jdk1.7.0/jre/lib/zi/Asia/Samarkand > jdk1.7.0/jre/lib/zi/Asia/Krasnoyarsk > jdk1.7.0/jre/lib/zi/Asia/Aqtobe > jdk1.7.0/jre/lib/zi/Asia/Omsk > jdk1.7.0/jre/lib/zi/Asia/Seoul > jdk1.7.0/jre/lib/zi/Asia/Bishkek > jdk1.7.0/jre/lib/zi/Asia/Thimphu > jdk1.7.0/jre/lib/zi/Asia/Novosibirsk > jdk1.7.0/jre/lib/zi/Asia/Kabul > jdk1.7.0/jre/lib/zi/Asia/Baku > jdk1.7.0/jre/lib/zi/Asia/Riyadh88 > jdk1.7.0/jre/lib/zi/Asia/Tehran > jdk1.7.0/jre/lib/zi/Asia/Taipei > jdk1.7.0/jre/lib/zi/Asia/Makassar > jdk1.7.0/jre/lib/zi/Asia/Yakutsk > jdk1.7.0/jre/lib/zi/Asia/Tokyo > jdk1.7.0/jre/lib/zi/Asia/Urumqi > jdk1.7.0/jre/lib/zi/Asia/Kuala_Lumpur > jdk1.7.0/jre/lib/zi/Asia/Riyadh89 > jdk1.7.0/jre/lib/zi/Asia/Kuwait > jdk1.7.0/jre/lib/zi/Asia/Brunei > jdk1.7.0/jre/lib/zi/Asia/Shanghai > jdk1.7.0/jre/lib/zi/Asia/Ulaanbaatar > jdk1.7.0/jre/lib/zi/Asia/Aden > jdk1.7.0/jre/lib/zi/Asia/Choibalsan > jdk1.7.0/jre/lib/zi/Asia/Qyzylorda > jdk1.7.0/jre/lib/zi/Asia/Tbilisi > jdk1.7.0/jre/lib/zi/Asia/Vientiane > jdk1.7.0/jre/lib/zi/Asia/Macau > jdk1.7.0/jre/lib/zi/Asia/Vladivostok > jdk1.7.0/jre/lib/zi/Asia/Yerevan > jdk1.7.0/jre/lib/zi/Asia/Gaza > jdk1.7.0/jre/lib/zi/Asia/Phnom_Penh > jdk1.7.0/jre/lib/zi/Asia/Bangkok > jdk1.7.0/jre/lib/zi/Asia/Harbin > jdk1.7.0/jre/lib/zi/Asia/Kashgar > jdk1.7.0/jre/lib/zi/Asia/Baghdad > jdk1.7.0/jre/lib/zi/Asia/Damascus > jdk1.7.0/jre/lib/zi/Asia/Nicosia > jdk1.7.0/jre/lib/zi/Asia/Jerusalem > jdk1.7.0/jre/lib/zi/Asia/Singapore > jdk1.7.0/jre/lib/zi/Asia/Pontianak > jdk1.7.0/jre/lib/zi/Asia/Qatar > jdk1.7.0/jre/lib/zi/Asia/Dhaka > jdk1.7.0/jre/lib/zi/Asia/Almaty > jdk1.7.0/jre/lib/zi/Asia/Chongqing > jdk1.7.0/jre/lib/zi/Asia/Hong_Kong > jdk1.7.0/jre/lib/zi/Asia/Yekaterinburg > jdk1.7.0/jre/lib/zi/Asia/Riyadh > jdk1.7.0/jre/lib/zi/Asia/Pyongyang > jdk1.7.0/jre/lib/zi/Asia/Kamchatka > jdk1.7.0/jre/lib/zi/Asia/Irkutsk > jdk1.7.0/jre/lib/zi/Asia/Riyadh87 > jdk1.7.0/jre/lib/zi/Asia/Sakhalin > jdk1.7.0/jre/lib/zi/Asia/Kuching > jdk1.7.0/jre/lib/zi/Asia/Colombo > jdk1.7.0/jre/lib/zi/HST > jdk1.7.0/jre/lib/zi/GMT > jdk1.7.0/jre/lib/zi/Antarctica > jdk1.7.0/jre/lib/zi/Antarctica/DumontDUrville > jdk1.7.0/jre/lib/zi/Antarctica/Mawson > jdk1.7.0/jre/lib/zi/Antarctica/Davis > jdk1.7.0/jre/lib/zi/Antarctica/Rothera > jdk1.7.0/jre/lib/zi/Antarctica/McMurdo > jdk1.7.0/jre/lib/zi/Antarctica/Palmer > jdk1.7.0/jre/lib/zi/Antarctica/Syowa > jdk1.7.0/jre/lib/zi/Antarctica/Casey > jdk1.7.0/jre/lib/zi/Antarctica/Vostok > jdk1.7.0/jre/lib/zi/EST > jdk1.7.0/jre/lib/zi/CST6CDT > jdk1.7.0/jre/lib/zi/CET > jdk1.7.0/jre/lib/zi/MST7MDT > jdk1.7.0/jre/lib/zi/Australia > jdk1.7.0/jre/lib/zi/Australia/Broken_Hill > jdk1.7.0/jre/lib/zi/Australia/Lord_Howe > jdk1.7.0/jre/lib/zi/Australia/Melbourne > jdk1.7.0/jre/lib/zi/Australia/Brisbane > jdk1.7.0/jre/lib/zi/Australia/Darwin > jdk1.7.0/jre/lib/zi/Australia/Lindeman > jdk1.7.0/jre/lib/zi/Australia/Eucla > jdk1.7.0/jre/lib/zi/Australia/Adelaide > jdk1.7.0/jre/lib/zi/Australia/Hobart > jdk1.7.0/jre/lib/zi/Australia/Perth > jdk1.7.0/jre/lib/zi/Australia/Currie > jdk1.7.0/jre/lib/zi/Australia/Sydney > jdk1.7.0/jre/lib/zi/SystemV > jdk1.7.0/jre/lib/zi/SystemV/CST6CDT > jdk1.7.0/jre/lib/zi/SystemV/HST10 > jdk1.7.0/jre/lib/zi/SystemV/PST8 > jdk1.7.0/jre/lib/zi/SystemV/MST7MDT > jdk1.7.0/jre/lib/zi/SystemV/AST4ADT > jdk1.7.0/jre/lib/zi/SystemV/CST6 > jdk1.7.0/jre/lib/zi/SystemV/EST5EDT > jdk1.7.0/jre/lib/zi/SystemV/YST9 > jdk1.7.0/jre/lib/zi/SystemV/YST9YDT > jdk1.7.0/jre/lib/zi/SystemV/MST7 > jdk1.7.0/jre/lib/zi/SystemV/EST5 > jdk1.7.0/jre/lib/zi/SystemV/AST4 > jdk1.7.0/jre/lib/zi/SystemV/PST8PDT > jdk1.7.0/jre/lib/zi/MST > jdk1.7.0/jre/lib/zi/WET > jdk1.7.0/jre/lib/zi/Europe > jdk1.7.0/jre/lib/zi/Europe/Amsterdam > jdk1.7.0/jre/lib/zi/Europe/Berlin > jdk1.7.0/jre/lib/zi/Europe/Brussels > jdk1.7.0/jre/lib/zi/Europe/Rome > jdk1.7.0/jre/lib/zi/Europe/Sofia > jdk1.7.0/jre/lib/zi/Europe/Warsaw > jdk1.7.0/jre/lib/zi/Europe/London > jdk1.7.0/jre/lib/zi/Europe/Monaco > jdk1.7.0/jre/lib/zi/Europe/Kaliningrad > jdk1.7.0/jre/lib/zi/Europe/Zaporozhye > jdk1.7.0/jre/lib/zi/Europe/Riga > jdk1.7.0/jre/lib/zi/Europe/Tirane > jdk1.7.0/jre/lib/zi/Europe/Kiev > jdk1.7.0/jre/lib/zi/Europe/Istanbul > jdk1.7.0/jre/lib/zi/Europe/Belgrade > jdk1.7.0/jre/lib/zi/Europe/Paris > jdk1.7.0/jre/lib/zi/Europe/Gibraltar > jdk1.7.0/jre/lib/zi/Europe/Bucharest > jdk1.7.0/jre/lib/zi/Europe/Vienna > jdk1.7.0/jre/lib/zi/Europe/Samara > jdk1.7.0/jre/lib/zi/Europe/Vaduz > jdk1.7.0/jre/lib/zi/Europe/Zurich > jdk1.7.0/jre/lib/zi/Europe/Dublin > jdk1.7.0/jre/lib/zi/Europe/Madrid > jdk1.7.0/jre/lib/zi/Europe/Volgograd > jdk1.7.0/jre/lib/zi/Europe/Oslo > jdk1.7.0/jre/lib/zi/Europe/Malta > jdk1.7.0/jre/lib/zi/Europe/Moscow > jdk1.7.0/jre/lib/zi/Europe/Luxembourg > jdk1.7.0/jre/lib/zi/Europe/Athens > jdk1.7.0/jre/lib/zi/Europe/Prague > jdk1.7.0/jre/lib/zi/Europe/Lisbon > jdk1.7.0/jre/lib/zi/Europe/Stockholm > jdk1.7.0/jre/lib/zi/Europe/Vilnius > jdk1.7.0/jre/lib/zi/Europe/Uzhgorod > jdk1.7.0/jre/lib/zi/Europe/Tallinn > jdk1.7.0/jre/lib/zi/Europe/Helsinki > jdk1.7.0/jre/lib/zi/Europe/Minsk > jdk1.7.0/jre/lib/zi/Europe/Simferopol > jdk1.7.0/jre/lib/zi/Europe/Copenhagen > jdk1.7.0/jre/lib/zi/Europe/Budapest > jdk1.7.0/jre/lib/zi/Europe/Chisinau > jdk1.7.0/jre/lib/zi/Europe/Andorra > jdk1.7.0/jre/lib/zi/Africa > jdk1.7.0/jre/lib/zi/Africa/Bangui > jdk1.7.0/jre/lib/zi/Africa/Windhoek > jdk1.7.0/jre/lib/zi/Africa/Sao_Tome > jdk1.7.0/jre/lib/zi/Africa/Ouagadougou > jdk1.7.0/jre/lib/zi/Africa/Algiers > jdk1.7.0/jre/lib/zi/Africa/Ndjamena > jdk1.7.0/jre/lib/zi/Africa/Banjul > jdk1.7.0/jre/lib/zi/Africa/Ceuta > jdk1.7.0/jre/lib/zi/Africa/Djibouti > jdk1.7.0/jre/lib/zi/Africa/Nairobi > jdk1.7.0/jre/lib/zi/Africa/Kampala > jdk1.7.0/jre/lib/zi/Africa/Brazzaville > jdk1.7.0/jre/lib/zi/Africa/Lagos > jdk1.7.0/jre/lib/zi/Africa/Harare > jdk1.7.0/jre/lib/zi/Africa/Lubumbashi > jdk1.7.0/jre/lib/zi/Africa/Dakar > jdk1.7.0/jre/lib/zi/Africa/Monrovia > jdk1.7.0/jre/lib/zi/Africa/Lome > jdk1.7.0/jre/lib/zi/Africa/Asmara > jdk1.7.0/jre/lib/zi/Africa/Luanda > jdk1.7.0/jre/lib/zi/Africa/Lusaka > jdk1.7.0/jre/lib/zi/Africa/Libreville > jdk1.7.0/jre/lib/zi/Africa/El_Aaiun > jdk1.7.0/jre/lib/zi/Africa/Mbabane > jdk1.7.0/jre/lib/zi/Africa/Blantyre > jdk1.7.0/jre/lib/zi/Africa/Mogadishu > jdk1.7.0/jre/lib/zi/Africa/Maputo > jdk1.7.0/jre/lib/zi/Africa/Johannesburg > jdk1.7.0/jre/lib/zi/Africa/Douala > jdk1.7.0/jre/lib/zi/Africa/Maseru > jdk1.7.0/jre/lib/zi/Africa/Addis_Ababa > jdk1.7.0/jre/lib/zi/Africa/Freetown > jdk1.7.0/jre/lib/zi/Africa/Accra > jdk1.7.0/jre/lib/zi/Africa/Bamako > jdk1.7.0/jre/lib/zi/Africa/Niamey > jdk1.7.0/jre/lib/zi/Africa/Bissau > jdk1.7.0/jre/lib/zi/Africa/Conakry > jdk1.7.0/jre/lib/zi/Africa/Bujumbura > jdk1.7.0/jre/lib/zi/Africa/Tunis > jdk1.7.0/jre/lib/zi/Africa/Abidjan > jdk1.7.0/jre/lib/zi/Africa/Malabo > jdk1.7.0/jre/lib/zi/Africa/Cairo > jdk1.7.0/jre/lib/zi/Africa/Porto-Novo > jdk1.7.0/jre/lib/zi/Africa/Nouakchott > jdk1.7.0/jre/lib/zi/Africa/Casablanca > jdk1.7.0/jre/lib/zi/Africa/Dar_es_Salaam > jdk1.7.0/jre/lib/zi/Africa/Tripoli > jdk1.7.0/jre/lib/zi/Africa/Khartoum > jdk1.7.0/jre/lib/zi/Africa/Kinshasa > jdk1.7.0/jre/lib/zi/Africa/Kigali > jdk1.7.0/jre/lib/zi/Africa/Gaborone > jdk1.7.0/jre/lib/zi/EET > jdk1.7.0/jre/lib/zi/EST5EDT > jdk1.7.0/jre/lib/zi/Etc > jdk1.7.0/jre/lib/zi/Etc/GMT > jdk1.7.0/jre/lib/zi/Etc/GMT+5 > jdk1.7.0/jre/lib/zi/Etc/GMT-13 > jdk1.7.0/jre/lib/zi/Etc/GMT+12 > jdk1.7.0/jre/lib/zi/Etc/GMT+11 > jdk1.7.0/jre/lib/zi/Etc/GMT-6 > jdk1.7.0/jre/lib/zi/Etc/GMT-4 > jdk1.7.0/jre/lib/zi/Etc/GMT-12 > jdk1.7.0/jre/lib/zi/Etc/GMT-8 > jdk1.7.0/jre/lib/zi/Etc/GMT+1 > jdk1.7.0/jre/lib/zi/Etc/GMT+8 > jdk1.7.0/jre/lib/zi/Etc/GMT+2 > jdk1.7.0/jre/lib/zi/Etc/GMT-10 > jdk1.7.0/jre/lib/zi/Etc/GMT-11 > jdk1.7.0/jre/lib/zi/Etc/UCT > jdk1.7.0/jre/lib/zi/Etc/GMT-3 > jdk1.7.0/jre/lib/zi/Etc/GMT+9 > jdk1.7.0/jre/lib/zi/Etc/GMT-1 > jdk1.7.0/jre/lib/zi/Etc/GMT-2 > jdk1.7.0/jre/lib/zi/Etc/GMT-14 > jdk1.7.0/jre/lib/zi/Etc/GMT+6 > jdk1.7.0/jre/lib/zi/Etc/GMT+3 > jdk1.7.0/jre/lib/zi/Etc/GMT-5 > jdk1.7.0/jre/lib/zi/Etc/GMT+4 > jdk1.7.0/jre/lib/zi/Etc/GMT-9 > jdk1.7.0/jre/lib/zi/Etc/GMT+7 > jdk1.7.0/jre/lib/zi/Etc/UTC > jdk1.7.0/jre/lib/zi/Etc/GMT+10 > jdk1.7.0/jre/lib/zi/Etc/GMT-7 > jdk1.7.0/jre/lib/zi/Pacific > jdk1.7.0/jre/lib/zi/Pacific/Honolulu > jdk1.7.0/jre/lib/zi/Pacific/Kiritimati > jdk1.7.0/jre/lib/zi/Pacific/Midway > jdk1.7.0/jre/lib/zi/Pacific/Nauru > jdk1.7.0/jre/lib/zi/Pacific/Johnston > jdk1.7.0/jre/lib/zi/Pacific/Ponape > jdk1.7.0/jre/lib/zi/Pacific/Galapagos > jdk1.7.0/jre/lib/zi/Pacific/Auckland > jdk1.7.0/jre/lib/zi/Pacific/Wake > jdk1.7.0/jre/lib/zi/Pacific/Tongatapu > jdk1.7.0/jre/lib/zi/Pacific/Chatham > jdk1.7.0/jre/lib/zi/Pacific/Wallis > jdk1.7.0/jre/lib/zi/Pacific/Truk > jdk1.7.0/jre/lib/zi/Pacific/Efate > jdk1.7.0/jre/lib/zi/Pacific/Fiji > jdk1.7.0/jre/lib/zi/Pacific/Port_Moresby > jdk1.7.0/jre/lib/zi/Pacific/Marquesas > jdk1.7.0/jre/lib/zi/Pacific/Tahiti > jdk1.7.0/jre/lib/zi/Pacific/Funafuti > jdk1.7.0/jre/lib/zi/Pacific/Niue > jdk1.7.0/jre/lib/zi/Pacific/Easter > jdk1.7.0/jre/lib/zi/Pacific/Gambier > jdk1.7.0/jre/lib/zi/Pacific/Kosrae > jdk1.7.0/jre/lib/zi/Pacific/Norfolk > jdk1.7.0/jre/lib/zi/Pacific/Fakaofo > jdk1.7.0/jre/lib/zi/Pacific/Majuro > jdk1.7.0/jre/lib/zi/Pacific/Enderbury > jdk1.7.0/jre/lib/zi/Pacific/Kwajalein > jdk1.7.0/jre/lib/zi/Pacific/Pitcairn > jdk1.7.0/jre/lib/zi/Pacific/Guadalcanal > jdk1.7.0/jre/lib/zi/Pacific/Rarotonga > jdk1.7.0/jre/lib/zi/Pacific/Noumea > jdk1.7.0/jre/lib/zi/Pacific/Guam > jdk1.7.0/jre/lib/zi/Pacific/Palau > jdk1.7.0/jre/lib/zi/Pacific/Saipan > jdk1.7.0/jre/lib/zi/Pacific/Apia > jdk1.7.0/jre/lib/zi/Pacific/Tarawa > jdk1.7.0/jre/lib/zi/Pacific/Pago_Pago > jdk1.7.0/jre/lib/zi/Atlantic > jdk1.7.0/jre/lib/zi/Atlantic/Azores > jdk1.7.0/jre/lib/zi/Atlantic/Cape_Verde > jdk1.7.0/jre/lib/zi/Atlantic/Bermuda > jdk1.7.0/jre/lib/zi/Atlantic/Stanley > jdk1.7.0/jre/lib/zi/Atlantic/Madeira > jdk1.7.0/jre/lib/zi/Atlantic/St_Helena > jdk1.7.0/jre/lib/zi/Atlantic/Canary > jdk1.7.0/jre/lib/zi/Atlantic/South_Georgia > jdk1.7.0/jre/lib/zi/Atlantic/Reykjavik > jdk1.7.0/jre/lib/zi/Atlantic/Faroe > jdk1.7.0/jre/lib/zi/America > jdk1.7.0/jre/lib/zi/America/North_Dakota > jdk1.7.0/jre/lib/zi/America/North_Dakota/Center > jdk1.7.0/jre/lib/zi/America/North_Dakota/New_Salem > jdk1.7.0/jre/lib/zi/America/Anchorage > jdk1.7.0/jre/lib/zi/America/Santiago > jdk1.7.0/jre/lib/zi/America/Paramaribo > jdk1.7.0/jre/lib/zi/America/Godthab > jdk1.7.0/jre/lib/zi/America/Detroit > jdk1.7.0/jre/lib/zi/America/Rankin_Inlet > jdk1.7.0/jre/lib/zi/America/La_Paz > jdk1.7.0/jre/lib/zi/America/St_Lucia > jdk1.7.0/jre/lib/zi/America/El_Salvador > jdk1.7.0/jre/lib/zi/America/Maceio > jdk1.7.0/jre/lib/zi/America/Cayenne > jdk1.7.0/jre/lib/zi/America/Nassau > jdk1.7.0/jre/lib/zi/America/Chicago > jdk1.7.0/jre/lib/zi/America/Bogota > jdk1.7.0/jre/lib/zi/America/Whitehorse > jdk1.7.0/jre/lib/zi/America/Phoenix > jdk1.7.0/jre/lib/zi/America/Kentucky > jdk1.7.0/jre/lib/zi/America/Kentucky/Louisville > jdk1.7.0/jre/lib/zi/America/Kentucky/Monticello > jdk1.7.0/jre/lib/zi/America/Rainy_River > jdk1.7.0/jre/lib/zi/America/Fortaleza > jdk1.7.0/jre/lib/zi/America/Boise > jdk1.7.0/jre/lib/zi/America/Barbados > jdk1.7.0/jre/lib/zi/America/Bahia > jdk1.7.0/jre/lib/zi/America/St_Thomas > jdk1.7.0/jre/lib/zi/America/Moncton > jdk1.7.0/jre/lib/zi/America/Cambridge_Bay > jdk1.7.0/jre/lib/zi/America/Jamaica > jdk1.7.0/jre/lib/zi/America/Antigua > jdk1.7.0/jre/lib/zi/America/Porto_Velho > jdk1.7.0/jre/lib/zi/America/Montevideo > jdk1.7.0/jre/lib/zi/America/Hermosillo > jdk1.7.0/jre/lib/zi/America/Dominica > jdk1.7.0/jre/lib/zi/America/Tijuana > jdk1.7.0/jre/lib/zi/America/Guayaquil > jdk1.7.0/jre/lib/zi/America/Denver > jdk1.7.0/jre/lib/zi/America/Rio_Branco > jdk1.7.0/jre/lib/zi/America/Cancun > jdk1.7.0/jre/lib/zi/America/Mexico_City > jdk1.7.0/jre/lib/zi/America/Port-au-Prince > jdk1.7.0/jre/lib/zi/America/Montserrat > jdk1.7.0/jre/lib/zi/America/St_Johns > jdk1.7.0/jre/lib/zi/America/Inuvik > jdk1.7.0/jre/lib/zi/America/Managua > jdk1.7.0/jre/lib/zi/America/Martinique > jdk1.7.0/jre/lib/zi/America/Regina > jdk1.7.0/jre/lib/zi/America/Toronto > jdk1.7.0/jre/lib/zi/America/Indiana > jdk1.7.0/jre/lib/zi/America/Indiana/Vevay > jdk1.7.0/jre/lib/zi/America/Indiana/Knox > jdk1.7.0/jre/lib/zi/America/Indiana/Marengo > jdk1.7.0/jre/lib/zi/America/Indiana/Vincennes > jdk1.7.0/jre/lib/zi/America/Indiana/Indianapolis > jdk1.7.0/jre/lib/zi/America/Indiana/Winamac > jdk1.7.0/jre/lib/zi/America/Indiana/Petersburg > jdk1.7.0/jre/lib/zi/America/Grenada > jdk1.7.0/jre/lib/zi/America/Pangnirtung > jdk1.7.0/jre/lib/zi/America/St_Kitts > jdk1.7.0/jre/lib/zi/America/Caracas > jdk1.7.0/jre/lib/zi/America/Atikokan > jdk1.7.0/jre/lib/zi/America/Monterrey > jdk1.7.0/jre/lib/zi/America/Swift_Current > jdk1.7.0/jre/lib/zi/America/Los_Angeles > jdk1.7.0/jre/lib/zi/America/Guyana > jdk1.7.0/jre/lib/zi/America/Anguilla > jdk1.7.0/jre/lib/zi/America/Grand_Turk > jdk1.7.0/jre/lib/zi/America/Juneau > jdk1.7.0/jre/lib/zi/America/Chihuahua > jdk1.7.0/jre/lib/zi/America/Merida > jdk1.7.0/jre/lib/zi/America/Lima > jdk1.7.0/jre/lib/zi/America/Manaus > jdk1.7.0/jre/lib/zi/America/Danmarkshavn > jdk1.7.0/jre/lib/zi/America/Eirunepe > jdk1.7.0/jre/lib/zi/America/Araguaina > jdk1.7.0/jre/lib/zi/America/Belize > jdk1.7.0/jre/lib/zi/America/Tegucigalpa > jdk1.7.0/jre/lib/zi/America/Miquelon > jdk1.7.0/jre/lib/zi/America/Nome > jdk1.7.0/jre/lib/zi/America/New_York > jdk1.7.0/jre/lib/zi/America/Noronha > jdk1.7.0/jre/lib/zi/America/Adak > jdk1.7.0/jre/lib/zi/America/Winnipeg > jdk1.7.0/jre/lib/zi/America/Thunder_Bay > jdk1.7.0/jre/lib/zi/America/Dawson > jdk1.7.0/jre/lib/zi/America/Yakutat > jdk1.7.0/jre/lib/zi/America/Dawson_Creek > jdk1.7.0/jre/lib/zi/America/Blanc-Sablon > jdk1.7.0/jre/lib/zi/America/Puerto_Rico > jdk1.7.0/jre/lib/zi/America/Cayman > jdk1.7.0/jre/lib/zi/America/Thule > jdk1.7.0/jre/lib/zi/America/Panama > jdk1.7.0/jre/lib/zi/America/Nipigon > jdk1.7.0/jre/lib/zi/America/Argentina > jdk1.7.0/jre/lib/zi/America/Argentina/Catamarca > jdk1.7.0/jre/lib/zi/America/Argentina/Rio_Gallegos > jdk1.7.0/jre/lib/zi/America/Argentina/Mendoza > jdk1.7.0/jre/lib/zi/America/Argentina/Ushuaia > jdk1.7.0/jre/lib/zi/America/Argentina/Tucuman > jdk1.7.0/jre/lib/zi/America/Argentina/Buenos_Aires > jdk1.7.0/jre/lib/zi/America/Argentina/Jujuy > jdk1.7.0/jre/lib/zi/America/Argentina/San_Juan > jdk1.7.0/jre/lib/zi/America/Argentina/Cordoba > jdk1.7.0/jre/lib/zi/America/Argentina/La_Rioja > jdk1.7.0/jre/lib/zi/America/Port_of_Spain > jdk1.7.0/jre/lib/zi/America/Campo_Grande > jdk1.7.0/jre/lib/zi/America/Goose_Bay > jdk1.7.0/jre/lib/zi/America/Cuiaba > jdk1.7.0/jre/lib/zi/America/Glace_Bay > jdk1.7.0/jre/lib/zi/America/Montreal > jdk1.7.0/jre/lib/zi/America/Curacao > jdk1.7.0/jre/lib/zi/America/Tortola > jdk1.7.0/jre/lib/zi/America/Havana > jdk1.7.0/jre/lib/zi/America/Asuncion > jdk1.7.0/jre/lib/zi/America/Mazatlan > jdk1.7.0/jre/lib/zi/America/Scoresbysund > jdk1.7.0/jre/lib/zi/America/Yellowknife > jdk1.7.0/jre/lib/zi/America/Aruba > jdk1.7.0/jre/lib/zi/America/Edmonton > jdk1.7.0/jre/lib/zi/America/Halifax > jdk1.7.0/jre/lib/zi/America/Iqaluit > jdk1.7.0/jre/lib/zi/America/Guadeloupe > jdk1.7.0/jre/lib/zi/America/Costa_Rica > jdk1.7.0/jre/lib/zi/America/Belem > jdk1.7.0/jre/lib/zi/America/Santo_Domingo > jdk1.7.0/jre/lib/zi/America/Sao_Paulo > jdk1.7.0/jre/lib/zi/America/Boa_Vista > jdk1.7.0/jre/lib/zi/America/Recife > jdk1.7.0/jre/lib/zi/America/Guatemala > jdk1.7.0/jre/lib/zi/America/St_Vincent > jdk1.7.0/jre/lib/zi/America/Menominee > jdk1.7.0/jre/lib/zi/America/Vancouver > jdk1.7.0/jre/lib/zi/Indian > jdk1.7.0/jre/lib/zi/Indian/Chagos > jdk1.7.0/jre/lib/zi/Indian/Christmas > jdk1.7.0/jre/lib/zi/Indian/Antananarivo > jdk1.7.0/jre/lib/zi/Indian/Mayotte > jdk1.7.0/jre/lib/zi/Indian/Comoro > jdk1.7.0/jre/lib/zi/Indian/Maldives > jdk1.7.0/jre/lib/zi/Indian/Cocos > jdk1.7.0/jre/lib/zi/Indian/Mauritius > jdk1.7.0/jre/lib/zi/Indian/Kerguelen > jdk1.7.0/jre/lib/zi/Indian/Reunion > jdk1.7.0/jre/lib/zi/Indian/Mahe > jdk1.7.0/jre/lib/zi/ZoneInfoMappings > jdk1.7.0/jre/lib/zi/MET > jdk1.7.0/jre/lib/zi/PST8PDT > jdk1.7.0/jre/lib/sound.properties > jdk1.7.0/jre/lib/rt.jar > jdk1.7.0/jre/lib/content-types.properties > jdk1.7.0/jre/lib/management > jdk1.7.0/jre/lib/management/jmxremote.access > jdk1.7.0/jre/lib/management/snmp.acl.template > jdk1.7.0/jre/lib/management/jmxremote.password.template > jdk1.7.0/jre/lib/management/management.properties > jdk1.7.0/jre/lib/ext > jdk1.7.0/jre/lib/ext/sunjce_provider.jar > jdk1.7.0/LICENSE > > rt.jar: > META-INF/ > META-INF/MANIFEST.MF > com/ > com/sun/ > com/sun/media/ > com/sun/media/sound/ > com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class > com/sun/media/sound/AbstractDataLine.class > com/sun/media/sound/ReferenceCountingDevice.class > com/sun/media/sound/HeadspaceSample.class > com/sun/media/sound/RealTimeSequencer$DataPump.class > com/sun/media/sound/StandardMidiFileWriter.class > com/sun/media/sound/SimpleInputDevice$InputDevicePort.class > com/sun/media/sound/JDK13Services$ProviderCache.class > com/sun/media/sound/MidiInDeviceProvider$1.class > com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class > com/sun/media/sound/PortMixer$BoolCtrl$BCT.class > com/sun/media/sound/UlawCodec$UlawCodecStream.class > com/sun/media/sound/PortMixerProvider$PortMixerInfo.class > com/sun/media/sound/SMFParser.class > com/sun/media/sound/AbstractMixer.class > com/sun/media/sound/HeadspaceMixer.class > com/sun/media/sound/MixerSequencerProvider.class > com/sun/media/sound/HeadspaceMixer$MidiLine.class > com/sun/media/sound/JSSecurityManager$5.class > com/sun/media/sound/MixerClip$1.class > com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class > com/sun/media/sound/AutoConnectSequencer.class > com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class > com/sun/media/sound/SunFileWriter.class > com/sun/media/sound/MidiInDevice$1.class > com/sun/media/sound/AbstractMidiDevice.class > com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class > com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class > com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class > com/sun/media/sound/RealTimeSequencer$PlayThread.class > com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class > com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class > com/sun/media/sound/HeadspaceSoundbank.class > com/sun/media/sound/AiffFileWriter.class > com/sun/media/sound/DirectAudioDevice.class > com/sun/media/sound/SimpleInputDevice$1.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class > com/sun/media/sound/Toolkit.class > com/sun/media/sound/MixerSynth$SynthReceiver.class > com/sun/media/sound/JDK13Services$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL.class > com/sun/media/sound/DirectAudioDevice$DirectBAOS.class > com/sun/media/sound/StandardMidiFileReader.class > com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class > com/sun/media/sound/MidiInDevice.class > com/sun/media/sound/MidiOutDevice.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class > com/sun/media/sound/DataPusher.class > com/sun/media/sound/AbstractMidiDevice$TransmitterList.class > com/sun/media/sound/HeadspaceInstrument.class > com/sun/media/sound/MidiUtils$TempoCache.class > com/sun/media/sound/PortMixer$FloatCtrl.class > com/sun/media/sound/PortMixer$FloatCtrl$FCT.class > com/sun/media/sound/JDK13Services.class > com/sun/media/sound/HeadspaceMixer$1.class > com/sun/media/sound/PortMixer$PortInfo.class > com/sun/media/sound/EventDispatcher$EventInfo.class > com/sun/media/sound/EventDispatcher$LineMonitor.class > com/sun/media/sound/SimpleInputDeviceProvider$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class > com/sun/media/sound/JSSecurityManager$4.class > com/sun/media/sound/AlawCodec$AlawCodecStream.class > com/sun/media/sound/WaveFileWriter.class > com/sun/media/sound/DirectAudioDevice$DirectClip.class > com/sun/media/sound/PortMixer.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class > com/sun/media/sound/JSSecurityManager.class > com/sun/media/sound/PortMixer$CompCtrl.class > com/sun/media/sound/SimpleInputDeviceProvider.class > com/sun/media/sound/HeadspaceMixer$MixerInfo.class > com/sun/media/sound/MixerSourceLine.class > com/sun/media/sound/MixerClip.class > com/sun/media/sound/MidiUtils.class > com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class > com/sun/media/sound/MixerClip$MixerClipGainControl.class > com/sun/media/sound/SunCodec.class > com/sun/media/sound/AuFileWriter.class > com/sun/media/sound/RealTimeSequencer.class > com/sun/media/sound/AiffFileFormat.class > com/sun/media/sound/MixerSynth$MixerSynthInfo.class > com/sun/media/sound/MixerClip$MixerClipPanControl.class > com/sun/media/sound/AbstractMidiDeviceProvider.class > com/sun/media/sound/MixerThread.class > com/sun/media/sound/RealTimeSequencer$1.class > com/sun/media/sound/AuFileReader.class > com/sun/media/sound/JavaSoundAudioClip.class > com/sun/media/sound/JSSecurityManager$3.class > com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class > com/sun/media/sound/MidiInDeviceProvider.class > com/sun/media/sound/MixerSequencer$ControllerVectorElement.class > com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class > com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class > com/sun/media/sound/JSSecurityManager$7.class > com/sun/media/sound/UlawCodec.class > com/sun/media/sound/PortMixer$1.class > com/sun/media/sound/PortMixer$BoolCtrl.class > com/sun/media/sound/MidiOutDeviceProvider$1.class > com/sun/media/sound/AbstractMidiDeviceProvider$Info.class > com/sun/media/sound/RmfFileReader.class > com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class > com/sun/media/sound/RealTimeSequencer$RecordingTrack.class > com/sun/media/sound/AlawCodec.class > com/sun/media/sound/PortMixer$CompCtrl$CCT.class > com/sun/media/sound/DirectAudioDeviceProvider.class > com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class > com/sun/media/sound/PCMtoPCMCodec.class > com/sun/media/sound/HsbParser.class > com/sun/media/sound/EventDispatcher$ClipInfo.class > com/sun/media/sound/MixerMidiChannel.class > com/sun/media/sound/DirectAudioDevice$DirectSDL.class > com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class > com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class > com/sun/media/sound/MixerSequencer$RecordingTrack.class > com/sun/media/sound/RealTimeSequencer$ControllerListElement.class > com/sun/media/sound/MixerSourceLine$1.class > com/sun/media/sound/HeadspaceMixerProvider.class > com/sun/media/sound/RealTimeSequencerProvider.class > com/sun/media/sound/AuFileFormat.class > com/sun/media/sound/MixerSynth$1.class > com/sun/media/sound/AutoClosingClip.class > com/sun/media/sound/EventDispatcher.class > com/sun/media/sound/AiffFileReader.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class > com/sun/media/sound/AbstractPlayer.class > com/sun/media/sound/MidiInDevice$MidiInTransmitter.class > com/sun/media/sound/MixerSequencer.class > com/sun/media/sound/FastSysexMessage.class > com/sun/media/sound/JSSecurityManager$6.class > com/sun/media/sound/WaveFileReader.class > com/sun/media/sound/JSSecurityManager$2.class > com/sun/media/sound/MixerSynthProvider.class > com/sun/media/sound/SimpleInputDevice.class > com/sun/media/sound/AbstractLine.class > com/sun/media/sound/DirectAudioDevice$1.class > com/sun/media/sound/MixerClip$MixerClipMuteControl.class > com/sun/media/sound/SunFileReader.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class > com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class > com/sun/media/sound/Platform.class > com/sun/media/sound/DirectAudioDevice$DirectTDL.class > com/sun/media/sound/PortMixerProvider.class > com/sun/media/sound/CircularBuffer.class > com/sun/media/sound/PortMixer$PortMixerPort.class > com/sun/media/sound/DirectAudioDevice$DirectDLI.class > com/sun/media/sound/MidiOutDeviceProvider.class > com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class > com/sun/media/sound/Printer.class > com/sun/media/sound/MixerSequencer$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class > com/sun/media/sound/MixerSynth.class > com/sun/media/sound/FastShortMessage.class > com/sun/media/sound/JSSecurityManager$1.class > com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class > com/sun/media/sound/WaveFileFormat.class > com/sun/jmx/ > com/sun/jmx/snmp/ > com/sun/jmx/snmp/SnmpOpaque.class > com/sun/jmx/snmp/SnmpVarBindList.class > com/sun/jmx/snmp/SnmpString.class > com/sun/jmx/snmp/SnmpUnknownSubSystemException.class > com/sun/jmx/snmp/SnmpBadSecurityLevelException.class > com/sun/jmx/snmp/BerException.class > com/sun/jmx/snmp/SnmpGauge.class > com/sun/jmx/snmp/SnmpEngineFactory.class > com/sun/jmx/snmp/SnmpTooBigException.class > com/sun/jmx/snmp/ServiceName.class > com/sun/jmx/snmp/EnumRowStatus.class > com/sun/jmx/snmp/SnmpDataTypeEnums.class > com/sun/jmx/snmp/SnmpStringFixed.class > com/sun/jmx/snmp/SnmpPduPacket.class > com/sun/jmx/snmp/SnmpParams.class > com/sun/jmx/snmp/SnmpSecurityException.class > com/sun/jmx/snmp/SnmpEngineId.class > com/sun/jmx/snmp/SnmpUnknownMsgProcModelException.class > com/sun/jmx/snmp/Timestamp.class > com/sun/jmx/snmp/SnmpPdu.class > com/sun/jmx/snmp/SnmpVarBind.class > com/sun/jmx/snmp/UserAcl.class > com/sun/jmx/snmp/SnmpScopedPduPacket.class > com/sun/jmx/snmp/SnmpUnknownModelException.class > com/sun/jmx/snmp/SnmpIpAddress.class > com/sun/jmx/snmp/SnmpUsmKeyHandler.class > com/sun/jmx/snmp/SnmpScopedPduRequest.class > com/sun/jmx/snmp/SnmpPduFactory.class > com/sun/jmx/snmp/SnmpPduBulkType.class > com/sun/jmx/snmp/SnmpPduBulk.class > com/sun/jmx/snmp/SnmpPduRequest.class > com/sun/jmx/snmp/BerDecoder.class > com/sun/jmx/snmp/SnmpEngineParameters.class > com/sun/jmx/snmp/SnmpOidTableSupport.class > com/sun/jmx/snmp/SnmpOidDatabaseSupport.class > com/sun/jmx/snmp/SnmpMsg.class > com/sun/jmx/snmp/SnmpScopedPduBulk.class > com/sun/jmx/snmp/BerEncoder.class > com/sun/jmx/snmp/SnmpDefinitions.class > com/sun/jmx/snmp/SnmpAckPdu.class > com/sun/jmx/snmp/ThreadContext.class > com/sun/jmx/snmp/SnmpUnknownAccContrModelException.class > com/sun/jmx/snmp/daemon/ > com/sun/jmx/snmp/daemon/SendQ.class > com/sun/jmx/snmp/daemon/SnmpMibTree$1.class > com/sun/jmx/snmp/daemon/SnmpMibTree$TreeNode.class > com/sun/jmx/snmp/daemon/CommunicatorServer.class > com/sun/jmx/snmp/daemon/CommunicationException.class > com/sun/jmx/snmp/daemon/SnmpRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpResponseHandler.class > com/sun/jmx/snmp/daemon/SnmpRequestCounter.class > com/sun/jmx/snmp/daemon/SnmpSession.class > com/sun/jmx/snmp/daemon/SnmpTimerServer.class > com/sun/jmx/snmp/daemon/SnmpAdaptorServer.class > com/sun/jmx/snmp/daemon/SnmpSendServer.class > com/sun/jmx/snmp/daemon/WaitQ.class > com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpInformRequest.class > com/sun/jmx/snmp/daemon/SnmpSocket.class > com/sun/jmx/snmp/daemon/SnmpSubRequestHandler$NonSyncVector.class > com/sun/jmx/snmp/daemon/SnmpMibTree.class > com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.class > com/sun/jmx/snmp/daemon/ClientHandler.class > com/sun/jmx/snmp/daemon/SnmpInformHandler.class > com/sun/jmx/snmp/daemon/SnmpQManager.class > com/sun/jmx/snmp/daemon/CommunicatorServerMBean.class > com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.class > com/sun/jmx/snmp/SnmpStatusException.class > com/sun/jmx/snmp/SnmpMessage.class > com/sun/jmx/snmp/SnmpV3Message.class > com/sun/jmx/snmp/SnmpPduRequestType.class > com/sun/jmx/snmp/InetAddressAcl.class > com/sun/jmx/snmp/SnmpPeer.class > com/sun/jmx/snmp/SnmpInt.class > com/sun/jmx/snmp/SnmpCounter64.class > com/sun/jmx/snmp/SnmpValue.class > com/sun/jmx/snmp/SnmpOid.class > com/sun/jmx/snmp/SnmpPduFactoryBER.class > com/sun/jmx/snmp/SnmpOidRecord.class > com/sun/jmx/snmp/SnmpUnknownSecModelException.class > com/sun/jmx/snmp/SnmpNull.class > com/sun/jmx/snmp/SnmpTimeticks.class > com/sun/jmx/snmp/SnmpUnsignedInt.class > com/sun/jmx/snmp/SnmpUnknownModelLcdException.class > com/sun/jmx/snmp/SnmpSecurityParameters.class > com/sun/jmx/snmp/SnmpParameters.class > com/sun/jmx/snmp/SnmpOidDatabase.class > com/sun/jmx/snmp/SnmpOidTable.class > com/sun/jmx/snmp/Enumerated.class > com/sun/jmx/snmp/SnmpPduTrap.class > com/sun/jmx/snmp/SnmpCounter.class > com/sun/jmx/snmp/SnmpEngine.class > java/ > java/awt/ > java/awt/color/ > java/awt/color/ICC_ProfileRGB.class > java/awt/color/ICC_Profile$2.class > java/awt/color/ICC_ColorSpace.class > java/awt/color/ICC_Profile$1.class > java/awt/color/ICC_ProfileGray.class > java/awt/color/ProfileDataException.class > java/awt/color/ICC_Profile.class > java/awt/color/CMMException.class > java/awt/color/ICC_Profile$3.class > java/awt/color/ColorSpace.class > java/awt/image/ > java/awt/image/MemoryImageSource.class > java/awt/image/PixelInterleavedSampleModel.class > java/awt/image/ImageObserver.class > java/awt/image/RenderedImage.class > java/awt/image/renderable/ > java/awt/image/renderable/RenderableImageProducer.class > java/awt/image/renderable/RenderableImage.class > java/awt/image/renderable/ParameterBlock.class > java/awt/image/renderable/RenderContext.class > java/awt/image/renderable/ContextualRenderedImageFactory.class > java/awt/image/renderable/RenderableImageOp.class > java/awt/image/renderable/RenderedImageFactory.class > java/awt/image/ColorModel.class > java/awt/image/AffineTransformOp.class > java/awt/image/ImageProducer.class > java/awt/image/ImageConsumer.class > java/awt/image/LookupTable.class > java/awt/image/DataBufferDouble.class > java/awt/image/DataBufferFloat.class > java/awt/image/ComponentColorModel.class > java/awt/image/BandedSampleModel.class > java/awt/image/WritableRenderedImage.class > java/awt/image/CropImageFilter.class > java/awt/image/TileObserver.class > java/awt/image/ReplicateScaleFilter.class > java/awt/image/BufferedImageFilter.class > java/awt/image/VolatileImage.class > java/awt/image/RasterFormatException.class > java/awt/image/AreaAveragingScaleFilter.class > java/awt/image/SinglePixelPackedSampleModel.class > java/awt/image/LookupOp.class > java/awt/image/ConvolveOp.class > java/awt/image/PixelGrabber.class > java/awt/image/BufferedImageOp.class > java/awt/image/BufferedImage.class > java/awt/image/DataBufferUShort.class > java/awt/image/ShortLookupTable.class > java/awt/image/ImageFilter.class > java/awt/image/DataBufferByte.class > java/awt/image/MultiPixelPackedSampleModel.class > java/awt/image/IndexColorModel.class > java/awt/image/RGBImageFilter.class > java/awt/image/FilteredImageSource.class > java/awt/image/DataBuffer.class > java/awt/image/RescaleOp.class > java/awt/image/Raster.class > java/awt/image/SampleModel.class > java/awt/image/WritableRaster.class > java/awt/image/ColorConvertOp.class > java/awt/image/DirectColorModel.class > java/awt/image/Kernel.class > java/awt/image/ByteLookupTable.class > java/awt/image/DataBufferInt.class > java/awt/image/RasterOp.class > java/awt/image/ComponentSampleModel.class > java/awt/image/BandCombineOp.class > java/awt/image/BufferStrategy.class > java/awt/image/PackedColorModel.class > java/awt/image/DataBuffer$1.class > java/awt/image/ImagingOpException.class > java/awt/image/DataBufferShort.class > sun/ > sun/dc/ > sun/dc/pr/ > sun/dc/pr/PathFiller.class > sun/dc/pr/PRException.class > sun/dc/pr/PRError.class > sun/dc/pr/PathStroker.class > sun/dc/pr/Rasterizer$ConsumerDisposer.class > sun/dc/pr/Rasterizer.class > sun/dc/pr/PathDasher.class > sun/dc/path/ > sun/dc/path/PathConsumer.class > sun/dc/path/FastPathProducer.class > sun/dc/path/PathError.class > sun/dc/path/PathException.class From betelgeuse at gentoo.org Tue May 15 21:08:28 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 16 May 2007 00:08:28 +0300 Subject: [Fwd: [gentoo-java] Re: Why are the binay plugs so big?] Message-ID: <464A214C.3040307@gentoo.org> Wrong mailing list. -------- Alkuper?inen viesti / Orig.Msg. -------- Aihe: [gentoo-java] Re: Why are the binay plugs so big? P?iv?ys: Wed, 16 May 2007 00:05:55 +0300 L?hett?j?: Petteri R?ty Vastaanottaja: Kelly O'Hair CC: Gentoo Java Viittaukset: <464951C3.7070005 at yahoo.com> <464A13B4.3030903 at sun.com> Kelly O'Hair kirjoitti: > Your observations are correct. > Initially it wasn't 100% clear what binary plugs were necessary, and it > was easiest to just refer to a previously built jdk install tree. > > Given more time these bundles would have been stripped down to the bare > minimum, and that may still happen in the future. > But would you rather we spent our time getting rid of the binary plug > dependency, or reducing it's size? > Well at least reduced binary plug would be provide a good reference on what is still encumbered on what is not. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From lhofhansl at yahoo.com Tue May 15 21:09:39 2007 From: lhofhansl at yahoo.com (lars hofhansl) Date: Tue, 15 May 2007 14:09:39 -0700 (PDT) Subject: Why are the binay plugs so big? Message-ID: <527386.82065.qm@web52907.mail.re2.yahoo.com> Of course it is better to get rid of the dependencies (some Classpath folks are already working on the Color* stuff). The size of the binary plug "scared" me initially and I think having the minimum binary plugs would be very helpful until the dependencies are removed. I can come with the bare minimum list of files (although you probably have that) or provide the binary plug (with md5sum verified contents) if that helps - at least for Linux. ----- Original Message ---- From: Kelly O'Hair To: Lars Cc: build-dev at openjdk.java.net Sent: Tuesday, May 15, 2007 1:10:28 PM Subject: Re: Why are the binay plugs so big? Your observations are correct. Initially it wasn't 100% clear what binary plugs were necessary, and it was easiest to just refer to a previously built jdk install tree. Given more time these bundles would have been stripped down to the bare minimum, and that may still happen in the future. But would you rather we spent our time getting rid of the binary plug dependency, or reducing it's size? -kto Lars wrote: > After looking through the Makefiles (mostly Release.gmk) I was able to > build OpenJDK on Linux with ~4MB of binary plugs (unpacked), which is > only a fraction of a provided plugs which weigh in with over 170MB > (unpacked). > > The following list of files (and contents of rt.jar) should be pretty > universal and not just for Linux. rt.jar can even be reduced a little > further. > > So the obvious question: Why are the Sun provided binary plug so huge? > > Files: > jdk1.7.0/ > jdk1.7.0/jre > jdk1.7.0/jre/COPYRIGHT > jdk1.7.0/jre/LICENSE > jdk1.7.0/jre/lib > jdk1.7.0/jre/lib/jce.jar > jdk1.7.0/jre/lib/applet > jdk1.7.0/jre/lib/net.properties > jdk1.7.0/jre/lib/logging.properties > jdk1.7.0/jre/lib/flavormap.properties > jdk1.7.0/jre/lib/jvm.hprof.txt > jdk1.7.0/jre/lib/i386 > jdk1.7.0/jre/lib/i386/jvm.cfg > jdk1.7.0/jre/lib/i386/libdcpr.so > jdk1.7.0/jre/lib/i386/libjsoundalsa.so > jdk1.7.0/jre/lib/i386/libjsound.so > jdk1.7.0/jre/lib/i386/libt2k.so > jdk1.7.0/jre/lib/images > jdk1.7.0/jre/lib/images/cursors > jdk1.7.0/jre/lib/images/cursors/motif_LinkNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_MoveNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/cursors.properties > jdk1.7.0/jre/lib/images/cursors/motif_CopyDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_LinkDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_CopyNoDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/motif_MoveDrop32x32.gif > jdk1.7.0/jre/lib/images/cursors/invalid32x32.gif > jdk1.7.0/jre/lib/classlist > jdk1.7.0/jre/lib/security > jdk1.7.0/jre/lib/security/java.policy > jdk1.7.0/jre/lib/security/US_export_policy.jar > jdk1.7.0/jre/lib/security/local_policy.jar > jdk1.7.0/jre/lib/security/java.security > jdk1.7.0/jre/lib/audio > jdk1.7.0/jre/lib/audio/soundbank.gm > jdk1.7.0/jre/lib/zi > jdk1.7.0/jre/lib/zi/Asia > jdk1.7.0/jre/lib/zi/Asia/Dili > jdk1.7.0/jre/lib/zi/Asia/Magadan > jdk1.7.0/jre/lib/zi/Asia/Muscat > jdk1.7.0/jre/lib/zi/Asia/Karachi > jdk1.7.0/jre/lib/zi/Asia/Manila > jdk1.7.0/jre/lib/zi/Asia/Katmandu > jdk1.7.0/jre/lib/zi/Asia/Bahrain > jdk1.7.0/jre/lib/zi/Asia/Dushanbe > jdk1.7.0/jre/lib/zi/Asia/Saigon > jdk1.7.0/jre/lib/zi/Asia/Anadyr > jdk1.7.0/jre/lib/zi/Asia/Rangoon > jdk1.7.0/jre/lib/zi/Asia/Tashkent > jdk1.7.0/jre/lib/zi/Asia/Amman > jdk1.7.0/jre/lib/zi/Asia/Oral > jdk1.7.0/jre/lib/zi/Asia/Calcutta > jdk1.7.0/jre/lib/zi/Asia/Jakarta > jdk1.7.0/jre/lib/zi/Asia/Aqtau > jdk1.7.0/jre/lib/zi/Asia/Dubai > jdk1.7.0/jre/lib/zi/Asia/Ashgabat > jdk1.7.0/jre/lib/zi/Asia/Beirut > jdk1.7.0/jre/lib/zi/Asia/Hovd > jdk1.7.0/jre/lib/zi/Asia/Jayapura > jdk1.7.0/jre/lib/zi/Asia/Samarkand > jdk1.7.0/jre/lib/zi/Asia/Krasnoyarsk > jdk1.7.0/jre/lib/zi/Asia/Aqtobe > jdk1.7.0/jre/lib/zi/Asia/Omsk > jdk1.7.0/jre/lib/zi/Asia/Seoul > jdk1.7.0/jre/lib/zi/Asia/Bishkek > jdk1.7.0/jre/lib/zi/Asia/Thimphu > jdk1.7.0/jre/lib/zi/Asia/Novosibirsk > jdk1.7.0/jre/lib/zi/Asia/Kabul > jdk1.7.0/jre/lib/zi/Asia/Baku > jdk1.7.0/jre/lib/zi/Asia/Riyadh88 > jdk1.7.0/jre/lib/zi/Asia/Tehran > jdk1.7.0/jre/lib/zi/Asia/Taipei > jdk1.7.0/jre/lib/zi/Asia/Makassar > jdk1.7.0/jre/lib/zi/Asia/Yakutsk > jdk1.7.0/jre/lib/zi/Asia/Tokyo > jdk1.7.0/jre/lib/zi/Asia/Urumqi > jdk1.7.0/jre/lib/zi/Asia/Kuala_Lumpur > jdk1.7.0/jre/lib/zi/Asia/Riyadh89 > jdk1.7.0/jre/lib/zi/Asia/Kuwait > jdk1.7.0/jre/lib/zi/Asia/Brunei > jdk1.7.0/jre/lib/zi/Asia/Shanghai > jdk1.7.0/jre/lib/zi/Asia/Ulaanbaatar > jdk1.7.0/jre/lib/zi/Asia/Aden > jdk1.7.0/jre/lib/zi/Asia/Choibalsan > jdk1.7.0/jre/lib/zi/Asia/Qyzylorda > jdk1.7.0/jre/lib/zi/Asia/Tbilisi > jdk1.7.0/jre/lib/zi/Asia/Vientiane > jdk1.7.0/jre/lib/zi/Asia/Macau > jdk1.7.0/jre/lib/zi/Asia/Vladivostok > jdk1.7.0/jre/lib/zi/Asia/Yerevan > jdk1.7.0/jre/lib/zi/Asia/Gaza > jdk1.7.0/jre/lib/zi/Asia/Phnom_Penh > jdk1.7.0/jre/lib/zi/Asia/Bangkok > jdk1.7.0/jre/lib/zi/Asia/Harbin > jdk1.7.0/jre/lib/zi/Asia/Kashgar > jdk1.7.0/jre/lib/zi/Asia/Baghdad > jdk1.7.0/jre/lib/zi/Asia/Damascus > jdk1.7.0/jre/lib/zi/Asia/Nicosia > jdk1.7.0/jre/lib/zi/Asia/Jerusalem > jdk1.7.0/jre/lib/zi/Asia/Singapore > jdk1.7.0/jre/lib/zi/Asia/Pontianak > jdk1.7.0/jre/lib/zi/Asia/Qatar > jdk1.7.0/jre/lib/zi/Asia/Dhaka > jdk1.7.0/jre/lib/zi/Asia/Almaty > jdk1.7.0/jre/lib/zi/Asia/Chongqing > jdk1.7.0/jre/lib/zi/Asia/Hong_Kong > jdk1.7.0/jre/lib/zi/Asia/Yekaterinburg > jdk1.7.0/jre/lib/zi/Asia/Riyadh > jdk1.7.0/jre/lib/zi/Asia/Pyongyang > jdk1.7.0/jre/lib/zi/Asia/Kamchatka > jdk1.7.0/jre/lib/zi/Asia/Irkutsk > jdk1.7.0/jre/lib/zi/Asia/Riyadh87 > jdk1.7.0/jre/lib/zi/Asia/Sakhalin > jdk1.7.0/jre/lib/zi/Asia/Kuching > jdk1.7.0/jre/lib/zi/Asia/Colombo > jdk1.7.0/jre/lib/zi/HST > jdk1.7.0/jre/lib/zi/GMT > jdk1.7.0/jre/lib/zi/Antarctica > jdk1.7.0/jre/lib/zi/Antarctica/DumontDUrville > jdk1.7.0/jre/lib/zi/Antarctica/Mawson > jdk1.7.0/jre/lib/zi/Antarctica/Davis > jdk1.7.0/jre/lib/zi/Antarctica/Rothera > jdk1.7.0/jre/lib/zi/Antarctica/McMurdo > jdk1.7.0/jre/lib/zi/Antarctica/Palmer > jdk1.7.0/jre/lib/zi/Antarctica/Syowa > jdk1.7.0/jre/lib/zi/Antarctica/Casey > jdk1.7.0/jre/lib/zi/Antarctica/Vostok > jdk1.7.0/jre/lib/zi/EST > jdk1.7.0/jre/lib/zi/CST6CDT > jdk1.7.0/jre/lib/zi/CET > jdk1.7.0/jre/lib/zi/MST7MDT > jdk1.7.0/jre/lib/zi/Australia > jdk1.7.0/jre/lib/zi/Australia/Broken_Hill > jdk1.7.0/jre/lib/zi/Australia/Lord_Howe > jdk1.7.0/jre/lib/zi/Australia/Melbourne > jdk1.7.0/jre/lib/zi/Australia/Brisbane > jdk1.7.0/jre/lib/zi/Australia/Darwin > jdk1.7.0/jre/lib/zi/Australia/Lindeman > jdk1.7.0/jre/lib/zi/Australia/Eucla > jdk1.7.0/jre/lib/zi/Australia/Adelaide > jdk1.7.0/jre/lib/zi/Australia/Hobart > jdk1.7.0/jre/lib/zi/Australia/Perth > jdk1.7.0/jre/lib/zi/Australia/Currie > jdk1.7.0/jre/lib/zi/Australia/Sydney > jdk1.7.0/jre/lib/zi/SystemV > jdk1.7.0/jre/lib/zi/SystemV/CST6CDT > jdk1.7.0/jre/lib/zi/SystemV/HST10 > jdk1.7.0/jre/lib/zi/SystemV/PST8 > jdk1.7.0/jre/lib/zi/SystemV/MST7MDT > jdk1.7.0/jre/lib/zi/SystemV/AST4ADT > jdk1.7.0/jre/lib/zi/SystemV/CST6 > jdk1.7.0/jre/lib/zi/SystemV/EST5EDT > jdk1.7.0/jre/lib/zi/SystemV/YST9 > jdk1.7.0/jre/lib/zi/SystemV/YST9YDT > jdk1.7.0/jre/lib/zi/SystemV/MST7 > jdk1.7.0/jre/lib/zi/SystemV/EST5 > jdk1.7.0/jre/lib/zi/SystemV/AST4 > jdk1.7.0/jre/lib/zi/SystemV/PST8PDT > jdk1.7.0/jre/lib/zi/MST > jdk1.7.0/jre/lib/zi/WET > jdk1.7.0/jre/lib/zi/Europe > jdk1.7.0/jre/lib/zi/Europe/Amsterdam > jdk1.7.0/jre/lib/zi/Europe/Berlin > jdk1.7.0/jre/lib/zi/Europe/Brussels > jdk1.7.0/jre/lib/zi/Europe/Rome > jdk1.7.0/jre/lib/zi/Europe/Sofia > jdk1.7.0/jre/lib/zi/Europe/Warsaw > jdk1.7.0/jre/lib/zi/Europe/London > jdk1.7.0/jre/lib/zi/Europe/Monaco > jdk1.7.0/jre/lib/zi/Europe/Kaliningrad > jdk1.7.0/jre/lib/zi/Europe/Zaporozhye > jdk1.7.0/jre/lib/zi/Europe/Riga > jdk1.7.0/jre/lib/zi/Europe/Tirane > jdk1.7.0/jre/lib/zi/Europe/Kiev > jdk1.7.0/jre/lib/zi/Europe/Istanbul > jdk1.7.0/jre/lib/zi/Europe/Belgrade > jdk1.7.0/jre/lib/zi/Europe/Paris > jdk1.7.0/jre/lib/zi/Europe/Gibraltar > jdk1.7.0/jre/lib/zi/Europe/Bucharest > jdk1.7.0/jre/lib/zi/Europe/Vienna > jdk1.7.0/jre/lib/zi/Europe/Samara > jdk1.7.0/jre/lib/zi/Europe/Vaduz > jdk1.7.0/jre/lib/zi/Europe/Zurich > jdk1.7.0/jre/lib/zi/Europe/Dublin > jdk1.7.0/jre/lib/zi/Europe/Madrid > jdk1.7.0/jre/lib/zi/Europe/Volgograd > jdk1.7.0/jre/lib/zi/Europe/Oslo > jdk1.7.0/jre/lib/zi/Europe/Malta > jdk1.7.0/jre/lib/zi/Europe/Moscow > jdk1.7.0/jre/lib/zi/Europe/Luxembourg > jdk1.7.0/jre/lib/zi/Europe/Athens > jdk1.7.0/jre/lib/zi/Europe/Prague > jdk1.7.0/jre/lib/zi/Europe/Lisbon > jdk1.7.0/jre/lib/zi/Europe/Stockholm > jdk1.7.0/jre/lib/zi/Europe/Vilnius > jdk1.7.0/jre/lib/zi/Europe/Uzhgorod > jdk1.7.0/jre/lib/zi/Europe/Tallinn > jdk1.7.0/jre/lib/zi/Europe/Helsinki > jdk1.7.0/jre/lib/zi/Europe/Minsk > jdk1.7.0/jre/lib/zi/Europe/Simferopol > jdk1.7.0/jre/lib/zi/Europe/Copenhagen > jdk1.7.0/jre/lib/zi/Europe/Budapest > jdk1.7.0/jre/lib/zi/Europe/Chisinau > jdk1.7.0/jre/lib/zi/Europe/Andorra > jdk1.7.0/jre/lib/zi/Africa > jdk1.7.0/jre/lib/zi/Africa/Bangui > jdk1.7.0/jre/lib/zi/Africa/Windhoek > jdk1.7.0/jre/lib/zi/Africa/Sao_Tome > jdk1.7.0/jre/lib/zi/Africa/Ouagadougou > jdk1.7.0/jre/lib/zi/Africa/Algiers > jdk1.7.0/jre/lib/zi/Africa/Ndjamena > jdk1.7.0/jre/lib/zi/Africa/Banjul > jdk1.7.0/jre/lib/zi/Africa/Ceuta > jdk1.7.0/jre/lib/zi/Africa/Djibouti > jdk1.7.0/jre/lib/zi/Africa/Nairobi > jdk1.7.0/jre/lib/zi/Africa/Kampala > jdk1.7.0/jre/lib/zi/Africa/Brazzaville > jdk1.7.0/jre/lib/zi/Africa/Lagos > jdk1.7.0/jre/lib/zi/Africa/Harare > jdk1.7.0/jre/lib/zi/Africa/Lubumbashi > jdk1.7.0/jre/lib/zi/Africa/Dakar > jdk1.7.0/jre/lib/zi/Africa/Monrovia > jdk1.7.0/jre/lib/zi/Africa/Lome > jdk1.7.0/jre/lib/zi/Africa/Asmara > jdk1.7.0/jre/lib/zi/Africa/Luanda > jdk1.7.0/jre/lib/zi/Africa/Lusaka > jdk1.7.0/jre/lib/zi/Africa/Libreville > jdk1.7.0/jre/lib/zi/Africa/El_Aaiun > jdk1.7.0/jre/lib/zi/Africa/Mbabane > jdk1.7.0/jre/lib/zi/Africa/Blantyre > jdk1.7.0/jre/lib/zi/Africa/Mogadishu > jdk1.7.0/jre/lib/zi/Africa/Maputo > jdk1.7.0/jre/lib/zi/Africa/Johannesburg > jdk1.7.0/jre/lib/zi/Africa/Douala > jdk1.7.0/jre/lib/zi/Africa/Maseru > jdk1.7.0/jre/lib/zi/Africa/Addis_Ababa > jdk1.7.0/jre/lib/zi/Africa/Freetown > jdk1.7.0/jre/lib/zi/Africa/Accra > jdk1.7.0/jre/lib/zi/Africa/Bamako > jdk1.7.0/jre/lib/zi/Africa/Niamey > jdk1.7.0/jre/lib/zi/Africa/Bissau > jdk1.7.0/jre/lib/zi/Africa/Conakry > jdk1.7.0/jre/lib/zi/Africa/Bujumbura > jdk1.7.0/jre/lib/zi/Africa/Tunis > jdk1.7.0/jre/lib/zi/Africa/Abidjan > jdk1.7.0/jre/lib/zi/Africa/Malabo > jdk1.7.0/jre/lib/zi/Africa/Cairo > jdk1.7.0/jre/lib/zi/Africa/Porto-Novo > jdk1.7.0/jre/lib/zi/Africa/Nouakchott > jdk1.7.0/jre/lib/zi/Africa/Casablanca > jdk1.7.0/jre/lib/zi/Africa/Dar_es_Salaam > jdk1.7.0/jre/lib/zi/Africa/Tripoli > jdk1.7.0/jre/lib/zi/Africa/Khartoum > jdk1.7.0/jre/lib/zi/Africa/Kinshasa > jdk1.7.0/jre/lib/zi/Africa/Kigali > jdk1.7.0/jre/lib/zi/Africa/Gaborone > jdk1.7.0/jre/lib/zi/EET > jdk1.7.0/jre/lib/zi/EST5EDT > jdk1.7.0/jre/lib/zi/Etc > jdk1.7.0/jre/lib/zi/Etc/GMT > jdk1.7.0/jre/lib/zi/Etc/GMT+5 > jdk1.7.0/jre/lib/zi/Etc/GMT-13 > jdk1.7.0/jre/lib/zi/Etc/GMT+12 > jdk1.7.0/jre/lib/zi/Etc/GMT+11 > jdk1.7.0/jre/lib/zi/Etc/GMT-6 > jdk1.7.0/jre/lib/zi/Etc/GMT-4 > jdk1.7.0/jre/lib/zi/Etc/GMT-12 > jdk1.7.0/jre/lib/zi/Etc/GMT-8 > jdk1.7.0/jre/lib/zi/Etc/GMT+1 > jdk1.7.0/jre/lib/zi/Etc/GMT+8 > jdk1.7.0/jre/lib/zi/Etc/GMT+2 > jdk1.7.0/jre/lib/zi/Etc/GMT-10 > jdk1.7.0/jre/lib/zi/Etc/GMT-11 > jdk1.7.0/jre/lib/zi/Etc/UCT > jdk1.7.0/jre/lib/zi/Etc/GMT-3 > jdk1.7.0/jre/lib/zi/Etc/GMT+9 > jdk1.7.0/jre/lib/zi/Etc/GMT-1 > jdk1.7.0/jre/lib/zi/Etc/GMT-2 > jdk1.7.0/jre/lib/zi/Etc/GMT-14 > jdk1.7.0/jre/lib/zi/Etc/GMT+6 > jdk1.7.0/jre/lib/zi/Etc/GMT+3 > jdk1.7.0/jre/lib/zi/Etc/GMT-5 > jdk1.7.0/jre/lib/zi/Etc/GMT+4 > jdk1.7.0/jre/lib/zi/Etc/GMT-9 > jdk1.7.0/jre/lib/zi/Etc/GMT+7 > jdk1.7.0/jre/lib/zi/Etc/UTC > jdk1.7.0/jre/lib/zi/Etc/GMT+10 > jdk1.7.0/jre/lib/zi/Etc/GMT-7 > jdk1.7.0/jre/lib/zi/Pacific > jdk1.7.0/jre/lib/zi/Pacific/Honolulu > jdk1.7.0/jre/lib/zi/Pacific/Kiritimati > jdk1.7.0/jre/lib/zi/Pacific/Midway > jdk1.7.0/jre/lib/zi/Pacific/Nauru > jdk1.7.0/jre/lib/zi/Pacific/Johnston > jdk1.7.0/jre/lib/zi/Pacific/Ponape > jdk1.7.0/jre/lib/zi/Pacific/Galapagos > jdk1.7.0/jre/lib/zi/Pacific/Auckland > jdk1.7.0/jre/lib/zi/Pacific/Wake > jdk1.7.0/jre/lib/zi/Pacific/Tongatapu > jdk1.7.0/jre/lib/zi/Pacific/Chatham > jdk1.7.0/jre/lib/zi/Pacific/Wallis > jdk1.7.0/jre/lib/zi/Pacific/Truk > jdk1.7.0/jre/lib/zi/Pacific/Efate > jdk1.7.0/jre/lib/zi/Pacific/Fiji > jdk1.7.0/jre/lib/zi/Pacific/Port_Moresby > jdk1.7.0/jre/lib/zi/Pacific/Marquesas > jdk1.7.0/jre/lib/zi/Pacific/Tahiti > jdk1.7.0/jre/lib/zi/Pacific/Funafuti > jdk1.7.0/jre/lib/zi/Pacific/Niue > jdk1.7.0/jre/lib/zi/Pacific/Easter > jdk1.7.0/jre/lib/zi/Pacific/Gambier > jdk1.7.0/jre/lib/zi/Pacific/Kosrae > jdk1.7.0/jre/lib/zi/Pacific/Norfolk > jdk1.7.0/jre/lib/zi/Pacific/Fakaofo > jdk1.7.0/jre/lib/zi/Pacific/Majuro > jdk1.7.0/jre/lib/zi/Pacific/Enderbury > jdk1.7.0/jre/lib/zi/Pacific/Kwajalein > jdk1.7.0/jre/lib/zi/Pacific/Pitcairn > jdk1.7.0/jre/lib/zi/Pacific/Guadalcanal > jdk1.7.0/jre/lib/zi/Pacific/Rarotonga > jdk1.7.0/jre/lib/zi/Pacific/Noumea > jdk1.7.0/jre/lib/zi/Pacific/Guam > jdk1.7.0/jre/lib/zi/Pacific/Palau > jdk1.7.0/jre/lib/zi/Pacific/Saipan > jdk1.7.0/jre/lib/zi/Pacific/Apia > jdk1.7.0/jre/lib/zi/Pacific/Tarawa > jdk1.7.0/jre/lib/zi/Pacific/Pago_Pago > jdk1.7.0/jre/lib/zi/Atlantic > jdk1.7.0/jre/lib/zi/Atlantic/Azores > jdk1.7.0/jre/lib/zi/Atlantic/Cape_Verde > jdk1.7.0/jre/lib/zi/Atlantic/Bermuda > jdk1.7.0/jre/lib/zi/Atlantic/Stanley > jdk1.7.0/jre/lib/zi/Atlantic/Madeira > jdk1.7.0/jre/lib/zi/Atlantic/St_Helena > jdk1.7.0/jre/lib/zi/Atlantic/Canary > jdk1.7.0/jre/lib/zi/Atlantic/South_Georgia > jdk1.7.0/jre/lib/zi/Atlantic/Reykjavik > jdk1.7.0/jre/lib/zi/Atlantic/Faroe > jdk1.7.0/jre/lib/zi/America > jdk1.7.0/jre/lib/zi/America/North_Dakota > jdk1.7.0/jre/lib/zi/America/North_Dakota/Center > jdk1.7.0/jre/lib/zi/America/North_Dakota/New_Salem > jdk1.7.0/jre/lib/zi/America/Anchorage > jdk1.7.0/jre/lib/zi/America/Santiago > jdk1.7.0/jre/lib/zi/America/Paramaribo > jdk1.7.0/jre/lib/zi/America/Godthab > jdk1.7.0/jre/lib/zi/America/Detroit > jdk1.7.0/jre/lib/zi/America/Rankin_Inlet > jdk1.7.0/jre/lib/zi/America/La_Paz > jdk1.7.0/jre/lib/zi/America/St_Lucia > jdk1.7.0/jre/lib/zi/America/El_Salvador > jdk1.7.0/jre/lib/zi/America/Maceio > jdk1.7.0/jre/lib/zi/America/Cayenne > jdk1.7.0/jre/lib/zi/America/Nassau > jdk1.7.0/jre/lib/zi/America/Chicago > jdk1.7.0/jre/lib/zi/America/Bogota > jdk1.7.0/jre/lib/zi/America/Whitehorse > jdk1.7.0/jre/lib/zi/America/Phoenix > jdk1.7.0/jre/lib/zi/America/Kentucky > jdk1.7.0/jre/lib/zi/America/Kentucky/Louisville > jdk1.7.0/jre/lib/zi/America/Kentucky/Monticello > jdk1.7.0/jre/lib/zi/America/Rainy_River > jdk1.7.0/jre/lib/zi/America/Fortaleza > jdk1.7.0/jre/lib/zi/America/Boise > jdk1.7.0/jre/lib/zi/America/Barbados > jdk1.7.0/jre/lib/zi/America/Bahia > jdk1.7.0/jre/lib/zi/America/St_Thomas > jdk1.7.0/jre/lib/zi/America/Moncton > jdk1.7.0/jre/lib/zi/America/Cambridge_Bay > jdk1.7.0/jre/lib/zi/America/Jamaica > jdk1.7.0/jre/lib/zi/America/Antigua > jdk1.7.0/jre/lib/zi/America/Porto_Velho > jdk1.7.0/jre/lib/zi/America/Montevideo > jdk1.7.0/jre/lib/zi/America/Hermosillo > jdk1.7.0/jre/lib/zi/America/Dominica > jdk1.7.0/jre/lib/zi/America/Tijuana > jdk1.7.0/jre/lib/zi/America/Guayaquil > jdk1.7.0/jre/lib/zi/America/Denver > jdk1.7.0/jre/lib/zi/America/Rio_Branco > jdk1.7.0/jre/lib/zi/America/Cancun > jdk1.7.0/jre/lib/zi/America/Mexico_City > jdk1.7.0/jre/lib/zi/America/Port-au-Prince > jdk1.7.0/jre/lib/zi/America/Montserrat > jdk1.7.0/jre/lib/zi/America/St_Johns > jdk1.7.0/jre/lib/zi/America/Inuvik > jdk1.7.0/jre/lib/zi/America/Managua > jdk1.7.0/jre/lib/zi/America/Martinique > jdk1.7.0/jre/lib/zi/America/Regina > jdk1.7.0/jre/lib/zi/America/Toronto > jdk1.7.0/jre/lib/zi/America/Indiana > jdk1.7.0/jre/lib/zi/America/Indiana/Vevay > jdk1.7.0/jre/lib/zi/America/Indiana/Knox > jdk1.7.0/jre/lib/zi/America/Indiana/Marengo > jdk1.7.0/jre/lib/zi/America/Indiana/Vincennes > jdk1.7.0/jre/lib/zi/America/Indiana/Indianapolis > jdk1.7.0/jre/lib/zi/America/Indiana/Winamac > jdk1.7.0/jre/lib/zi/America/Indiana/Petersburg > jdk1.7.0/jre/lib/zi/America/Grenada > jdk1.7.0/jre/lib/zi/America/Pangnirtung > jdk1.7.0/jre/lib/zi/America/St_Kitts > jdk1.7.0/jre/lib/zi/America/Caracas > jdk1.7.0/jre/lib/zi/America/Atikokan > jdk1.7.0/jre/lib/zi/America/Monterrey > jdk1.7.0/jre/lib/zi/America/Swift_Current > jdk1.7.0/jre/lib/zi/America/Los_Angeles > jdk1.7.0/jre/lib/zi/America/Guyana > jdk1.7.0/jre/lib/zi/America/Anguilla > jdk1.7.0/jre/lib/zi/America/Grand_Turk > jdk1.7.0/jre/lib/zi/America/Juneau > jdk1.7.0/jre/lib/zi/America/Chihuahua > jdk1.7.0/jre/lib/zi/America/Merida > jdk1.7.0/jre/lib/zi/America/Lima > jdk1.7.0/jre/lib/zi/America/Manaus > jdk1.7.0/jre/lib/zi/America/Danmarkshavn > jdk1.7.0/jre/lib/zi/America/Eirunepe > jdk1.7.0/jre/lib/zi/America/Araguaina > jdk1.7.0/jre/lib/zi/America/Belize > jdk1.7.0/jre/lib/zi/America/Tegucigalpa > jdk1.7.0/jre/lib/zi/America/Miquelon > jdk1.7.0/jre/lib/zi/America/Nome > jdk1.7.0/jre/lib/zi/America/New_York > jdk1.7.0/jre/lib/zi/America/Noronha > jdk1.7.0/jre/lib/zi/America/Adak > jdk1.7.0/jre/lib/zi/America/Winnipeg > jdk1.7.0/jre/lib/zi/America/Thunder_Bay > jdk1.7.0/jre/lib/zi/America/Dawson > jdk1.7.0/jre/lib/zi/America/Yakutat > jdk1.7.0/jre/lib/zi/America/Dawson_Creek > jdk1.7.0/jre/lib/zi/America/Blanc-Sablon > jdk1.7.0/jre/lib/zi/America/Puerto_Rico > jdk1.7.0/jre/lib/zi/America/Cayman > jdk1.7.0/jre/lib/zi/America/Thule > jdk1.7.0/jre/lib/zi/America/Panama > jdk1.7.0/jre/lib/zi/America/Nipigon > jdk1.7.0/jre/lib/zi/America/Argentina > jdk1.7.0/jre/lib/zi/America/Argentina/Catamarca > jdk1.7.0/jre/lib/zi/America/Argentina/Rio_Gallegos > jdk1.7.0/jre/lib/zi/America/Argentina/Mendoza > jdk1.7.0/jre/lib/zi/America/Argentina/Ushuaia > jdk1.7.0/jre/lib/zi/America/Argentina/Tucuman > jdk1.7.0/jre/lib/zi/America/Argentina/Buenos_Aires > jdk1.7.0/jre/lib/zi/America/Argentina/Jujuy > jdk1.7.0/jre/lib/zi/America/Argentina/San_Juan > jdk1.7.0/jre/lib/zi/America/Argentina/Cordoba > jdk1.7.0/jre/lib/zi/America/Argentina/La_Rioja > jdk1.7.0/jre/lib/zi/America/Port_of_Spain > jdk1.7.0/jre/lib/zi/America/Campo_Grande > jdk1.7.0/jre/lib/zi/America/Goose_Bay > jdk1.7.0/jre/lib/zi/America/Cuiaba > jdk1.7.0/jre/lib/zi/America/Glace_Bay > jdk1.7.0/jre/lib/zi/America/Montreal > jdk1.7.0/jre/lib/zi/America/Curacao > jdk1.7.0/jre/lib/zi/America/Tortola > jdk1.7.0/jre/lib/zi/America/Havana > jdk1.7.0/jre/lib/zi/America/Asuncion > jdk1.7.0/jre/lib/zi/America/Mazatlan > jdk1.7.0/jre/lib/zi/America/Scoresbysund > jdk1.7.0/jre/lib/zi/America/Yellowknife > jdk1.7.0/jre/lib/zi/America/Aruba > jdk1.7.0/jre/lib/zi/America/Edmonton > jdk1.7.0/jre/lib/zi/America/Halifax > jdk1.7.0/jre/lib/zi/America/Iqaluit > jdk1.7.0/jre/lib/zi/America/Guadeloupe > jdk1.7.0/jre/lib/zi/America/Costa_Rica > jdk1.7.0/jre/lib/zi/America/Belem > jdk1.7.0/jre/lib/zi/America/Santo_Domingo > jdk1.7.0/jre/lib/zi/America/Sao_Paulo > jdk1.7.0/jre/lib/zi/America/Boa_Vista > jdk1.7.0/jre/lib/zi/America/Recife > jdk1.7.0/jre/lib/zi/America/Guatemala > jdk1.7.0/jre/lib/zi/America/St_Vincent > jdk1.7.0/jre/lib/zi/America/Menominee > jdk1.7.0/jre/lib/zi/America/Vancouver > jdk1.7.0/jre/lib/zi/Indian > jdk1.7.0/jre/lib/zi/Indian/Chagos > jdk1.7.0/jre/lib/zi/Indian/Christmas > jdk1.7.0/jre/lib/zi/Indian/Antananarivo > jdk1.7.0/jre/lib/zi/Indian/Mayotte > jdk1.7.0/jre/lib/zi/Indian/Comoro > jdk1.7.0/jre/lib/zi/Indian/Maldives > jdk1.7.0/jre/lib/zi/Indian/Cocos > jdk1.7.0/jre/lib/zi/Indian/Mauritius > jdk1.7.0/jre/lib/zi/Indian/Kerguelen > jdk1.7.0/jre/lib/zi/Indian/Reunion > jdk1.7.0/jre/lib/zi/Indian/Mahe > jdk1.7.0/jre/lib/zi/ZoneInfoMappings > jdk1.7.0/jre/lib/zi/MET > jdk1.7.0/jre/lib/zi/PST8PDT > jdk1.7.0/jre/lib/sound.properties > jdk1.7.0/jre/lib/rt.jar > jdk1.7.0/jre/lib/content-types.properties > jdk1.7.0/jre/lib/management > jdk1.7.0/jre/lib/management/jmxremote.access > jdk1.7.0/jre/lib/management/snmp.acl.template > jdk1.7.0/jre/lib/management/jmxremote.password.template > jdk1.7.0/jre/lib/management/management.properties > jdk1.7.0/jre/lib/ext > jdk1.7.0/jre/lib/ext/sunjce_provider.jar > jdk1.7.0/LICENSE > > rt.jar: > META-INF/ > META-INF/MANIFEST.MF > com/ > com/sun/ > com/sun/media/ > com/sun/media/sound/ > com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class > com/sun/media/sound/AbstractDataLine.class > com/sun/media/sound/ReferenceCountingDevice.class > com/sun/media/sound/HeadspaceSample.class > com/sun/media/sound/RealTimeSequencer$DataPump.class > com/sun/media/sound/StandardMidiFileWriter.class > com/sun/media/sound/SimpleInputDevice$InputDevicePort.class > com/sun/media/sound/JDK13Services$ProviderCache.class > com/sun/media/sound/MidiInDeviceProvider$1.class > com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class > com/sun/media/sound/PortMixer$BoolCtrl$BCT.class > com/sun/media/sound/UlawCodec$UlawCodecStream.class > com/sun/media/sound/PortMixerProvider$PortMixerInfo.class > com/sun/media/sound/SMFParser.class > com/sun/media/sound/AbstractMixer.class > com/sun/media/sound/HeadspaceMixer.class > com/sun/media/sound/MixerSequencerProvider.class > com/sun/media/sound/HeadspaceMixer$MidiLine.class > com/sun/media/sound/JSSecurityManager$5.class > com/sun/media/sound/MixerClip$1.class > com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class > com/sun/media/sound/AutoConnectSequencer.class > com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class > com/sun/media/sound/SunFileWriter.class > com/sun/media/sound/MidiInDevice$1.class > com/sun/media/sound/AbstractMidiDevice.class > com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class > com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class > com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class > com/sun/media/sound/RealTimeSequencer$PlayThread.class > com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class > com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class > com/sun/media/sound/HeadspaceSoundbank.class > com/sun/media/sound/AiffFileWriter.class > com/sun/media/sound/DirectAudioDevice.class > com/sun/media/sound/SimpleInputDevice$1.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class > com/sun/media/sound/Toolkit.class > com/sun/media/sound/MixerSynth$SynthReceiver.class > com/sun/media/sound/JDK13Services$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL.class > com/sun/media/sound/DirectAudioDevice$DirectBAOS.class > com/sun/media/sound/StandardMidiFileReader.class > com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class > com/sun/media/sound/MidiInDevice.class > com/sun/media/sound/MidiOutDevice.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class > com/sun/media/sound/DataPusher.class > com/sun/media/sound/AbstractMidiDevice$TransmitterList.class > com/sun/media/sound/HeadspaceInstrument.class > com/sun/media/sound/MidiUtils$TempoCache.class > com/sun/media/sound/PortMixer$FloatCtrl.class > com/sun/media/sound/PortMixer$FloatCtrl$FCT.class > com/sun/media/sound/JDK13Services.class > com/sun/media/sound/HeadspaceMixer$1.class > com/sun/media/sound/PortMixer$PortInfo.class > com/sun/media/sound/EventDispatcher$EventInfo.class > com/sun/media/sound/EventDispatcher$LineMonitor.class > com/sun/media/sound/SimpleInputDeviceProvider$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class > com/sun/media/sound/JSSecurityManager$4.class > com/sun/media/sound/AlawCodec$AlawCodecStream.class > com/sun/media/sound/WaveFileWriter.class > com/sun/media/sound/DirectAudioDevice$DirectClip.class > com/sun/media/sound/PortMixer.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class > com/sun/media/sound/JSSecurityManager.class > com/sun/media/sound/PortMixer$CompCtrl.class > com/sun/media/sound/SimpleInputDeviceProvider.class > com/sun/media/sound/HeadspaceMixer$MixerInfo.class > com/sun/media/sound/MixerSourceLine.class > com/sun/media/sound/MixerClip.class > com/sun/media/sound/MidiUtils.class > com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class > com/sun/media/sound/MixerClip$MixerClipGainControl.class > com/sun/media/sound/SunCodec.class > com/sun/media/sound/AuFileWriter.class > com/sun/media/sound/RealTimeSequencer.class > com/sun/media/sound/AiffFileFormat.class > com/sun/media/sound/MixerSynth$MixerSynthInfo.class > com/sun/media/sound/MixerClip$MixerClipPanControl.class > com/sun/media/sound/AbstractMidiDeviceProvider.class > com/sun/media/sound/MixerThread.class > com/sun/media/sound/RealTimeSequencer$1.class > com/sun/media/sound/AuFileReader.class > com/sun/media/sound/JavaSoundAudioClip.class > com/sun/media/sound/JSSecurityManager$3.class > com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class > com/sun/media/sound/MidiInDeviceProvider.class > com/sun/media/sound/MixerSequencer$ControllerVectorElement.class > com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class > com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class > com/sun/media/sound/JSSecurityManager$7.class > com/sun/media/sound/UlawCodec.class > com/sun/media/sound/PortMixer$1.class > com/sun/media/sound/PortMixer$BoolCtrl.class > com/sun/media/sound/MidiOutDeviceProvider$1.class > com/sun/media/sound/AbstractMidiDeviceProvider$Info.class > com/sun/media/sound/RmfFileReader.class > com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class > com/sun/media/sound/RealTimeSequencer$RecordingTrack.class > com/sun/media/sound/AlawCodec.class > com/sun/media/sound/PortMixer$CompCtrl$CCT.class > com/sun/media/sound/DirectAudioDeviceProvider.class > com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class > com/sun/media/sound/PCMtoPCMCodec.class > com/sun/media/sound/HsbParser.class > com/sun/media/sound/EventDispatcher$ClipInfo.class > com/sun/media/sound/MixerMidiChannel.class > com/sun/media/sound/DirectAudioDevice$DirectSDL.class > com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class > com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class > com/sun/media/sound/MixerSequencer$RecordingTrack.class > com/sun/media/sound/RealTimeSequencer$ControllerListElement.class > com/sun/media/sound/MixerSourceLine$1.class > com/sun/media/sound/HeadspaceMixerProvider.class > com/sun/media/sound/RealTimeSequencerProvider.class > com/sun/media/sound/AuFileFormat.class > com/sun/media/sound/MixerSynth$1.class > com/sun/media/sound/AutoClosingClip.class > com/sun/media/sound/EventDispatcher.class > com/sun/media/sound/AiffFileReader.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class > com/sun/media/sound/AbstractPlayer.class > com/sun/media/sound/MidiInDevice$MidiInTransmitter.class > com/sun/media/sound/MixerSequencer.class > com/sun/media/sound/FastSysexMessage.class > com/sun/media/sound/JSSecurityManager$6.class > com/sun/media/sound/WaveFileReader.class > com/sun/media/sound/JSSecurityManager$2.class > com/sun/media/sound/MixerSynthProvider.class > com/sun/media/sound/SimpleInputDevice.class > com/sun/media/sound/AbstractLine.class > com/sun/media/sound/DirectAudioDevice$1.class > com/sun/media/sound/MixerClip$MixerClipMuteControl.class > com/sun/media/sound/SunFileReader.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class > com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class > com/sun/media/sound/Platform.class > com/sun/media/sound/DirectAudioDevice$DirectTDL.class > com/sun/media/sound/PortMixerProvider.class > com/sun/media/sound/CircularBuffer.class > com/sun/media/sound/PortMixer$PortMixerPort.class > com/sun/media/sound/DirectAudioDevice$DirectDLI.class > com/sun/media/sound/MidiOutDeviceProvider.class > com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class > com/sun/media/sound/Printer.class > com/sun/media/sound/MixerSequencer$1.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class > com/sun/media/sound/MixerSynth.class > com/sun/media/sound/FastShortMessage.class > com/sun/media/sound/JSSecurityManager$1.class > com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class > com/sun/media/sound/WaveFileFormat.class > com/sun/jmx/ > com/sun/jmx/snmp/ > com/sun/jmx/snmp/SnmpOpaque.class > com/sun/jmx/snmp/SnmpVarBindList.class > com/sun/jmx/snmp/SnmpString.class > com/sun/jmx/snmp/SnmpUnknownSubSystemException.class > com/sun/jmx/snmp/SnmpBadSecurityLevelException.class > com/sun/jmx/snmp/BerException.class > com/sun/jmx/snmp/SnmpGauge.class > com/sun/jmx/snmp/SnmpEngineFactory.class > com/sun/jmx/snmp/SnmpTooBigException.class > com/sun/jmx/snmp/ServiceName.class > com/sun/jmx/snmp/EnumRowStatus.class > com/sun/jmx/snmp/SnmpDataTypeEnums.class > com/sun/jmx/snmp/SnmpStringFixed.class > com/sun/jmx/snmp/SnmpPduPacket.class > com/sun/jmx/snmp/SnmpParams.class > com/sun/jmx/snmp/SnmpSecurityException.class > com/sun/jmx/snmp/SnmpEngineId.class > com/sun/jmx/snmp/SnmpUnknownMsgProcModelException.class > com/sun/jmx/snmp/Timestamp.class > com/sun/jmx/snmp/SnmpPdu.class > com/sun/jmx/snmp/SnmpVarBind.class > com/sun/jmx/snmp/UserAcl.class > com/sun/jmx/snmp/SnmpScopedPduPacket.class > com/sun/jmx/snmp/SnmpUnknownModelException.class > com/sun/jmx/snmp/SnmpIpAddress.class > com/sun/jmx/snmp/SnmpUsmKeyHandler.class > com/sun/jmx/snmp/SnmpScopedPduRequest.class > com/sun/jmx/snmp/SnmpPduFactory.class > com/sun/jmx/snmp/SnmpPduBulkType.class > com/sun/jmx/snmp/SnmpPduBulk.class > com/sun/jmx/snmp/SnmpPduRequest.class > com/sun/jmx/snmp/BerDecoder.class > com/sun/jmx/snmp/SnmpEngineParameters.class > com/sun/jmx/snmp/SnmpOidTableSupport.class > com/sun/jmx/snmp/SnmpOidDatabaseSupport.class > com/sun/jmx/snmp/SnmpMsg.class > com/sun/jmx/snmp/SnmpScopedPduBulk.class > com/sun/jmx/snmp/BerEncoder.class > com/sun/jmx/snmp/SnmpDefinitions.class > com/sun/jmx/snmp/SnmpAckPdu.class > com/sun/jmx/snmp/ThreadContext.class > com/sun/jmx/snmp/SnmpUnknownAccContrModelException.class > com/sun/jmx/snmp/daemon/ > com/sun/jmx/snmp/daemon/SendQ.class > com/sun/jmx/snmp/daemon/SnmpMibTree$1.class > com/sun/jmx/snmp/daemon/SnmpMibTree$TreeNode.class > com/sun/jmx/snmp/daemon/CommunicatorServer.class > com/sun/jmx/snmp/daemon/CommunicationException.class > com/sun/jmx/snmp/daemon/SnmpRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpResponseHandler.class > com/sun/jmx/snmp/daemon/SnmpRequestCounter.class > com/sun/jmx/snmp/daemon/SnmpSession.class > com/sun/jmx/snmp/daemon/SnmpTimerServer.class > com/sun/jmx/snmp/daemon/SnmpAdaptorServer.class > com/sun/jmx/snmp/daemon/SnmpSendServer.class > com/sun/jmx/snmp/daemon/WaitQ.class > com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpInformRequest.class > com/sun/jmx/snmp/daemon/SnmpSocket.class > com/sun/jmx/snmp/daemon/SnmpSubRequestHandler$NonSyncVector.class > com/sun/jmx/snmp/daemon/SnmpMibTree.class > com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.class > com/sun/jmx/snmp/daemon/ClientHandler.class > com/sun/jmx/snmp/daemon/SnmpInformHandler.class > com/sun/jmx/snmp/daemon/SnmpQManager.class > com/sun/jmx/snmp/daemon/CommunicatorServerMBean.class > com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.class > com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.class > com/sun/jmx/snmp/SnmpStatusException.class > com/sun/jmx/snmp/SnmpMessage.class > com/sun/jmx/snmp/SnmpV3Message.class > com/sun/jmx/snmp/SnmpPduRequestType.class > com/sun/jmx/snmp/InetAddressAcl.class > com/sun/jmx/snmp/SnmpPeer.class > com/sun/jmx/snmp/SnmpInt.class > com/sun/jmx/snmp/SnmpCounter64.class > com/sun/jmx/snmp/SnmpValue.class > com/sun/jmx/snmp/SnmpOid.class > com/sun/jmx/snmp/SnmpPduFactoryBER.class > com/sun/jmx/snmp/SnmpOidRecord.class > com/sun/jmx/snmp/SnmpUnknownSecModelException.class > com/sun/jmx/snmp/SnmpNull.class > com/sun/jmx/snmp/SnmpTimeticks.class > com/sun/jmx/snmp/SnmpUnsignedInt.class > com/sun/jmx/snmp/SnmpUnknownModelLcdException.class > com/sun/jmx/snmp/SnmpSecurityParameters.class > com/sun/jmx/snmp/SnmpParameters.class > com/sun/jmx/snmp/SnmpOidDatabase.class > com/sun/jmx/snmp/SnmpOidTable.class > com/sun/jmx/snmp/Enumerated.class > com/sun/jmx/snmp/SnmpPduTrap.class > com/sun/jmx/snmp/SnmpCounter.class > com/sun/jmx/snmp/SnmpEngine.class > java/ > java/awt/ > java/awt/color/ > java/awt/color/ICC_ProfileRGB.class > java/awt/color/ICC_Profile$2.class > java/awt/color/ICC_ColorSpace.class > java/awt/color/ICC_Profile$1.class > java/awt/color/ICC_ProfileGray.class > java/awt/color/ProfileDataException.class > java/awt/color/ICC_Profile.class > java/awt/color/CMMException.class > java/awt/color/ICC_Profile$3.class > java/awt/color/ColorSpace.class > java/awt/image/ > java/awt/image/MemoryImageSource.class > java/awt/image/PixelInterleavedSampleModel.class > java/awt/image/ImageObserver.class > java/awt/image/RenderedImage.class > java/awt/image/renderable/ > java/awt/image/renderable/RenderableImageProducer.class > java/awt/image/renderable/RenderableImage.class > java/awt/image/renderable/ParameterBlock.class > java/awt/image/renderable/RenderContext.class > java/awt/image/renderable/ContextualRenderedImageFactory.class > java/awt/image/renderable/RenderableImageOp.class > java/awt/image/renderable/RenderedImageFactory.class > java/awt/image/ColorModel.class > java/awt/image/AffineTransformOp.class > java/awt/image/ImageProducer.class > java/awt/image/ImageConsumer.class > java/awt/image/LookupTable.class > java/awt/image/DataBufferDouble.class > java/awt/image/DataBufferFloat.class > java/awt/image/ComponentColorModel.class > java/awt/image/BandedSampleModel.class > java/awt/image/WritableRenderedImage.class > java/awt/image/CropImageFilter.class > java/awt/image/TileObserver.class > java/awt/image/ReplicateScaleFilter.class > java/awt/image/BufferedImageFilter.class > java/awt/image/VolatileImage.class > java/awt/image/RasterFormatException.class > java/awt/image/AreaAveragingScaleFilter.class > java/awt/image/SinglePixelPackedSampleModel.class > java/awt/image/LookupOp.class > java/awt/image/ConvolveOp.class > java/awt/image/PixelGrabber.class > java/awt/image/BufferedImageOp.class > java/awt/image/BufferedImage.class > java/awt/image/DataBufferUShort.class > java/awt/image/ShortLookupTable.class > java/awt/image/ImageFilter.class > java/awt/image/DataBufferByte.class > java/awt/image/MultiPixelPackedSampleModel.class > java/awt/image/IndexColorModel.class > java/awt/image/RGBImageFilter.class > java/awt/image/FilteredImageSource.class > java/awt/image/DataBuffer.class > java/awt/image/RescaleOp.class > java/awt/image/Raster.class > java/awt/image/SampleModel.class > java/awt/image/WritableRaster.class > java/awt/image/ColorConvertOp.class > java/awt/image/DirectColorModel.class > java/awt/image/Kernel.class > java/awt/image/ByteLookupTable.class > java/awt/image/DataBufferInt.class > java/awt/image/RasterOp.class > java/awt/image/ComponentSampleModel.class > java/awt/image/BandCombineOp.class > java/awt/image/BufferStrategy.class > java/awt/image/PackedColorModel.class > java/awt/image/DataBuffer$1.class > java/awt/image/ImagingOpException.class > java/awt/image/DataBufferShort.class > sun/ > sun/dc/ > sun/dc/pr/ > sun/dc/pr/PathFiller.class > sun/dc/pr/PRException.class > sun/dc/pr/PRError.class > sun/dc/pr/PathStroker.class > sun/dc/pr/Rasterizer$ConsumerDisposer.class > sun/dc/pr/Rasterizer.class > sun/dc/pr/PathDasher.class > sun/dc/path/ > sun/dc/path/PathConsumer.class > sun/dc/path/FastPathProducer.class > sun/dc/path/PathError.class > sun/dc/path/PathException.class From Kelly.Ohair at Sun.COM Wed May 16 20:58:33 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 16 May 2007 13:58:33 -0700 Subject: Which parts of the binary blob are actually needed? In-Reply-To: <200705161700.25638.bero@arklinux.org> References: <200705161700.25638.bero@arklinux.org> Message-ID: <464B7079.5050109@sun.com> Unofficial list is: Binary Libraries: lib/i386/libt2k.so (or bin/t2k.dll) lib/i386/libdcpr.so (or bin/dcpr.dll) lib/i386/libjsound.so (or bin/jsound.dll) and libjsoundalsa.so on Linux? Security Jar Files: lib/jce.jar lib/ext/sunjce_provider.jar lib/security/US_export_policy.jar lib/security/local_policy.jar Classes From rt.jar: com/sun/jmx/snmp/SnmpDataTypeEnums.class com/sun/jmx/snmp/SnmpDefinitions.class com/sun/jmx/snmp/SnmpOid.class com/sun/jmx/snmp/SnmpOidDatabase.class com/sun/jmx/snmp/SnmpOidDatabaseSupport.class com/sun/jmx/snmp/SnmpOidRecord.class com/sun/jmx/snmp/SnmpOidTable.class com/sun/jmx/snmp/SnmpOidTableSupport.class com/sun/jmx/snmp/SnmpParameters.class com/sun/jmx/snmp/SnmpPduPacket.class com/sun/jmx/snmp/SnmpPeer.class com/sun/jmx/snmp/SnmpTimeticks.class com/sun/jmx/snmp/SnmpVarBind.class com/sun/jmx/snmp/SnmpVarBindList.class com/sun/jmx/snmp/Timestamp.class com/sun/jmx/snmp/daemon/SendQ.class com/sun/jmx/snmp/daemon/SnmpInformRequest.class com/sun/jmx/snmp/daemon/SnmpQManager.class com/sun/jmx/snmp/daemon/SnmpRequestCounter.class com/sun/jmx/snmp/daemon/SnmpResponseHandler.class com/sun/jmx/snmp/daemon/SnmpSendServer.class com/sun/jmx/snmp/daemon/SnmpSession.class com/sun/jmx/snmp/daemon/SnmpSocket.class com/sun/jmx/snmp/daemon/SnmpTimerServer.class com/sun/jmx/snmp/daemon/WaitQ.class com/sun/media/sound/AbstractDataLine.class com/sun/media/sound/AbstractLine.class com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class com/sun/media/sound/AbstractMidiDevice$TransmitterList.class com/sun/media/sound/AbstractMidiDevice.class com/sun/media/sound/AbstractMidiDeviceProvider$Info.class com/sun/media/sound/AbstractMidiDeviceProvider.class com/sun/media/sound/AbstractMixer.class com/sun/media/sound/AbstractPlayer.class com/sun/media/sound/AiffFileFormat.class com/sun/media/sound/AiffFileReader.class com/sun/media/sound/AiffFileWriter.class com/sun/media/sound/AlawCodec$AlawCodecStream.class com/sun/media/sound/AlawCodec.class com/sun/media/sound/AuFileFormat.class com/sun/media/sound/AuFileReader.class com/sun/media/sound/AuFileWriter.class com/sun/media/sound/AutoClosingClip.class com/sun/media/sound/AutoConnectSequencer.class com/sun/media/sound/CircularBuffer.class com/sun/media/sound/DataPusher.class com/sun/media/sound/DirectAudioDevice$1.class com/sun/media/sound/DirectAudioDevice$DirectBAOS.class com/sun/media/sound/DirectAudioDevice$DirectClip.class com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class com/sun/media/sound/DirectAudioDevice$DirectDL.class com/sun/media/sound/DirectAudioDevice$DirectDLI.class com/sun/media/sound/DirectAudioDevice$DirectSDL.class com/sun/media/sound/DirectAudioDevice$DirectTDL.class com/sun/media/sound/DirectAudioDevice.class com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class com/sun/media/sound/DirectAudioDeviceProvider.class com/sun/media/sound/EventDispatcher$ClipInfo.class com/sun/media/sound/EventDispatcher$EventInfo.class com/sun/media/sound/EventDispatcher$LineMonitor.class com/sun/media/sound/EventDispatcher.class com/sun/media/sound/FastShortMessage.class com/sun/media/sound/FastSysexMessage.class com/sun/media/sound/HeadspaceInstrument.class com/sun/media/sound/HeadspaceMixer$1.class com/sun/media/sound/HeadspaceMixer$MidiLine.class com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class com/sun/media/sound/HeadspaceMixer$MixerInfo.class com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class com/sun/media/sound/HeadspaceMixer.class com/sun/media/sound/HeadspaceMixerProvider.class com/sun/media/sound/HeadspaceSample.class com/sun/media/sound/HeadspaceSoundbank.class com/sun/media/sound/HsbParser.class com/sun/media/sound/JDK13Services$1.class com/sun/media/sound/JDK13Services$ProviderCache.class com/sun/media/sound/JDK13Services.class com/sun/media/sound/JSSecurityManager$1.class com/sun/media/sound/JSSecurityManager$2.class com/sun/media/sound/JSSecurityManager$3.class com/sun/media/sound/JSSecurityManager$4.class com/sun/media/sound/JSSecurityManager$5.class com/sun/media/sound/JSSecurityManager$6.class com/sun/media/sound/JSSecurityManager$7.class com/sun/media/sound/JSSecurityManager.class com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class com/sun/media/sound/JavaSoundAudioClip.class com/sun/media/sound/MidiInDevice$1.class com/sun/media/sound/MidiInDevice$MidiInTransmitter.class com/sun/media/sound/MidiInDevice.class com/sun/media/sound/MidiInDeviceProvider$1.class com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class com/sun/media/sound/MidiInDeviceProvider.class com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class com/sun/media/sound/MidiOutDevice.class com/sun/media/sound/MidiOutDeviceProvider$1.class com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class com/sun/media/sound/MidiOutDeviceProvider.class com/sun/media/sound/MidiUtils$TempoCache.class com/sun/media/sound/MidiUtils.class com/sun/media/sound/MixerClip$1.class com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class com/sun/media/sound/MixerClip$MixerClipGainControl.class com/sun/media/sound/MixerClip$MixerClipMuteControl.class com/sun/media/sound/MixerClip$MixerClipPanControl.class com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class com/sun/media/sound/MixerClip.class com/sun/media/sound/MixerMidiChannel.class com/sun/media/sound/MixerSequencer$1.class com/sun/media/sound/MixerSequencer$ControllerVectorElement.class com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class com/sun/media/sound/MixerSequencer$RecordingTrack.class com/sun/media/sound/MixerSequencer.class com/sun/media/sound/MixerSequencerProvider.class com/sun/media/sound/MixerSourceLine$1.class com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class com/sun/media/sound/MixerSourceLine.class com/sun/media/sound/MixerSynth$1.class com/sun/media/sound/MixerSynth$MixerSynthInfo.class com/sun/media/sound/MixerSynth$SynthReceiver.class com/sun/media/sound/MixerSynth.class com/sun/media/sound/MixerSynthProvider.class com/sun/media/sound/MixerThread.class com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class com/sun/media/sound/PCMtoPCMCodec.class com/sun/media/sound/Platform.class com/sun/media/sound/PortMixer$1.class com/sun/media/sound/PortMixer$BoolCtrl$BCT.class com/sun/media/sound/PortMixer$BoolCtrl.class com/sun/media/sound/PortMixer$CompCtrl$CCT.class com/sun/media/sound/PortMixer$CompCtrl.class com/sun/media/sound/PortMixer$FloatCtrl$FCT.class com/sun/media/sound/PortMixer$FloatCtrl.class com/sun/media/sound/PortMixer$PortInfo.class com/sun/media/sound/PortMixer$PortMixerPort.class com/sun/media/sound/PortMixer.class com/sun/media/sound/PortMixerProvider$PortMixerInfo.class com/sun/media/sound/PortMixerProvider.class com/sun/media/sound/Printer.class com/sun/media/sound/RealTimeSequencer$1.class com/sun/media/sound/RealTimeSequencer$ControllerListElement.class com/sun/media/sound/RealTimeSequencer$DataPump.class com/sun/media/sound/RealTimeSequencer$PlayThread.class com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class com/sun/media/sound/RealTimeSequencer$RecordingTrack.class com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class com/sun/media/sound/RealTimeSequencer.class com/sun/media/sound/RealTimeSequencerProvider.class com/sun/media/sound/ReferenceCountingDevice.class com/sun/media/sound/RmfFileReader.class com/sun/media/sound/SMFParser.class com/sun/media/sound/SimpleInputDevice$1.class com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class com/sun/media/sound/SimpleInputDevice$InputDevicePort.class com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class com/sun/media/sound/SimpleInputDevice.class com/sun/media/sound/SimpleInputDeviceProvider$1.class com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class com/sun/media/sound/SimpleInputDeviceProvider.class com/sun/media/sound/StandardMidiFileReader.class com/sun/media/sound/StandardMidiFileWriter.class com/sun/media/sound/SunCodec.class com/sun/media/sound/SunFileReader.class com/sun/media/sound/SunFileWriter.class com/sun/media/sound/Toolkit.class com/sun/media/sound/UlawCodec$UlawCodecStream.class com/sun/media/sound/UlawCodec.class com/sun/media/sound/WaveFileFormat.class com/sun/media/sound/WaveFileReader.class com/sun/media/sound/WaveFileWriter.class java/awt/color/CMMException.class java/awt/color/ColorSpace.class java/awt/color/ICC_ColorSpace.class java/awt/color/ICC_Profile$1.class java/awt/color/ICC_Profile$2.class java/awt/color/ICC_Profile$3.class java/awt/color/ICC_Profile.class java/awt/color/ICC_ProfileGray.class java/awt/color/ICC_ProfileRGB.class java/awt/image/BandedSampleModel.class java/awt/image/ColorConvertOp.class java/awt/image/ComponentSampleModel.class java/awt/image/DataBuffer$1.class java/awt/image/DataBuffer.class java/awt/image/DataBufferByte.class java/awt/image/DataBufferInt.class java/awt/image/DataBufferShort.class java/awt/image/DataBufferUShort.class java/awt/image/MultiPixelPackedSampleModel.class java/awt/image/Raster.class java/awt/image/RenderedImage.class java/awt/image/SampleModel.class java/awt/image/SinglePixelPackedSampleModel.class java/awt/image/WritableRaster.class java/awt/image/WritableRenderedImage.class java/awt/image/renderable/ContextualRenderedImageFactory.class java/awt/image/renderable/ParameterBlock.class java/awt/image/renderable/RenderContext.class java/awt/image/renderable/RenderableImage.class java/awt/image/renderable/RenderableImageOp.class java/awt/image/renderable/RenderableImageProducer.class java/awt/image/renderable/RenderedImageFactory.class sun/dc/path/FastPathProducer.class sun/dc/path/PathConsumer.class sun/dc/path/PathError.class sun/dc/path/PathException.class sun/dc/pr/PRError.class sun/dc/pr/PRException.class sun/dc/pr/PathDasher.class sun/dc/pr/PathFiller.class sun/dc/pr/PathStroker.class sun/dc/pr/Rasterizer$ConsumerDisposer.class sun/dc/pr/Rasterizer.class -The End- -kto Bernhard Rosenkraenzer wrote: > I've just had a look at the "full" openjdk release -- and noticed the binary > blob is just about the size of the full jdk. I'm assuming it contains some > unnecessary bits (e.g. bits that will be replaced with components that are > built during the openjdk build process, such as the "java" and "javac" > executables). > > What parts of the blob actually make it to the final build? (And has anyone > checked if they can be replaced with components from any of the free JDK > reimplementations?) > > Regards, > bero From gnu_andrew at member.fsf.org Wed May 16 21:37:49 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 16 May 2007 22:37:49 +0100 Subject: Which parts of the binary blob are actually needed? In-Reply-To: <464B7079.5050109@sun.com> References: <200705161700.25638.bero@arklinux.org> <464B7079.5050109@sun.com> Message-ID: <200705162237.58372.gnu_andrew@member.fsf.org> On Wednesday 16 May 2007 21:58, Kelly O'Hair wrote: > Unofficial list is: > > Binary Libraries: > > lib/i386/libt2k.so (or bin/t2k.dll) > lib/i386/libdcpr.so (or bin/dcpr.dll) > lib/i386/libjsound.so (or bin/jsound.dll) and libjsoundalsa.so on Linux? > > Security Jar Files: > > lib/jce.jar > lib/ext/sunjce_provider.jar > lib/security/US_export_policy.jar > lib/security/local_policy.jar > > Classes From rt.jar: > > com/sun/jmx/snmp/SnmpDataTypeEnums.class > com/sun/jmx/snmp/SnmpDefinitions.class > com/sun/jmx/snmp/SnmpOid.class > com/sun/jmx/snmp/SnmpOidDatabase.class > com/sun/jmx/snmp/SnmpOidDatabaseSupport.class > com/sun/jmx/snmp/SnmpOidRecord.class > com/sun/jmx/snmp/SnmpOidTable.class > com/sun/jmx/snmp/SnmpOidTableSupport.class > com/sun/jmx/snmp/SnmpParameters.class > com/sun/jmx/snmp/SnmpPduPacket.class > com/sun/jmx/snmp/SnmpPeer.class > com/sun/jmx/snmp/SnmpTimeticks.class > com/sun/jmx/snmp/SnmpVarBind.class > com/sun/jmx/snmp/SnmpVarBindList.class > com/sun/jmx/snmp/Timestamp.class > com/sun/jmx/snmp/daemon/SendQ.class > com/sun/jmx/snmp/daemon/SnmpInformRequest.class > com/sun/jmx/snmp/daemon/SnmpQManager.class > com/sun/jmx/snmp/daemon/SnmpRequestCounter.class > com/sun/jmx/snmp/daemon/SnmpResponseHandler.class > com/sun/jmx/snmp/daemon/SnmpSendServer.class > com/sun/jmx/snmp/daemon/SnmpSession.class > com/sun/jmx/snmp/daemon/SnmpSocket.class > com/sun/jmx/snmp/daemon/SnmpTimerServer.class > com/sun/jmx/snmp/daemon/WaitQ.class > com/sun/media/sound/AbstractDataLine.class > com/sun/media/sound/AbstractLine.class > com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class > com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class > com/sun/media/sound/AbstractMidiDevice$TransmitterList.class > com/sun/media/sound/AbstractMidiDevice.class > com/sun/media/sound/AbstractMidiDeviceProvider$Info.class > com/sun/media/sound/AbstractMidiDeviceProvider.class > com/sun/media/sound/AbstractMixer.class > com/sun/media/sound/AbstractPlayer.class > com/sun/media/sound/AiffFileFormat.class > com/sun/media/sound/AiffFileReader.class > com/sun/media/sound/AiffFileWriter.class > com/sun/media/sound/AlawCodec$AlawCodecStream.class > com/sun/media/sound/AlawCodec.class > com/sun/media/sound/AuFileFormat.class > com/sun/media/sound/AuFileReader.class > com/sun/media/sound/AuFileWriter.class > com/sun/media/sound/AutoClosingClip.class > com/sun/media/sound/AutoConnectSequencer.class > com/sun/media/sound/CircularBuffer.class > com/sun/media/sound/DataPusher.class > com/sun/media/sound/DirectAudioDevice$1.class > com/sun/media/sound/DirectAudioDevice$DirectBAOS.class > com/sun/media/sound/DirectAudioDevice$DirectClip.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class > com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class > com/sun/media/sound/DirectAudioDevice$DirectDL.class > com/sun/media/sound/DirectAudioDevice$DirectDLI.class > com/sun/media/sound/DirectAudioDevice$DirectSDL.class > com/sun/media/sound/DirectAudioDevice$DirectTDL.class > com/sun/media/sound/DirectAudioDevice.class > > com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class > com/sun/media/sound/DirectAudioDeviceProvider.class > com/sun/media/sound/EventDispatcher$ClipInfo.class > com/sun/media/sound/EventDispatcher$EventInfo.class > com/sun/media/sound/EventDispatcher$LineMonitor.class > com/sun/media/sound/EventDispatcher.class > com/sun/media/sound/FastShortMessage.class > com/sun/media/sound/FastSysexMessage.class > com/sun/media/sound/HeadspaceInstrument.class > com/sun/media/sound/HeadspaceMixer$1.class > com/sun/media/sound/HeadspaceMixer$MidiLine.class > com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class > com/sun/media/sound/HeadspaceMixer$MixerInfo.class > > com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class > com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class > com/sun/media/sound/HeadspaceMixer.class > com/sun/media/sound/HeadspaceMixerProvider.class > com/sun/media/sound/HeadspaceSample.class > com/sun/media/sound/HeadspaceSoundbank.class > com/sun/media/sound/HsbParser.class > com/sun/media/sound/JDK13Services$1.class > com/sun/media/sound/JDK13Services$ProviderCache.class > com/sun/media/sound/JDK13Services.class > com/sun/media/sound/JSSecurityManager$1.class > com/sun/media/sound/JSSecurityManager$2.class > com/sun/media/sound/JSSecurityManager$3.class > com/sun/media/sound/JSSecurityManager$4.class > com/sun/media/sound/JSSecurityManager$5.class > com/sun/media/sound/JSSecurityManager$6.class > com/sun/media/sound/JSSecurityManager$7.class > com/sun/media/sound/JSSecurityManager.class > com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class > com/sun/media/sound/JavaSoundAudioClip.class > com/sun/media/sound/MidiInDevice$1.class > com/sun/media/sound/MidiInDevice$MidiInTransmitter.class > com/sun/media/sound/MidiInDevice.class > com/sun/media/sound/MidiInDeviceProvider$1.class > com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class > com/sun/media/sound/MidiInDeviceProvider.class > com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class > com/sun/media/sound/MidiOutDevice.class > com/sun/media/sound/MidiOutDeviceProvider$1.class > com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class > com/sun/media/sound/MidiOutDeviceProvider.class > com/sun/media/sound/MidiUtils$TempoCache.class > com/sun/media/sound/MidiUtils.class > com/sun/media/sound/MixerClip$1.class > com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class > com/sun/media/sound/MixerClip$MixerClipGainControl.class > com/sun/media/sound/MixerClip$MixerClipMuteControl.class > com/sun/media/sound/MixerClip$MixerClipPanControl.class > com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class > com/sun/media/sound/MixerClip.class > com/sun/media/sound/MixerMidiChannel.class > com/sun/media/sound/MixerSequencer$1.class > com/sun/media/sound/MixerSequencer$ControllerVectorElement.class > com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class > com/sun/media/sound/MixerSequencer$RecordingTrack.class > com/sun/media/sound/MixerSequencer.class > com/sun/media/sound/MixerSequencerProvider.class > com/sun/media/sound/MixerSourceLine$1.class > > com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class > com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class > com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class > com/sun/media/sound/MixerSourceLine.class > com/sun/media/sound/MixerSynth$1.class > com/sun/media/sound/MixerSynth$MixerSynthInfo.class > com/sun/media/sound/MixerSynth$SynthReceiver.class > com/sun/media/sound/MixerSynth.class > com/sun/media/sound/MixerSynthProvider.class > com/sun/media/sound/MixerThread.class > com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class > com/sun/media/sound/PCMtoPCMCodec.class > com/sun/media/sound/Platform.class > com/sun/media/sound/PortMixer$1.class > com/sun/media/sound/PortMixer$BoolCtrl$BCT.class > com/sun/media/sound/PortMixer$BoolCtrl.class > com/sun/media/sound/PortMixer$CompCtrl$CCT.class > com/sun/media/sound/PortMixer$CompCtrl.class > com/sun/media/sound/PortMixer$FloatCtrl$FCT.class > com/sun/media/sound/PortMixer$FloatCtrl.class > com/sun/media/sound/PortMixer$PortInfo.class > com/sun/media/sound/PortMixer$PortMixerPort.class > com/sun/media/sound/PortMixer.class > com/sun/media/sound/PortMixerProvider$PortMixerInfo.class > com/sun/media/sound/PortMixerProvider.class > com/sun/media/sound/Printer.class > com/sun/media/sound/RealTimeSequencer$1.class > com/sun/media/sound/RealTimeSequencer$ControllerListElement.class > com/sun/media/sound/RealTimeSequencer$DataPump.class > com/sun/media/sound/RealTimeSequencer$PlayThread.class > com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class > com/sun/media/sound/RealTimeSequencer$RecordingTrack.class > com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class > com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class > com/sun/media/sound/RealTimeSequencer.class > com/sun/media/sound/RealTimeSequencerProvider.class > com/sun/media/sound/ReferenceCountingDevice.class > com/sun/media/sound/RmfFileReader.class > com/sun/media/sound/SMFParser.class > com/sun/media/sound/SimpleInputDevice$1.class > com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class > com/sun/media/sound/SimpleInputDevice$InputDevicePort.class > com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class > com/sun/media/sound/SimpleInputDevice.class > com/sun/media/sound/SimpleInputDeviceProvider$1.class > com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class > com/sun/media/sound/SimpleInputDeviceProvider.class > com/sun/media/sound/StandardMidiFileReader.class > com/sun/media/sound/StandardMidiFileWriter.class > com/sun/media/sound/SunCodec.class > com/sun/media/sound/SunFileReader.class > com/sun/media/sound/SunFileWriter.class > com/sun/media/sound/Toolkit.class > com/sun/media/sound/UlawCodec$UlawCodecStream.class > com/sun/media/sound/UlawCodec.class > com/sun/media/sound/WaveFileFormat.class > com/sun/media/sound/WaveFileReader.class > com/sun/media/sound/WaveFileWriter.class > java/awt/color/CMMException.class > java/awt/color/ColorSpace.class > java/awt/color/ICC_ColorSpace.class > java/awt/color/ICC_Profile$1.class > java/awt/color/ICC_Profile$2.class > java/awt/color/ICC_Profile$3.class > java/awt/color/ICC_Profile.class > java/awt/color/ICC_ProfileGray.class > java/awt/color/ICC_ProfileRGB.class > java/awt/image/BandedSampleModel.class > java/awt/image/ColorConvertOp.class > java/awt/image/ComponentSampleModel.class > java/awt/image/DataBuffer$1.class > java/awt/image/DataBuffer.class > java/awt/image/DataBufferByte.class > java/awt/image/DataBufferInt.class > java/awt/image/DataBufferShort.class > java/awt/image/DataBufferUShort.class > java/awt/image/MultiPixelPackedSampleModel.class > java/awt/image/Raster.class > java/awt/image/RenderedImage.class > java/awt/image/SampleModel.class > java/awt/image/SinglePixelPackedSampleModel.class > java/awt/image/WritableRaster.class > java/awt/image/WritableRenderedImage.class > java/awt/image/renderable/ContextualRenderedImageFactory.class > java/awt/image/renderable/ParameterBlock.class > java/awt/image/renderable/RenderContext.class > java/awt/image/renderable/RenderableImage.class > java/awt/image/renderable/RenderableImageOp.class > java/awt/image/renderable/RenderableImageProducer.class > java/awt/image/renderable/RenderedImageFactory.class > sun/dc/path/FastPathProducer.class > sun/dc/path/PathConsumer.class > sun/dc/path/PathError.class > sun/dc/path/PathException.class > sun/dc/pr/PRError.class > sun/dc/pr/PRException.class > sun/dc/pr/PathDasher.class > sun/dc/pr/PathFiller.class > sun/dc/pr/PathStroker.class > sun/dc/pr/Rasterizer$ConsumerDisposer.class > sun/dc/pr/Rasterizer.class > > -The End- > > -kto > > Bernhard Rosenkraenzer wrote: > > I've just had a look at the "full" openjdk release -- and noticed the > > binary blob is just about the size of the full jdk. I'm assuming it > > contains some unnecessary bits (e.g. bits that will be replaced with > > components that are built during the openjdk build process, such as the > > "java" and "javac" executables). > > > > What parts of the blob actually make it to the final build? (And has > > anyone checked if they can be replaced with components from any of the > > free JDK reimplementations?) > > > > Regards, > > bero A number of the GNU Classpath developers (including myself) are looking into how OpenJDK can be built, in its present form, without the binary dependencies, through various methods such as using bits of Classpath, breaking of small chunks, etc. Sun is also of course working towards this in the long term, with the community when a process of committing patches is established. -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dfabulich at warpmail.net Fri May 18 05:42:44 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Thu, 17 May 2007 22:42:44 -0700 (Pacific Daylight Time) Subject: Which parts of the binary blob are actually needed? In-Reply-To: <464B7079.5050109@sun.com> References: <200705161700.25638.bero@arklinux.org> <464B7079.5050109@sun.com> Message-ID: Kelly O'Hair wrote: > Binary Libraries: > > lib/i386/libt2k.so (or bin/t2k.dll) Don't forget that you can't build OpenJDK on Windows because you need t2k.lib, not t2k.dll. t2k.lib is not distributed in the Windows binary plugs, so doing a build on that platform is impossible. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 -Dan From Tom.Marble at Sun.COM Sat May 19 21:03:40 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sat, 19 May 2007 16:03:40 -0500 Subject: test message Message-ID: <464F662C.2050801@sun.com> All: Please ignore this test message. --Tom From dfabulich at warpmail.net Mon May 21 05:47:40 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Sun, 20 May 2007 22:47:40 -0700 (Pacific Daylight Time) Subject: Which parts of the binary blob are actually needed? In-Reply-To: <007201c79b14$d548d5c0$802ca8c0@XPWork> References: <007201c79b14$d548d5c0$802ca8c0@XPWork> Message-ID: Ted Neward wrote: > Why is that? And is there someplace else one can find the t2k.dll? The DLL *is* included in the binary plugs, but you need t2k.lib, not t2k.dll. As far as I know, the .lib file is not available for download anywhere. However, Dmitri suggested a workaround: it should be possible to grab the source code for the non-open JRL JDK 7 and build that from scratch. That will generate a t2k.lib that you could use for building the OpenJDK. I don't know whether that works because I don't want to contaminate the GPL OpenJDK with details from the JRL JDK, but someone could try it and tell me if it works. It's probably best to just wait until the folks at Sun release working binary plugs for Windows. However, that may not happen; instead, we may have to wait until the font rasterizer is fully replaced. -Dan >> -----Original Message----- >> Don't forget that you can't build OpenJDK on Windows because you need >> t2k.lib, not t2k.dll. t2k.lib is not distributed in the Windows binary >> plugs, so doing a build on that platform is impossible. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 From ted at tedneward.com Sun May 20 19:26:54 2007 From: ted at tedneward.com (Ted Neward) Date: Sun, 20 May 2007 12:26:54 -0700 Subject: Which parts of the binary blob are actually needed? In-Reply-To: Message-ID: <007201c79b14$d548d5c0$802ca8c0@XPWork> Why is that? And is there someplace else one can find the t2k.dll? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > bounces at openjdk.java.net] On Behalf Of Dan Fabulich > Sent: Thursday, May 17, 2007 10:43 PM > To: Kelly O'Hair > Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.dev.java.net > Subject: Re: Which parts of the binary blob are actually needed? > > Kelly O'Hair wrote: > > > Binary Libraries: > > > > lib/i386/libt2k.so (or bin/t2k.dll) > > Don't forget that you can't build OpenJDK on Windows because you need > t2k.lib, not t2k.dll. t2k.lib is not distributed in the Windows binary > plugs, so doing a build on that platform is impossible. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 > > -Dan > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 5/15/2007 > 10:47 AM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.6/813 - Release Date: 5/20/2007 7:54 AM From betelgeuse at gentoo.org Tue May 22 16:47:16 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Tue, 22 May 2007 19:47:16 +0300 Subject: FYI Permission problems when building using Gentoo ebuild Message-ID: <46531E94.8030400@gentoo.org> 19:34 < Betelgeuse> Anyone seeing 600 permissions popping up in the build target? 19:38 < tmarble> note that the import JDK (i.e. with the plugs) does not have execute permission (it's intended only for building) 19:40 < Betelgeuse> tmarble: I don't use that. Remember the no GUI rule? 19:40 < Betelgeuse> tmarble: I don't think I am allowed to repackage it either? 19:40 < tmarble> of course, that's the one permissions issue i'm aware of 19:40 < tmarble> correct 19:41 < Betelgeuse> tmarble: http://forums.gentoo.org/viewtopic-t-558122-highlight-openjdk.html 19:41 < Betelgeuse> tmarble: for some reason the files get installed as 600 19:41 < Betelgeuse> tmarble: I guess I will end up resetting the permissions but would like to find out what makes it do that 19:42 < Betelgeuse> tmarble: I haven't been able to reproduce this myself but multiple people have 19:43 < tmarble> hmm.. has this been linked in a post to build-dev? seems like the logical next step 19:44 < Betelgeuse> tmarble: Well I could but you would need Gentoo to debug it 19:44 < Betelgeuse> tmarble: Maybe mr is interested :) 19:44 < Betelgeuse> tmarble: nichoj hit the issue so I hope he will be able to provide meaningful info 19:45 < tmarble> well the concern, of course, is that this is a general (not gentoo specific) problem... and in any case I think all should see that forum post 19:45 < Betelgeuse> Well I will mail it to build-dev http://forums.gentoo.org/viewtopic-t-558122-highlight-openjdk.html Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From betelgeuse at gentoo.org Tue May 22 17:13:27 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Tue, 22 May 2007 20:13:27 +0300 Subject: Permission problems when building using Gentoo ebuild In-Reply-To: <46531E94.8030400@gentoo.org> References: <46531E94.8030400@gentoo.org> Message-ID: <465324B7.7040702@gentoo.org> Petteri R?ty kirjoitti: > 19:44 < Betelgeuse> tmarble: nichoj hit the issue so I hope he will be > able to provide meaningful info 20:08 <@nichoj_work> # find -name libjli.so -exec ls -l {} \; 20:08 <@nichoj_work> -rwxr-xr-x 1 portage portage 19410 May 22 11:59 ./build/linux-i586/lib/i386/jli/libjli.so 20:08 <@nichoj_work> -rw------- 1 portage portage 19410 May 22 12:14 ./build/linux-i586/j2re-image/lib/i386/jli/libjli.so 20:08 <@nichoj_work> -rw------- 1 portage portage 19410 May 22 12:14 ./build/linux-i586/j2sdk-image/jre/lib/i386/jli/libjli.so So it does seem like something that could be happening on other distributions too. Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From flameeyes at gmail.com Wed May 23 20:00:25 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Wed, 23 May 2007 22:00:25 +0200 Subject: [PATCH] enable -z defs usage on all Linux targets Message-ID: <20070523220025.48d8783c@enterprise.flameeyes.is-a-geek.org> The gmk file currnetly allow usage of -z defs as LDFLAGS only for arches that are not PPC and are not 64-bit, without any comment on why this happens; counting that PPC Linux does not seem to be supported by OpenJDK anyway at the moment, -z defs works *mostly* fine on AMD64 Linux. Where mostly is referred to demos that links using gcc even when the source code is C++, using the LIBCXX variable to fix the link; this works fine, unless you use STATIC_CXX=false at build time to use runtime link to libstdc++. The attached patch removes the conditionals and fixes the libstdc++ build, allowing a safer build with -z defs enabled even on amd64. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-noundef.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: