From david.holmes at oracle.com Mon Sep 3 01:26:54 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Sep 2012 11:26:54 +1000 Subject: debuginfo/diz files in built images Message-ID: <5044075E.50301@oracle.com> The build will create debuginfo/diz files as requested - that's fine. What I'm unclear about is where those files should actually appear in our build artifacts, specifically the jdk/jre images that are created. Internally when we create binary images RE strips all the debuginfo/diz files out. But the build itself seems to treat them in an ad-hoc manner: - The new build deliberately excludes debuginfo/diz files associated with binaries, but will include any related to libraries (via generic copying routine). (It's obvious from the comments related to this that there is some puzzlement as to this reasoning.) - The old build also tries to exclude the files associated with binaries, but only handles .debuginfo not .diz :( Those associated with libraries just seem to get copied if they happen to be there As I said this all seems very ad-hoc to me. I would expect to see no debuginfo/diz files in a created image by default, and have a separate target that would produce a tar file of all the debuginfo/diz files ready to overlay on an existing image. Thoughts/comments? I have to deal with this for the SE Profile work, where we will not want these files present in any of the images. David From daniel.daugherty at oracle.com Mon Sep 3 02:47:24 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 02 Sep 2012 20:47:24 -0600 Subject: debuginfo/diz files in built images In-Reply-To: <5044075E.50301@oracle.com> References: <5044075E.50301@oracle.com> Message-ID: <50441A3C.5040001@oracle.com> On 9/2/12 7:26 PM, David Holmes wrote: > The build will create debuginfo/diz files as requested - that's fine. > > What I'm unclear about is where those files should actually appear in > our build artifacts, specifically the jdk/jre images that are created. > > Internally when we create binary images RE strips all the > debuginfo/diz files out. Not quite. The RE makefiles will put debug info files into a separate debuginfo.zip file. This includes .debuginfo, .diz, .map and .pdb files. For the regular bundles, the RE makefiles will not include debug info files. Not quite the same as stripping them out. > But the build itself seems to treat them in an ad-hoc manner: > > - The new build deliberately excludes debuginfo/diz files associated > with binaries, but will include any related to libraries (via generic > copying routine). (It's obvious from the comments related to this that > there is some puzzlement as to this reasoning.) Sorry I haven't looked at the new build system. > - The old build also tries to exclude the files associated with > binaries, but only handles .debuginfo not .diz :( During one round in the FDS project, I included .debuginfo/.diz files right next to some of the binaries. Apparently that's not allowed without explicit permission. The contents of the "bin" directory are controlled and there are tests to verify those contents. I changed the Makefiles for the few binaries that support FDS to not install the debug info files with the binaries, but they are left in the normal build artifacts location if someone has the need to use them. Of course, I've had queries for debug info files for the binaries to be included in the debuginfo.zip bundles. I'm not planning to fight that battle. > Those associated with libraries just seem to get copied if they happen > to be there All of the logic that copies debug info files to the image should do so if they happen to be there. Not all component support FDS now or in the future so the logic needs to adapt to what is built. > As I said this all seems very ad-hoc to me. I would expect to see no > debuginfo/diz files in a created image by default, and have a separate > target that would produce a tar file of all the debuginfo/diz files > ready to overlay on an existing image. Close. The image has to have the debug info or .diz files in order for the RE makefiles to generate the debuginfo.zip files. It is the RE makefiles that handle the packaging. Just like the demos are always built and it is the RE makefiles that put them in a separate bundle. > Thoughts/comments? > > I have to deal with this for the SE Profile work, where we will not > want these files present in any of the images. It should be fine if the Embedded profile does not generate debug info files or if the Embedded profile generates debug info, but does not copy the debug info files into the image area. The RE makefiles will handle the presence or absence of debug info files. However, the non-Embedded profile needs to continue to generate and copy debug info files for those components that already support FDS. If you change the non-Embedded logic to not copy the debug info files into the image area, the RE debuginfo.zip bundle will not be created and that will break FDS. Dan > > David From david.holmes at oracle.com Mon Sep 3 03:37:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Sep 2012 13:37:29 +1000 Subject: debuginfo/diz files in built images In-Reply-To: <50441A3C.5040001@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> Message-ID: <504425F9.6020405@oracle.com> Hi Dan, On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: > On 9/2/12 7:26 PM, David Holmes wrote: >> The build will create debuginfo/diz files as requested - that's fine. >> >> What I'm unclear about is where those files should actually appear in >> our build artifacts, specifically the jdk/jre images that are created. >> >> Internally when we create binary images RE strips all the >> debuginfo/diz files out. > > Not quite. The RE makefiles will put debug info files into a > separate debuginfo.zip file. This includes .debuginfo, .diz, > .map and .pdb files. For the regular bundles, the RE makefiles > will not include debug info files. Not quite the same as > stripping them out. Not trying to split hairs but if the image contains them and the RE bundle of the image does not, then the RE process is stripping them out. >> But the build itself seems to treat them in an ad-hoc manner: >> >> - The new build deliberately excludes debuginfo/diz files associated >> with binaries, but will include any related to libraries (via generic >> copying routine). (It's obvious from the comments related to this that >> there is some puzzlement as to this reasoning.) > > Sorry I haven't looked at the new build system. It tries to emulate the old build. >> - The old build also tries to exclude the files associated with >> binaries, but only handles .debuginfo not .diz :( > > During one round in the FDS project, I included .debuginfo/.diz files > right next to some of the binaries. Apparently that's not allowed without > explicit permission. The contents of the "bin" directory are controlled > and there are tests to verify those contents. > > I changed the Makefiles for the few binaries that support FDS to not > install the debug info files with the binaries, but they are left in > the normal build artifacts location if someone has the need to use > them. Of course, I've had queries for debug info files for the binaries > to be included in the debuginfo.zip bundles. I'm not planning to fight > that battle. Okay that explains the special handling for binaries. So how do these then get into the debuginfo.zip? Or don't they? >> Those associated with libraries just seem to get copied if they happen >> to be there > > All of the logic that copies debug info files to the image should do > so if they happen to be there. Not all component support FDS now or > in the future so the logic needs to adapt to what is built. > > >> As I said this all seems very ad-hoc to me. I would expect to see no >> debuginfo/diz files in a created image by default, and have a separate >> target that would produce a tar file of all the debuginfo/diz files >> ready to overlay on an existing image. > > Close. The image has to have the debug info or .diz files in order for > the RE makefiles to generate the debuginfo.zip files. It is the RE > makefiles that handle the packaging. Just like the demos are always > built and it is the RE makefiles that put them in a separate bundle. So therein lies the problem. RE lies outside of the OpenJDK build system. If the RE Makefiles can copy an image they can copy the debuginfo files too. I'd much rather see no debuginfo files in the built images (unless requested) and a distinct debuginfo related target (that RE could use if they choose). That would seem to be simpler all round. >> Thoughts/comments? >> >> I have to deal with this for the SE Profile work, where we will not >> want these files present in any of the images. > > It should be fine if the Embedded profile does not generate debug info > files or if the Embedded profile generates debug info, but does not > copy the debug info files into the image area. The RE makefiles will > handle the presence or absence of debug info files. These are not embedded profiles, these are just profiles - it is all to be part of SE in Java 8. The build is supposed to create an image corresponding to each profile. I can certainly specialise the handling of the debuginfo files for the profiles, but it seemed to me that the overall debuginfo-in-image story was rather unclear. > However, the non-Embedded profile needs to continue to generate and > copy debug info files for those components that already support FDS. > If you change the non-Embedded logic to not copy the debug info files > into the image area, the RE debuginfo.zip bundle will not be created > and that will break FDS. RE processes will have to change to handle profiles in any case. I think they'd rather get a debuginfo.zip out of the build than having to create it themselves. Thanks, David > > Dan > > >> >> David From artem.ananiev at oracle.com Mon Sep 3 10:37:05 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 03 Sep 2012 14:37:05 +0400 Subject: Windows build failure when building JLI Message-ID: <50448851.90808@oracle.com> Hi, build-dev, (please, keep me in CC as I'm not subscribed to this mailing list) I'm (again) trying to build JDK8 on my Windows box using new build infrastructure, based on autoconf. The build fails somewhere in JLI section. I can't provide the error log right now, as I've already found the workaround: 1. Add cmdtoargs.c to the list of compiled files Without it the linker complains about unresolved JLI_GetStdArgs and JLI_GetStdArgc symbols 2. Add several -export: flags, so all the required JLI functions are exported and can be found by launcher sources (main.c) Note that the old Makefiles do contain both cmdtoargs.c and exports listed above. I'm not an expert in building JDK, so it's quite possible I'm just doing something wrong. Anyway, here is the webrev: http://cr.openjdk.java.net/~art/jdk8/build-jli-cmdtoargs/ Please, let me know if this is a bug or a feature and if I need to file a new change request or not. Thanks, Artem From erik.joelsson at oracle.com Mon Sep 3 11:12:30 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 03 Sep 2012 13:12:30 +0200 Subject: Windows build failure when building JLI In-Reply-To: <50448851.90808@oracle.com> References: <50448851.90808@oracle.com> Message-ID: <5044909E.5000507@oracle.com> Hello Artem, Unfortunately the new build slowly gets outdated in the jdk8 repositories other than build-infra, where it is being developed. Please also note that the new build is still only a preview, and we are not yet guaranteeing correct results from it. You are correct with the patch. I've done that correction in build-infra already. We have been meaning to push another update to the new build from build-infra to jdk8 for a while now. We should probably try to get that done as soon as possible since people are suffering from this. If this change is to be applied on its own, it also needs to update the mapfile: diff -r 156ab3c38556 makefiles/mapfiles/libjli/mapfile-vers --- a/makefiles/mapfiles/libjli/mapfile-vers +++ b/makefiles/mapfiles/libjli/mapfile-vers @@ -34,6 +34,9 @@ JLI_ReportErrorMessageSys; JLI_ReportMessage; JLI_ReportExceptionDescription; + JLI_GetStdArgs; + JLI_GetStdArgc; local: *; }; /Erik On 2012-09-03 12:37, Artem Ananiev wrote: > Hi, build-dev, > > (please, keep me in CC as I'm not subscribed to this mailing list) > > I'm (again) trying to build JDK8 on my Windows box using new build > infrastructure, based on autoconf. The build fails somewhere in JLI > section. I can't provide the error log right now, as I've already > found the workaround: > > 1. Add cmdtoargs.c to the list of compiled files > > Without it the linker complains about unresolved JLI_GetStdArgs and > JLI_GetStdArgc symbols > > 2. Add several -export: flags, so all the required JLI functions are > exported and can be found by launcher sources (main.c) > > Note that the old Makefiles do contain both cmdtoargs.c and exports > listed above. I'm not an expert in building JDK, so it's quite > possible I'm just doing something wrong. > > Anyway, here is the webrev: > > http://cr.openjdk.java.net/~art/jdk8/build-jli-cmdtoargs/ > > Please, let me know if this is a bug or a feature and if I need to > file a new change request or not. > > Thanks, > > Artem From david.holmes at oracle.com Mon Sep 3 11:12:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Sep 2012 21:12:28 +1000 Subject: Windows build failure when building JLI In-Reply-To: <50448851.90808@oracle.com> References: <50448851.90808@oracle.com> Message-ID: <5044909C.5030908@oracle.com> Hi Artem, That sounds like some recent command-line parsing changes for wildcards didn't get applied to the new build files. cc'ing Kumar as the author of those changes. David On 3/09/2012 8:37 PM, Artem Ananiev wrote: > Hi, build-dev, > > (please, keep me in CC as I'm not subscribed to this mailing list) > > I'm (again) trying to build JDK8 on my Windows box using new build > infrastructure, based on autoconf. The build fails somewhere in JLI > section. I can't provide the error log right now, as I've already found > the workaround: > > 1. Add cmdtoargs.c to the list of compiled files > > Without it the linker complains about unresolved JLI_GetStdArgs and > JLI_GetStdArgc symbols > > 2. Add several -export: flags, so all the required JLI functions are > exported and can be found by launcher sources (main.c) > > Note that the old Makefiles do contain both cmdtoargs.c and exports > listed above. I'm not an expert in building JDK, so it's quite possible > I'm just doing something wrong. > > Anyway, here is the webrev: > > http://cr.openjdk.java.net/~art/jdk8/build-jli-cmdtoargs/ > > Please, let me know if this is a bug or a feature and if I need to file > a new change request or not. > > Thanks, > > Artem From dalibor.topic at oracle.com Mon Sep 3 11:18:10 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 03 Sep 2012 13:18:10 +0200 Subject: webrev failure? In-Reply-To: References: <5027939A.8060209@oracle.com> Message-ID: <504491F2.2000502@oracle.com> On 8/12/12 1:39 PM, Martijn Verburg wrote: > Hi David, > > Aha! :-). Any ideas on how far I need to downgrade the version of hg? > (I'm 2.3 at the moment). 2.2.3 works fine for me. See http://robilad.livejournal.com/125607.html for how to do it on MacPorts, assuming you've had it installed from MacPorts and working before. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From martijnverburg at gmail.com Mon Sep 3 11:31:00 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 3 Sep 2012 12:31:00 +0100 Subject: webrev failure? In-Reply-To: <504491F2.2000502@oracle.com> References: <5027939A.8060209@oracle.com> <504491F2.2000502@oracle.com> Message-ID: Yep, had that done already, I'll link to your blog post for the Adopt OpenJDK build - Thanks! Martijn On 3 September 2012 12:18, Dalibor Topic wrote: > On 8/12/12 1:39 PM, Martijn Verburg wrote: >> Hi David, >> >> Aha! :-). Any ideas on how far I need to downgrade the version of hg? >> (I'm 2.3 at the moment). > > 2.2.3 works fine for me. See http://robilad.livejournal.com/125607.html > for how to do it on MacPorts, assuming you've had it installed from > MacPorts and working before. > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From artem.ananiev at oracle.com Mon Sep 3 11:54:09 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 03 Sep 2012 15:54:09 +0400 Subject: Windows build failure when building JLI In-Reply-To: <5044909E.5000507@oracle.com> References: <50448851.90808@oracle.com> <5044909E.5000507@oracle.com> Message-ID: <50449A61.5070504@oracle.com> Hi, Erik, it's good to know that the work is in progress. I will leave the changes locally in my workspace then and wait for the next synchronization between build-infra and jdk8 master. BTW, what's the reason to continue the new build infrastructure development in a separate project (build-infra), not in the master workspace? On 9/3/2012 3:12 PM, Erik Joelsson wrote: > Hello Artem, > > Unfortunately the new build slowly gets outdated in the jdk8 > repositories other than build-infra, where it is being developed. Please > also note that the new build is still only a preview, and we are not yet > guaranteeing correct results from it. > > You are correct with the patch. I've done that correction in build-infra > already. We have been meaning to push another update to the new build > from build-infra to jdk8 for a while now. We should probably try to get > that done as soon as possible since people are suffering from this. > > If this change is to be applied on its own, it also needs to update the > mapfile: > > diff -r 156ab3c38556 makefiles/mapfiles/libjli/mapfile-vers > --- a/makefiles/mapfiles/libjli/mapfile-vers > +++ b/makefiles/mapfiles/libjli/mapfile-vers > @@ -34,6 +34,9 @@ > JLI_ReportErrorMessageSys; > JLI_ReportMessage; > JLI_ReportExceptionDescription; > + JLI_GetStdArgs; > + JLI_GetStdArgc; > local: > *; > }; Right, I noticed it, but forgot to add to my webrev :) Thanks, Artem > /Erik > > On 2012-09-03 12:37, Artem Ananiev wrote: >> Hi, build-dev, >> >> (please, keep me in CC as I'm not subscribed to this mailing list) >> >> I'm (again) trying to build JDK8 on my Windows box using new build >> infrastructure, based on autoconf. The build fails somewhere in JLI >> section. I can't provide the error log right now, as I've already >> found the workaround: >> >> 1. Add cmdtoargs.c to the list of compiled files >> >> Without it the linker complains about unresolved JLI_GetStdArgs and >> JLI_GetStdArgc symbols >> >> 2. Add several -export: flags, so all the required JLI functions are >> exported and can be found by launcher sources (main.c) >> >> Note that the old Makefiles do contain both cmdtoargs.c and exports >> listed above. I'm not an expert in building JDK, so it's quite >> possible I'm just doing something wrong. >> >> Anyway, here is the webrev: >> >> http://cr.openjdk.java.net/~art/jdk8/build-jli-cmdtoargs/ >> >> Please, let me know if this is a bug or a feature and if I need to >> file a new change request or not. >> >> Thanks, >> >> Artem From magnus.ihse.bursie at oracle.com Tue Sep 4 11:53:29 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Sep 2012 13:53:29 +0200 Subject: Windows build failure when building JLI In-Reply-To: <50449A61.5070504@oracle.com> References: <50448851.90808@oracle.com> <5044909E.5000507@oracle.com> <50449A61.5070504@oracle.com> Message-ID: <8015E8B0-EC66-4256-A20E-7880E99C6828@oracle.com> > BTW, what's the reason to continue the new build infrastructure development in a separate project (build-infra), not in the master workspace? There are strict formal rules on the build forest, that every single commit should have a WebRev and a CR. That would be highly impractical since build-infra is still under active development. /Magnus From daniel.daugherty at oracle.com Tue Sep 4 13:51:08 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 04 Sep 2012 07:51:08 -0600 Subject: debuginfo/diz files in built images In-Reply-To: <504425F9.6020405@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> Message-ID: <5046074C.8080402@oracle.com> On 9/2/12 9:37 PM, David Holmes wrote: > Hi Dan, > > On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >> On 9/2/12 7:26 PM, David Holmes wrote: >>> The build will create debuginfo/diz files as requested - that's fine. >>> >>> What I'm unclear about is where those files should actually appear in >>> our build artifacts, specifically the jdk/jre images that are created. >>> >>> Internally when we create binary images RE strips all the >>> debuginfo/diz files out. >> >> Not quite. The RE makefiles will put debug info files into a >> separate debuginfo.zip file. This includes .debuginfo, .diz, >> .map and .pdb files. For the regular bundles, the RE makefiles >> will not include debug info files. Not quite the same as >> stripping them out. > > Not trying to split hairs but if the image contains them and the RE > bundle of the image does not, then the RE process is stripping them out. The above is implying that there is a single RE bundle and that hasn't been true for the tar-style universe for quite a long time; the demo bundle was added by around JDK8-B20 or so. For the package-style universe, I don't think that has ever been true. RE's makefiles take the image generated by the build and package up the various files into two or more bundles. I believe each platform has two styles of bundles. For Solaris, SVR4 style packages and tar/zip bundles. For Windows, an EXE installer and tar/zip bundles. For Linux RPM packages and tar/ZIP bundles. So I'll stick with my assertion that the RE process is placing debug info files into a separate bundle and is not stripping them out. > >>> But the build itself seems to treat them in an ad-hoc manner: >>> >>> - The new build deliberately excludes debuginfo/diz files associated >>> with binaries, but will include any related to libraries (via generic >>> copying routine). (It's obvious from the comments related to this that >>> there is some puzzlement as to this reasoning.) >> >> Sorry I haven't looked at the new build system. > > It tries to emulate the old build. > >>> - The old build also tries to exclude the files associated with >>> binaries, but only handles .debuginfo not .diz :( >> >> During one round in the FDS project, I included .debuginfo/.diz files >> right next to some of the binaries. Apparently that's not allowed >> without >> explicit permission. The contents of the "bin" directory are controlled >> and there are tests to verify those contents. >> >> I changed the Makefiles for the few binaries that support FDS to not >> install the debug info files with the binaries, but they are left in >> the normal build artifacts location if someone has the need to use >> them. Of course, I've had queries for debug info files for the binaries >> to be included in the debuginfo.zip bundles. I'm not planning to fight >> that battle. > > Okay that explains the special handling for binaries. So how do these > then get into the debuginfo.zip? Or don't they? They don't. They are only available via the build artifacts that are archived. > >>> Those associated with libraries just seem to get copied if they happen >>> to be there >> >> All of the logic that copies debug info files to the image should do >> so if they happen to be there. Not all component support FDS now or >> in the future so the logic needs to adapt to what is built. >> >> >>> As I said this all seems very ad-hoc to me. I would expect to see no >>> debuginfo/diz files in a created image by default, and have a separate >>> target that would produce a tar file of all the debuginfo/diz files >>> ready to overlay on an existing image. >> >> Close. The image has to have the debug info or .diz files in order for >> the RE makefiles to generate the debuginfo.zip files. It is the RE >> makefiles that handle the packaging. Just like the demos are always >> built and it is the RE makefiles that put them in a separate bundle. > > So therein lies the problem. RE lies outside of the OpenJDK build > system. If the RE Makefiles can copy an image they can copy the > debuginfo files too. I'd much rather see no debuginfo files in the > built images (unless requested) and a distinct debuginfo related > target (that RE could use if they choose). That would seem to be > simpler all round. My understanding is that "the image" is supposed to be the complete image if every bundle is extracted. I believe that is how the packages are sanity checked to be complete. RE's Makefiles are meant to process "the image" into bundles. They aren't meant to add files of their own. If you are planning to change the meaning of "the image" or if you are planning to put files into bundles that are not in "the image", then you'll need to coordinate with RE and whoever does the package inventory testing. Also, if you change the way this works, keep in mind that some of the Makefiles generate their objects into a temporary directory and then copy things from that temporary directory to the image. Other Makefiles generate their objects directly into the image. For the latter, you'll have to move the debug info file(s) out of the image into some other place where it can be picked up by whatever bundling process you create to make the debuginfo.zip file. > >>> Thoughts/comments? >>> >>> I have to deal with this for the SE Profile work, where we will not >>> want these files present in any of the images. >> >> It should be fine if the Embedded profile does not generate debug info >> files or if the Embedded profile generates debug info, but does not >> copy the debug info files into the image area. The RE makefiles will >> handle the presence or absence of debug info files. > > These are not embedded profiles, these are just profiles - it is all > to be part of SE in Java 8. The build is supposed to create an image > corresponding to each profile. I can certainly specialise the handling > of the debuginfo files for the profiles, but it seemed to me that the > overall debuginfo-in-image story was rather unclear. I'm sorry you think that the debuginfo-in-image story is unclear. I thought I did a pretty good job integrating FDS into the whole OpenJDK build process somewhat seamlessly. I guess not. The key things to remember in all this is that debug info files (like the demos) have to end up in a separate bundle or bundles. So if you change the way this is all implemented, you still have to follow the separate bundle rule. > >> However, the non-Embedded profile needs to continue to generate and >> copy debug info files for those components that already support FDS. >> If you change the non-Embedded logic to not copy the debug info files >> into the image area, the RE debuginfo.zip bundle will not be created >> and that will break FDS. > > RE processes will have to change to handle profiles in any case. I > think they'd rather get a debuginfo.zip out of the build than having > to create it themselves. Interesting and not something that I have ever heard. I got the impression that RE needed to have control over what was bundled and how it was bundled. It's kind of hard to certify/vouch for a process when you don't do it yourself, but that's not really my call. Good luck with the tweaking of the build and packaging processes. Just remember: There be dragons here! Dan > > Thanks, > David > >> >> Dan >> >> >>> >>> David From david.holmes at oracle.com Wed Sep 5 10:46:01 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Sep 2012 20:46:01 +1000 Subject: debuginfo/diz files in built images In-Reply-To: <5046074C.8080402@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> <5046074C.8080402@oracle.com> Message-ID: <50472D69.1060209@oracle.com> Dan, Sorry, not meaning to ruffle your feathers. The reason I say the diz-in-image story is unclear is because there are no explicit rules that indicates that diz files should end up in a JDK or JRE image. I can accept that everything should go in a full JDK image. But a JRE is a JDK with a bunch of things left out and some of those things are libraries. But because diz files are not mentioned explicitly in the rules for making images we actually get the diz files for the libraries that were removed! They are simply copied from the build artifacts location to the jre image location specifically libattach.diz and libsaproc.diz. Maybe that was a simple oversight. Additionally it is unclear to me why we have diz files for some libraries and not others? Anyway as I said this will need to be modified for the profile work, in consultation with all the interested parties. Thanks, David On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: > On 9/2/12 9:37 PM, David Holmes wrote: >> Hi Dan, >> >> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>> On 9/2/12 7:26 PM, David Holmes wrote: >>>> The build will create debuginfo/diz files as requested - that's fine. >>>> >>>> What I'm unclear about is where those files should actually appear in >>>> our build artifacts, specifically the jdk/jre images that are created. >>>> >>>> Internally when we create binary images RE strips all the >>>> debuginfo/diz files out. >>> >>> Not quite. The RE makefiles will put debug info files into a >>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>> .map and .pdb files. For the regular bundles, the RE makefiles >>> will not include debug info files. Not quite the same as >>> stripping them out. >> >> Not trying to split hairs but if the image contains them and the RE >> bundle of the image does not, then the RE process is stripping them out. > > The above is implying that there is a single RE bundle and that hasn't > been true for the tar-style universe for quite a long time; the demo > bundle was added by around JDK8-B20 or so. For the package-style > universe, I don't think that has ever been true. > > RE's makefiles take the image generated by the build and package up the > various files into two or more bundles. I believe each platform has two > styles of bundles. For Solaris, SVR4 style packages and tar/zip bundles. > For Windows, an EXE installer and tar/zip bundles. For Linux RPM packages > and tar/ZIP bundles. > > So I'll stick with my assertion that the RE process is placing debug info > files into a separate bundle and is not stripping them out. > > >> >>>> But the build itself seems to treat them in an ad-hoc manner: >>>> >>>> - The new build deliberately excludes debuginfo/diz files associated >>>> with binaries, but will include any related to libraries (via generic >>>> copying routine). (It's obvious from the comments related to this that >>>> there is some puzzlement as to this reasoning.) >>> >>> Sorry I haven't looked at the new build system. >> >> It tries to emulate the old build. >> >>>> - The old build also tries to exclude the files associated with >>>> binaries, but only handles .debuginfo not .diz :( >>> >>> During one round in the FDS project, I included .debuginfo/.diz files >>> right next to some of the binaries. Apparently that's not allowed >>> without >>> explicit permission. The contents of the "bin" directory are controlled >>> and there are tests to verify those contents. >>> >>> I changed the Makefiles for the few binaries that support FDS to not >>> install the debug info files with the binaries, but they are left in >>> the normal build artifacts location if someone has the need to use >>> them. Of course, I've had queries for debug info files for the binaries >>> to be included in the debuginfo.zip bundles. I'm not planning to fight >>> that battle. >> >> Okay that explains the special handling for binaries. So how do these >> then get into the debuginfo.zip? Or don't they? > > They don't. They are only available via the build artifacts that > are archived. > > >> >>>> Those associated with libraries just seem to get copied if they happen >>>> to be there >>> >>> All of the logic that copies debug info files to the image should do >>> so if they happen to be there. Not all component support FDS now or >>> in the future so the logic needs to adapt to what is built. >>> >>> >>>> As I said this all seems very ad-hoc to me. I would expect to see no >>>> debuginfo/diz files in a created image by default, and have a separate >>>> target that would produce a tar file of all the debuginfo/diz files >>>> ready to overlay on an existing image. >>> >>> Close. The image has to have the debug info or .diz files in order for >>> the RE makefiles to generate the debuginfo.zip files. It is the RE >>> makefiles that handle the packaging. Just like the demos are always >>> built and it is the RE makefiles that put them in a separate bundle. >> >> So therein lies the problem. RE lies outside of the OpenJDK build >> system. If the RE Makefiles can copy an image they can copy the >> debuginfo files too. I'd much rather see no debuginfo files in the >> built images (unless requested) and a distinct debuginfo related >> target (that RE could use if they choose). That would seem to be >> simpler all round. > > My understanding is that "the image" is supposed to be the complete > image if every bundle is extracted. I believe that is how the packages > are sanity checked to be complete. RE's Makefiles are meant to process > "the image" into bundles. They aren't meant to add files of their own. > > If you are planning to change the meaning of "the image" or if you > are planning to put files into bundles that are not in "the image", > then you'll need to coordinate with RE and whoever does the package > inventory testing. > > Also, if you change the way this works, keep in mind that some of the > Makefiles generate their objects into a temporary directory and then > copy things from that temporary directory to the image. Other Makefiles > generate their objects directly into the image. For the latter, you'll > have to move the debug info file(s) out of the image into some other > place where it can be picked up by whatever bundling process you create > to make the debuginfo.zip file. > > >> >>>> Thoughts/comments? >>>> >>>> I have to deal with this for the SE Profile work, where we will not >>>> want these files present in any of the images. >>> >>> It should be fine if the Embedded profile does not generate debug info >>> files or if the Embedded profile generates debug info, but does not >>> copy the debug info files into the image area. The RE makefiles will >>> handle the presence or absence of debug info files. >> >> These are not embedded profiles, these are just profiles - it is all >> to be part of SE in Java 8. The build is supposed to create an image >> corresponding to each profile. I can certainly specialise the handling >> of the debuginfo files for the profiles, but it seemed to me that the >> overall debuginfo-in-image story was rather unclear. > > I'm sorry you think that the debuginfo-in-image story is unclear. > I thought I did a pretty good job integrating FDS into the whole > OpenJDK build process somewhat seamlessly. I guess not. > > The key things to remember in all this is that debug info files > (like the demos) have to end up in a separate bundle or bundles. > So if you change the way this is all implemented, you still have > to follow the separate bundle rule. > > >> >>> However, the non-Embedded profile needs to continue to generate and >>> copy debug info files for those components that already support FDS. >>> If you change the non-Embedded logic to not copy the debug info files >>> into the image area, the RE debuginfo.zip bundle will not be created >>> and that will break FDS. >> >> RE processes will have to change to handle profiles in any case. I >> think they'd rather get a debuginfo.zip out of the build than having >> to create it themselves. > > Interesting and not something that I have ever heard. I got the > impression that RE needed to have control over what was bundled > and how it was bundled. It's kind of hard to certify/vouch for a > process when you don't do it yourself, but that's not really my > call. > > Good luck with the tweaking of the build and packaging processes. > Just remember: There be dragons here! > > Dan > > > >> >> Thanks, >> David >> >>> >>> Dan >>> >>> >>>> >>>> David From henri.gomez at gmail.com Wed Sep 5 12:02:10 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 5 Sep 2012 14:02:10 +0200 Subject: debuginfo/diz files in built images In-Reply-To: <50472D69.1060209@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> <5046074C.8080402@oracle.com> <50472D69.1060209@oracle.com> Message-ID: Interesting point. Should .diz files be removed when packaging JDK/JRE for Linux ? 2012/9/5 David Holmes : > Dan, > > Sorry, not meaning to ruffle your feathers. > > The reason I say the diz-in-image story is unclear is because there are no > explicit rules that indicates that diz files should end up in a JDK or JRE > image. I can accept that everything should go in a full JDK image. But a JRE > is a JDK with a bunch of things left out and some of those things are > libraries. But because diz files are not mentioned explicitly in the rules > for making images we actually get the diz files for the libraries that were > removed! They are simply copied from the build artifacts location to the jre > image location specifically libattach.diz and libsaproc.diz. Maybe that was > a simple oversight. > > Additionally it is unclear to me why we have diz files for some libraries > and not others? > > Anyway as I said this will need to be modified for the profile work, in > consultation with all the interested parties. > > Thanks, > David > > On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: >> >> On 9/2/12 9:37 PM, David Holmes wrote: >>> >>> Hi Dan, >>> >>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>>> >>>> On 9/2/12 7:26 PM, David Holmes wrote: >>>>> >>>>> The build will create debuginfo/diz files as requested - that's fine. >>>>> >>>>> What I'm unclear about is where those files should actually appear in >>>>> our build artifacts, specifically the jdk/jre images that are created. >>>>> >>>>> Internally when we create binary images RE strips all the >>>>> debuginfo/diz files out. >>>> >>>> >>>> Not quite. The RE makefiles will put debug info files into a >>>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>>> .map and .pdb files. For the regular bundles, the RE makefiles >>>> will not include debug info files. Not quite the same as >>>> stripping them out. >>> >>> >>> Not trying to split hairs but if the image contains them and the RE >>> bundle of the image does not, then the RE process is stripping them out. >> >> >> The above is implying that there is a single RE bundle and that hasn't >> been true for the tar-style universe for quite a long time; the demo >> bundle was added by around JDK8-B20 or so. For the package-style >> universe, I don't think that has ever been true. >> >> RE's makefiles take the image generated by the build and package up the >> various files into two or more bundles. I believe each platform has two >> styles of bundles. For Solaris, SVR4 style packages and tar/zip bundles. >> For Windows, an EXE installer and tar/zip bundles. For Linux RPM packages >> and tar/ZIP bundles. >> >> So I'll stick with my assertion that the RE process is placing debug info >> files into a separate bundle and is not stripping them out. >> >> >> >>> >>>>> But the build itself seems to treat them in an ad-hoc manner: >>>>> >>>>> - The new build deliberately excludes debuginfo/diz files associated >>>>> with binaries, but will include any related to libraries (via generic >>>>> copying routine). (It's obvious from the comments related to this that >>>>> there is some puzzlement as to this reasoning.) >>>> >>>> >>>> Sorry I haven't looked at the new build system. >>> >>> >>> It tries to emulate the old build. >>> >>>>> - The old build also tries to exclude the files associated with >>>>> binaries, but only handles .debuginfo not .diz :( >>>> >>>> >>>> During one round in the FDS project, I included .debuginfo/.diz files >>>> right next to some of the binaries. Apparently that's not allowed >>>> without >>>> explicit permission. The contents of the "bin" directory are controlled >>>> and there are tests to verify those contents. >>>> >>>> I changed the Makefiles for the few binaries that support FDS to not >>>> install the debug info files with the binaries, but they are left in >>>> the normal build artifacts location if someone has the need to use >>>> them. Of course, I've had queries for debug info files for the binaries >>>> to be included in the debuginfo.zip bundles. I'm not planning to fight >>>> that battle. >>> >>> >>> Okay that explains the special handling for binaries. So how do these >>> then get into the debuginfo.zip? Or don't they? >> >> >> They don't. They are only available via the build artifacts that >> are archived. >> >> >> >>> >>>>> Those associated with libraries just seem to get copied if they happen >>>>> to be there >>>> >>>> >>>> All of the logic that copies debug info files to the image should do >>>> so if they happen to be there. Not all component support FDS now or >>>> in the future so the logic needs to adapt to what is built. >>>> >>>> >>>>> As I said this all seems very ad-hoc to me. I would expect to see no >>>>> debuginfo/diz files in a created image by default, and have a separate >>>>> target that would produce a tar file of all the debuginfo/diz files >>>>> ready to overlay on an existing image. >>>> >>>> >>>> Close. The image has to have the debug info or .diz files in order for >>>> the RE makefiles to generate the debuginfo.zip files. It is the RE >>>> makefiles that handle the packaging. Just like the demos are always >>>> built and it is the RE makefiles that put them in a separate bundle. >>> >>> >>> So therein lies the problem. RE lies outside of the OpenJDK build >>> system. If the RE Makefiles can copy an image they can copy the >>> debuginfo files too. I'd much rather see no debuginfo files in the >>> built images (unless requested) and a distinct debuginfo related >>> target (that RE could use if they choose). That would seem to be >>> simpler all round. >> >> >> My understanding is that "the image" is supposed to be the complete >> image if every bundle is extracted. I believe that is how the packages >> are sanity checked to be complete. RE's Makefiles are meant to process >> "the image" into bundles. They aren't meant to add files of their own. >> >> If you are planning to change the meaning of "the image" or if you >> are planning to put files into bundles that are not in "the image", >> then you'll need to coordinate with RE and whoever does the package >> inventory testing. >> >> Also, if you change the way this works, keep in mind that some of the >> Makefiles generate their objects into a temporary directory and then >> copy things from that temporary directory to the image. Other Makefiles >> generate their objects directly into the image. For the latter, you'll >> have to move the debug info file(s) out of the image into some other >> place where it can be picked up by whatever bundling process you create >> to make the debuginfo.zip file. >> >> >> >>> >>>>> Thoughts/comments? >>>>> >>>>> I have to deal with this for the SE Profile work, where we will not >>>>> want these files present in any of the images. >>>> >>>> >>>> It should be fine if the Embedded profile does not generate debug info >>>> files or if the Embedded profile generates debug info, but does not >>>> copy the debug info files into the image area. The RE makefiles will >>>> handle the presence or absence of debug info files. >>> >>> >>> These are not embedded profiles, these are just profiles - it is all >>> to be part of SE in Java 8. The build is supposed to create an image >>> corresponding to each profile. I can certainly specialise the handling >>> of the debuginfo files for the profiles, but it seemed to me that the >>> overall debuginfo-in-image story was rather unclear. >> >> >> I'm sorry you think that the debuginfo-in-image story is unclear. >> I thought I did a pretty good job integrating FDS into the whole >> OpenJDK build process somewhat seamlessly. I guess not. >> >> The key things to remember in all this is that debug info files >> (like the demos) have to end up in a separate bundle or bundles. >> So if you change the way this is all implemented, you still have >> to follow the separate bundle rule. >> >> >> >>> >>>> However, the non-Embedded profile needs to continue to generate and >>>> copy debug info files for those components that already support FDS. >>>> If you change the non-Embedded logic to not copy the debug info files >>>> into the image area, the RE debuginfo.zip bundle will not be created >>>> and that will break FDS. >>> >>> >>> RE processes will have to change to handle profiles in any case. I >>> think they'd rather get a debuginfo.zip out of the build than having >>> to create it themselves. >> >> >> Interesting and not something that I have ever heard. I got the >> impression that RE needed to have control over what was bundled >> and how it was bundled. It's kind of hard to certify/vouch for a >> process when you don't do it yourself, but that's not really my >> call. >> >> Good luck with the tweaking of the build and packaging processes. >> Just remember: There be dragons here! >> >> Dan >> >> >> >>> >>> Thanks, >>> David >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> David From aph at redhat.com Wed Sep 5 12:23:33 2012 From: aph at redhat.com (Andrew Haley) Date: Wed, 05 Sep 2012 13:23:33 +0100 Subject: debuginfo/diz files in built images In-Reply-To: References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> <5046074C.8080402@oracle.com> <50472D69.1060209@oracle.com> Message-ID: <50474445.6010904@redhat.com> On 09/05/2012 01:02 PM, Henri Gomez wrote: > Interesting point. > > Should .diz files be removed when packaging JDK/JRE for Linux ? I would have thought that depended on whether this is OpenJDK or proprietary JDK. For OpenJDK, surely the debuginfo should be in all builds. We do want people to be able to debug things, surely. Andrew. From daniel.daugherty at oracle.com Wed Sep 5 14:00:37 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 05 Sep 2012 08:00:37 -0600 Subject: debuginfo/diz files in built images In-Reply-To: <50472D69.1060209@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> <5046074C.8080402@oracle.com> <50472D69.1060209@oracle.com> Message-ID: <50475B05.4010405@oracle.com> On 9/5/12 4:46 AM, David Holmes wrote: > Dan, > > Sorry, not meaning to ruffle your feathers. Not ruffled. Just very tired of FDS. > The reason I say the diz-in-image story is unclear is because there > are no explicit rules that indicates that diz files should end up in a > JDK or JRE image. I can accept that everything should go in a full JDK > image. But a JRE is a JDK with a bunch of things left out and some of > those things are libraries. But because diz files are not mentioned > explicitly in the rules for making images we actually get the diz > files for the libraries that were removed! They are simply copied from > the build artifacts location to the jre image location specifically > libattach.diz and libsaproc.diz. Maybe that was a simple oversight. If the libraries are removed from the image, then that same logic should also remove debug info files or .diz files. Maybe I'm misunderstanding something here. > Additionally it is unclear to me why we have diz files for some > libraries and not others? I implemented complete FDS for Linux and Solaris for hotspot. I implemented FDS for Linux and Solaris for Runtime and Serviceability related libraries in the JDK. I did not implement FDS for any other team's libraries. Of course, Win* has had FDS since JDK1.4.1 so complete FDS is implemented everywhere on Windows. > Anyway as I said this will need to be modified for the profile work, > in consultation with all the interested parties. Please keep me in the loop. Dan > > Thanks, > David > > On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: >> On 9/2/12 9:37 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>>> On 9/2/12 7:26 PM, David Holmes wrote: >>>>> The build will create debuginfo/diz files as requested - that's fine. >>>>> >>>>> What I'm unclear about is where those files should actually appear in >>>>> our build artifacts, specifically the jdk/jre images that are >>>>> created. >>>>> >>>>> Internally when we create binary images RE strips all the >>>>> debuginfo/diz files out. >>>> >>>> Not quite. The RE makefiles will put debug info files into a >>>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>>> .map and .pdb files. For the regular bundles, the RE makefiles >>>> will not include debug info files. Not quite the same as >>>> stripping them out. >>> >>> Not trying to split hairs but if the image contains them and the RE >>> bundle of the image does not, then the RE process is stripping them >>> out. >> >> The above is implying that there is a single RE bundle and that hasn't >> been true for the tar-style universe for quite a long time; the demo >> bundle was added by around JDK8-B20 or so. For the package-style >> universe, I don't think that has ever been true. >> >> RE's makefiles take the image generated by the build and package up the >> various files into two or more bundles. I believe each platform has two >> styles of bundles. For Solaris, SVR4 style packages and tar/zip bundles. >> For Windows, an EXE installer and tar/zip bundles. For Linux RPM >> packages >> and tar/ZIP bundles. >> >> So I'll stick with my assertion that the RE process is placing debug >> info >> files into a separate bundle and is not stripping them out. >> >> >>> >>>>> But the build itself seems to treat them in an ad-hoc manner: >>>>> >>>>> - The new build deliberately excludes debuginfo/diz files associated >>>>> with binaries, but will include any related to libraries (via generic >>>>> copying routine). (It's obvious from the comments related to this >>>>> that >>>>> there is some puzzlement as to this reasoning.) >>>> >>>> Sorry I haven't looked at the new build system. >>> >>> It tries to emulate the old build. >>> >>>>> - The old build also tries to exclude the files associated with >>>>> binaries, but only handles .debuginfo not .diz :( >>>> >>>> During one round in the FDS project, I included .debuginfo/.diz files >>>> right next to some of the binaries. Apparently that's not allowed >>>> without >>>> explicit permission. The contents of the "bin" directory are >>>> controlled >>>> and there are tests to verify those contents. >>>> >>>> I changed the Makefiles for the few binaries that support FDS to not >>>> install the debug info files with the binaries, but they are left in >>>> the normal build artifacts location if someone has the need to use >>>> them. Of course, I've had queries for debug info files for the >>>> binaries >>>> to be included in the debuginfo.zip bundles. I'm not planning to fight >>>> that battle. >>> >>> Okay that explains the special handling for binaries. So how do these >>> then get into the debuginfo.zip? Or don't they? >> >> They don't. They are only available via the build artifacts that >> are archived. >> >> >>> >>>>> Those associated with libraries just seem to get copied if they >>>>> happen >>>>> to be there >>>> >>>> All of the logic that copies debug info files to the image should do >>>> so if they happen to be there. Not all component support FDS now or >>>> in the future so the logic needs to adapt to what is built. >>>> >>>> >>>>> As I said this all seems very ad-hoc to me. I would expect to see no >>>>> debuginfo/diz files in a created image by default, and have a >>>>> separate >>>>> target that would produce a tar file of all the debuginfo/diz files >>>>> ready to overlay on an existing image. >>>> >>>> Close. The image has to have the debug info or .diz files in order for >>>> the RE makefiles to generate the debuginfo.zip files. It is the RE >>>> makefiles that handle the packaging. Just like the demos are always >>>> built and it is the RE makefiles that put them in a separate bundle. >>> >>> So therein lies the problem. RE lies outside of the OpenJDK build >>> system. If the RE Makefiles can copy an image they can copy the >>> debuginfo files too. I'd much rather see no debuginfo files in the >>> built images (unless requested) and a distinct debuginfo related >>> target (that RE could use if they choose). That would seem to be >>> simpler all round. >> >> My understanding is that "the image" is supposed to be the complete >> image if every bundle is extracted. I believe that is how the packages >> are sanity checked to be complete. RE's Makefiles are meant to process >> "the image" into bundles. They aren't meant to add files of their own. >> >> If you are planning to change the meaning of "the image" or if you >> are planning to put files into bundles that are not in "the image", >> then you'll need to coordinate with RE and whoever does the package >> inventory testing. >> >> Also, if you change the way this works, keep in mind that some of the >> Makefiles generate their objects into a temporary directory and then >> copy things from that temporary directory to the image. Other Makefiles >> generate their objects directly into the image. For the latter, you'll >> have to move the debug info file(s) out of the image into some other >> place where it can be picked up by whatever bundling process you create >> to make the debuginfo.zip file. >> >> >>> >>>>> Thoughts/comments? >>>>> >>>>> I have to deal with this for the SE Profile work, where we will not >>>>> want these files present in any of the images. >>>> >>>> It should be fine if the Embedded profile does not generate debug info >>>> files or if the Embedded profile generates debug info, but does not >>>> copy the debug info files into the image area. The RE makefiles will >>>> handle the presence or absence of debug info files. >>> >>> These are not embedded profiles, these are just profiles - it is all >>> to be part of SE in Java 8. The build is supposed to create an image >>> corresponding to each profile. I can certainly specialise the handling >>> of the debuginfo files for the profiles, but it seemed to me that the >>> overall debuginfo-in-image story was rather unclear. >> >> I'm sorry you think that the debuginfo-in-image story is unclear. >> I thought I did a pretty good job integrating FDS into the whole >> OpenJDK build process somewhat seamlessly. I guess not. >> >> The key things to remember in all this is that debug info files >> (like the demos) have to end up in a separate bundle or bundles. >> So if you change the way this is all implemented, you still have >> to follow the separate bundle rule. >> >> >>> >>>> However, the non-Embedded profile needs to continue to generate and >>>> copy debug info files for those components that already support FDS. >>>> If you change the non-Embedded logic to not copy the debug info files >>>> into the image area, the RE debuginfo.zip bundle will not be created >>>> and that will break FDS. >>> >>> RE processes will have to change to handle profiles in any case. I >>> think they'd rather get a debuginfo.zip out of the build than having >>> to create it themselves. >> >> Interesting and not something that I have ever heard. I got the >> impression that RE needed to have control over what was bundled >> and how it was bundled. It's kind of hard to certify/vouch for a >> process when you don't do it yourself, but that's not really my >> call. >> >> Good luck with the tweaking of the build and packaging processes. >> Just remember: There be dragons here! >> >> Dan >> >> >> >>> >>> Thanks, >>> David >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> David From ahughes at redhat.com Wed Sep 5 15:00:50 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 5 Sep 2012 11:00:50 -0400 (EDT) Subject: debuginfo/diz files in built images In-Reply-To: Message-ID: <367958348.1241630.1346857250712.JavaMail.root@redhat.com> ----- Original Message ----- > Interesting point. > > Should .diz files be removed when packaging JDK/JRE for Linux ? > Specifically talking about packaging, distro build systems already handle stripping, etc. themselves so we've been setting STRIP_POLICY=no_strip. However, this still creates the diz files, even though the debuginfo is still in the binaries. I have a couple of changesets to fix this, one for HotSpot & one for JDK, basically making diz production conditional on STRIP_POLICY not being set to no_strip. I'll try and upstream them, if that sounds the correct thing to do. > 2012/9/5 David Holmes : > > Dan, > > > > Sorry, not meaning to ruffle your feathers. > > > > The reason I say the diz-in-image story is unclear is because there > > are no > > explicit rules that indicates that diz files should end up in a JDK > > or JRE > > image. I can accept that everything should go in a full JDK image. > > But a JRE > > is a JDK with a bunch of things left out and some of those things > > are > > libraries. But because diz files are not mentioned explicitly in > > the rules > > for making images we actually get the diz files for the libraries > > that were > > removed! They are simply copied from the build artifacts location > > to the jre > > image location specifically libattach.diz and libsaproc.diz. Maybe > > that was > > a simple oversight. > > > > Additionally it is unclear to me why we have diz files for some > > libraries > > and not others? > > > > Anyway as I said this will need to be modified for the profile > > work, in > > consultation with all the interested parties. > > > > Thanks, > > David > > > > On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: > >> > >> On 9/2/12 9:37 PM, David Holmes wrote: > >>> > >>> Hi Dan, > >>> > >>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: > >>>> > >>>> On 9/2/12 7:26 PM, David Holmes wrote: > >>>>> > >>>>> The build will create debuginfo/diz files as requested - that's > >>>>> fine. > >>>>> > >>>>> What I'm unclear about is where those files should actually > >>>>> appear in > >>>>> our build artifacts, specifically the jdk/jre images that are > >>>>> created. > >>>>> > >>>>> Internally when we create binary images RE strips all the > >>>>> debuginfo/diz files out. > >>>> > >>>> > >>>> Not quite. The RE makefiles will put debug info files into a > >>>> separate debuginfo.zip file. This includes .debuginfo, .diz, > >>>> .map and .pdb files. For the regular bundles, the RE makefiles > >>>> will not include debug info files. Not quite the same as > >>>> stripping them out. > >>> > >>> > >>> Not trying to split hairs but if the image contains them and the > >>> RE > >>> bundle of the image does not, then the RE process is stripping > >>> them out. > >> > >> > >> The above is implying that there is a single RE bundle and that > >> hasn't > >> been true for the tar-style universe for quite a long time; the > >> demo > >> bundle was added by around JDK8-B20 or so. For the package-style > >> universe, I don't think that has ever been true. > >> > >> RE's makefiles take the image generated by the build and package > >> up the > >> various files into two or more bundles. I believe each platform > >> has two > >> styles of bundles. For Solaris, SVR4 style packages and tar/zip > >> bundles. > >> For Windows, an EXE installer and tar/zip bundles. For Linux RPM > >> packages > >> and tar/ZIP bundles. > >> > >> So I'll stick with my assertion that the RE process is placing > >> debug info > >> files into a separate bundle and is not stripping them out. > >> > >> > >> > >>> > >>>>> But the build itself seems to treat them in an ad-hoc manner: > >>>>> > >>>>> - The new build deliberately excludes debuginfo/diz files > >>>>> associated > >>>>> with binaries, but will include any related to libraries (via > >>>>> generic > >>>>> copying routine). (It's obvious from the comments related to > >>>>> this that > >>>>> there is some puzzlement as to this reasoning.) > >>>> > >>>> > >>>> Sorry I haven't looked at the new build system. > >>> > >>> > >>> It tries to emulate the old build. > >>> > >>>>> - The old build also tries to exclude the files associated with > >>>>> binaries, but only handles .debuginfo not .diz :( > >>>> > >>>> > >>>> During one round in the FDS project, I included .debuginfo/.diz > >>>> files > >>>> right next to some of the binaries. Apparently that's not > >>>> allowed > >>>> without > >>>> explicit permission. The contents of the "bin" directory are > >>>> controlled > >>>> and there are tests to verify those contents. > >>>> > >>>> I changed the Makefiles for the few binaries that support FDS to > >>>> not > >>>> install the debug info files with the binaries, but they are > >>>> left in > >>>> the normal build artifacts location if someone has the need to > >>>> use > >>>> them. Of course, I've had queries for debug info files for the > >>>> binaries > >>>> to be included in the debuginfo.zip bundles. I'm not planning to > >>>> fight > >>>> that battle. > >>> > >>> > >>> Okay that explains the special handling for binaries. So how do > >>> these > >>> then get into the debuginfo.zip? Or don't they? > >> > >> > >> They don't. They are only available via the build artifacts that > >> are archived. > >> > >> > >> > >>> > >>>>> Those associated with libraries just seem to get copied if they > >>>>> happen > >>>>> to be there > >>>> > >>>> > >>>> All of the logic that copies debug info files to the image > >>>> should do > >>>> so if they happen to be there. Not all component support FDS now > >>>> or > >>>> in the future so the logic needs to adapt to what is built. > >>>> > >>>> > >>>>> As I said this all seems very ad-hoc to me. I would expect to > >>>>> see no > >>>>> debuginfo/diz files in a created image by default, and have a > >>>>> separate > >>>>> target that would produce a tar file of all the debuginfo/diz > >>>>> files > >>>>> ready to overlay on an existing image. > >>>> > >>>> > >>>> Close. The image has to have the debug info or .diz files in > >>>> order for > >>>> the RE makefiles to generate the debuginfo.zip files. It is the > >>>> RE > >>>> makefiles that handle the packaging. Just like the demos are > >>>> always > >>>> built and it is the RE makefiles that put them in a separate > >>>> bundle. > >>> > >>> > >>> So therein lies the problem. RE lies outside of the OpenJDK build > >>> system. If the RE Makefiles can copy an image they can copy the > >>> debuginfo files too. I'd much rather see no debuginfo files in > >>> the > >>> built images (unless requested) and a distinct debuginfo related > >>> target (that RE could use if they choose). That would seem to be > >>> simpler all round. > >> > >> > >> My understanding is that "the image" is supposed to be the > >> complete > >> image if every bundle is extracted. I believe that is how the > >> packages > >> are sanity checked to be complete. RE's Makefiles are meant to > >> process > >> "the image" into bundles. They aren't meant to add files of their > >> own. > >> > >> If you are planning to change the meaning of "the image" or if you > >> are planning to put files into bundles that are not in "the > >> image", > >> then you'll need to coordinate with RE and whoever does the > >> package > >> inventory testing. > >> > >> Also, if you change the way this works, keep in mind that some of > >> the > >> Makefiles generate their objects into a temporary directory and > >> then > >> copy things from that temporary directory to the image. Other > >> Makefiles > >> generate their objects directly into the image. For the latter, > >> you'll > >> have to move the debug info file(s) out of the image into some > >> other > >> place where it can be picked up by whatever bundling process you > >> create > >> to make the debuginfo.zip file. > >> > >> > >> > >>> > >>>>> Thoughts/comments? > >>>>> > >>>>> I have to deal with this for the SE Profile work, where we will > >>>>> not > >>>>> want these files present in any of the images. > >>>> > >>>> > >>>> It should be fine if the Embedded profile does not generate > >>>> debug info > >>>> files or if the Embedded profile generates debug info, but does > >>>> not > >>>> copy the debug info files into the image area. The RE makefiles > >>>> will > >>>> handle the presence or absence of debug info files. > >>> > >>> > >>> These are not embedded profiles, these are just profiles - it is > >>> all > >>> to be part of SE in Java 8. The build is supposed to create an > >>> image > >>> corresponding to each profile. I can certainly specialise the > >>> handling > >>> of the debuginfo files for the profiles, but it seemed to me that > >>> the > >>> overall debuginfo-in-image story was rather unclear. > >> > >> > >> I'm sorry you think that the debuginfo-in-image story is unclear. > >> I thought I did a pretty good job integrating FDS into the whole > >> OpenJDK build process somewhat seamlessly. I guess not. > >> > >> The key things to remember in all this is that debug info files > >> (like the demos) have to end up in a separate bundle or bundles. > >> So if you change the way this is all implemented, you still have > >> to follow the separate bundle rule. > >> > >> > >> > >>> > >>>> However, the non-Embedded profile needs to continue to generate > >>>> and > >>>> copy debug info files for those components that already support > >>>> FDS. > >>>> If you change the non-Embedded logic to not copy the debug info > >>>> files > >>>> into the image area, the RE debuginfo.zip bundle will not be > >>>> created > >>>> and that will break FDS. > >>> > >>> > >>> RE processes will have to change to handle profiles in any case. > >>> I > >>> think they'd rather get a debuginfo.zip out of the build than > >>> having > >>> to create it themselves. > >> > >> > >> Interesting and not something that I have ever heard. I got the > >> impression that RE needed to have control over what was bundled > >> and how it was bundled. It's kind of hard to certify/vouch for a > >> process when you don't do it yourself, but that's not really my > >> call. > >> > >> Good luck with the tweaking of the build and packaging processes. > >> Just remember: There be dragons here! > >> > >> Dan > >> > >> > >> > >>> > >>> Thanks, > >>> David > >>> > >>>> > >>>> Dan > >>>> > >>>> > >>>>> > >>>>> David > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From John.Coomes at oracle.com Wed Sep 5 19:08:30 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 5 Sep 2012 12:08:30 -0700 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh Message-ID: <20551.41774.838441.899681@oracle.com> Please review this small change to keep the script in sync with the forest structure. webrev: http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ inline diff: diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 @@ -60,3 +60,3 @@ if [ "${pull_extra_base}" != "" ] ; then - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` -John From kelly.ohair at oracle.com Wed Sep 5 19:40:53 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 5 Sep 2012 12:40:53 -0700 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh In-Reply-To: <20551.41774.838441.899681@oracle.com> References: <20551.41774.838441.899681@oracle.com> Message-ID: <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> Looks fine to me. -kto On Sep 5, 2012, at 12:08 PM, John Coomes wrote: > Please review this small change to keep the script in sync with the > forest structure. > > webrev: > > http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ > > inline diff: > > diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh > --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 > +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 > @@ -60,3 +60,3 @@ > if [ "${pull_extra_base}" != "" ] ; then > - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` > > -John From chris.hegarty at oracle.com Wed Sep 5 20:00:34 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Sep 2012 21:00:34 +0100 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh In-Reply-To: <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> References: <20551.41774.838441.899681@oracle.com> <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> Message-ID: <5047AF62.80101@oracle.com> +1 -Chris. On 05/09/2012 20:40, Kelly O'Hair wrote: > Looks fine to me. > > -kto > > On Sep 5, 2012, at 12:08 PM, John Coomes wrote: > >> Please review this small change to keep the script in sync with the >> forest structure. >> >> webrev: >> >> http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ >> >> inline diff: >> >> diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh >> --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 >> +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 >> @@ -60,3 +60,3 @@ >> if [ "${pull_extra_base}" != "" ] ; then >> - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" >> + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" >> pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` >> >> -John > From John.Coomes at oracle.com Wed Sep 5 20:12:49 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 5 Sep 2012 13:12:49 -0700 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh In-Reply-To: <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> References: <20551.41774.838441.899681@oracle.com> <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> Message-ID: <20551.45633.458158.358002@oracle.com> Kelly O'Hair (kelly.ohair at oracle.com) wrote: > Looks fine to me. Thanks Kelly. -John > On Sep 5, 2012, at 12:08 PM, John Coomes wrote: > > > Please review this small change to keep the script in sync with the > > forest structure. > > > > webrev: > > > > http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ > > > > inline diff: > > > > diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh > > --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 > > +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 > > @@ -60,3 +60,3 @@ > > if [ "${pull_extra_base}" != "" ] ; then > > - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > > + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > > pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` > > > > -John > From John.Coomes at oracle.com Wed Sep 5 20:13:01 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 5 Sep 2012 13:13:01 -0700 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh In-Reply-To: <5047AF62.80101@oracle.com> References: <20551.41774.838441.899681@oracle.com> <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> <5047AF62.80101@oracle.com> Message-ID: <20551.45645.417921.775829@oracle.com> Chris Hegarty (chris.hegarty at oracle.com) wrote: > +1 Thanks Chris. Apologies for not including you in the cset comment; I committed the cset and started the push before getting your message. -John > On 05/09/2012 20:40, Kelly O'Hair wrote: > > Looks fine to me. > > > > -kto > > > > On Sep 5, 2012, at 12:08 PM, John Coomes wrote: > > > >> Please review this small change to keep the script in sync with the > >> forest structure. > >> > >> webrev: > >> > >> http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ > >> > >> inline diff: > >> > >> diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh > >> --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 > >> +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 > >> @@ -60,3 +60,3 @@ > >> if [ "${pull_extra_base}" != "" ] ; then > >> - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > >> + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" > >> pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` > >> > >> -John > > From chris.hegarty at oracle.com Wed Sep 5 20:15:10 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Sep 2012 21:15:10 +0100 Subject: review request - 7196361 add hotspot/make/closed to hgforest.sh In-Reply-To: <20551.45645.417921.775829@oracle.com> References: <20551.41774.838441.899681@oracle.com> <3676D79F-33C6-4748-9A47-82041EED863C@oracle.com> <5047AF62.80101@oracle.com> <20551.45645.417921.775829@oracle.com> Message-ID: <5047B2CE.6000000@oracle.com> On 05/09/2012 21:13, John Coomes wrote: > Chris Hegarty (chris.hegarty at oracle.com) wrote: >> +1 > > Thanks Chris. Apologies for not including you in the cset comment; I > committed the cset and started the push before getting your message. No problem. More eyes always help ;-) -Chris. > > -John > >> On 05/09/2012 20:40, Kelly O'Hair wrote: >>> Looks fine to me. >>> >>> -kto >>> >>> On Sep 5, 2012, at 12:08 PM, John Coomes wrote: >>> >>>> Please review this small change to keep the script in sync with the >>>> forest structure. >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/ >>>> >>>> inline diff: >>>> >>>> diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh >>>> --- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700 >>>> +++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700 >>>> @@ -60,3 +60,3 @@ >>>> if [ "${pull_extra_base}" != "" ] ; then >>>> - subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" >>>> + subrepos_extra="jdk/src/closed jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install sponsors pubs" >>>> pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` >>>> >>>> -John >>> From michael.fang at oracle.com Wed Sep 5 21:08:54 2012 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 05 Sep 2012 14:08:54 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: <50338B45.4050906@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> <5032706A.8060007@oracle.com> <50338B45.4050906@oracle.com> Message-ID: <5047BF66.7080704@oracle.com> Hello, Please help to review the new JDK8 file for the following CR: 7196354 check-in jdk.tbom file to openjdk repo The webrev is located at: http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ Build-dev: The file will be pushed to the top level openjdk repository http://hg.openjdk.java.net/jdk8/build. This file is to be used as translation bill of material file for automated translation drop system to zip up the list of English resource files to be delivered to translation team. Mark: Since the dev team will need to maintain this file in the future (modifying it if you add or delete resource files), I temporarily put down your name as contact for the file. Please figure out the proper owner and we can update it again. Core-libs-dev: I believe most of the resource files are used for your product area. Please take a look and let me know if you have any concerns, or know of any files to be added or deleted at this time. In the future, if any bug/rfe requires adding/deleting resource files, the dev work should include updating this file to reflect the correct resource file list. (and please ask me to review it). I18n-dev: Also included the group mailing list since this is part of l10n team's deliverable. thanks, -michael From david.katleman at oracle.com Wed Sep 5 21:49:07 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:49:07 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20120905214907.C210547907@hg.openjdk.java.net> Changeset: d5e73011bde2 Author: katleman Date: 2012-08-30 10:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/d5e73011bde2 Added tag jdk8-b54 for changeset c1a277c6022a ! .hgtags Changeset: b85b44cced24 Author: jcoomes Date: 2012-09-05 12:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/b85b44cced24 7196361: add hotspot/make/closed to hgforest.sh Reviewed-by: ohair ! make/scripts/hgforest.sh From david.katleman at oracle.com Wed Sep 5 21:49:12 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:49:12 +0000 Subject: hg: jdk8/build/corba: 4 new changesets Message-ID: <20120905214915.3AFFC47908@hg.openjdk.java.net> Changeset: 6b2a363213f4 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/6b2a363213f4 Added tag jdk8-b54 for changeset 16c82fc74695 ! .hgtags Changeset: 18a02ad8dc73 Author: coffeys Date: 2012-08-16 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/18a02ad8dc73 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java Changeset: d086e67eb9dd Author: lana Date: 2012-08-27 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/d086e67eb9dd Merge Changeset: e8a0e84383d6 Author: lana Date: 2012-08-30 20:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/e8a0e84383d6 Merge From david.katleman at oracle.com Wed Sep 5 21:51:31 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:51:31 +0000 Subject: hg: jdk8/build/hotspot: 22 new changesets Message-ID: <20120905215223.4848147909@hg.openjdk.java.net> Changeset: 3b77f0c58018 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3b77f0c58018 Added tag jdk8-b54 for changeset e8fb566b9466 ! .hgtags Changeset: 153776c4cb6f Author: amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: be82ef218872 Author: sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script Changeset: b3602ff9c1b8 Author: dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b3602ff9c1b8 Merge Changeset: bb3f6194fedb Author: brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vitalyd at gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author: johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fa9253dcd4df Author: johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author: brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/220b59f8413f Merge Changeset: a1c7f6472621 Author: kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: a5dd6e3ef9f3 Author: twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 7f813940ac35 Author: twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 83b6305a5638 Author: coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.punegov at oracle.com ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 0acd345fd810 Author: kvn Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0acd345fd810 7160161: Missed safepoint in non-Counted loop Summary: Do not remove safepoints during peeling optimization. Reviewed-by: twisti ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 4d318b1e73ca Author: twisti Date: 2012-08-31 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4d318b1e73ca Merge Changeset: 0771839a29ab Author: jprovino Date: 2012-08-08 15:43 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0771839a29ab 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make Changeset: 892ec0920ccd Author: vladidan Date: 2012-08-08 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/892ec0920ccd Merge Changeset: e2cc1fe53845 Author: amurillo Date: 2012-08-17 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e2cc1fe53845 Merge Changeset: a9fed06c01d2 Author: bpittore Date: 2012-08-30 11:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a9fed06c01d2 7154641: Servicability agent should work on platforms other than x86, sparc Summary: Added capability to load support classes for other cpus Reviewed-by: coleenp, bobv, sla Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/defs.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: 6dcb17434873 Author: jiangli Date: 2012-08-31 14:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6dcb17434873 Merge Changeset: 1eb74cd5994b Author: jiangli Date: 2012-08-31 12:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1eb74cd5994b Merge Changeset: 09ea7e0752b3 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/09ea7e0752b3 Merge Changeset: af0c8a080851 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/af0c8a080851 Added tag hs24-b22 for changeset 09ea7e0752b3 ! .hgtags From david.katleman at oracle.com Wed Sep 5 21:53:43 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:53:43 +0000 Subject: hg: jdk8/build/jaxp: 4 new changesets Message-ID: <20120905215355.B13AA4790A@hg.openjdk.java.net> Changeset: 0cb5f2471628 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/0cb5f2471628 Added tag jdk8-b54 for changeset 7dd81ccb7c11 ! .hgtags Changeset: 2946807a6d7f Author: joehw Date: 2012-08-17 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/2946807a6d7f 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Summary: similar to the patch for 6756677 for XMLInputFactory and XMLOutputFactory, this patch fixes an error in XMLEventFactory where factoryId was taken as factory class. Reviewed-by: lancea ! src/javax/xml/stream/XMLEventFactory.java Changeset: 933d0234670f Author: lana Date: 2012-08-27 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/933d0234670f Merge Changeset: 7c2363666890 Author: lana Date: 2012-08-30 20:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/7c2363666890 Merge From david.katleman at oracle.com Wed Sep 5 21:54:01 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:54:01 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b54 for changeset 91970935926a Message-ID: <20120905215405.7925B4790B@hg.openjdk.java.net> Changeset: 109c9e1f2d85 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/109c9e1f2d85 Added tag jdk8-b54 for changeset 91970935926a ! .hgtags From david.katleman at oracle.com Wed Sep 5 21:56:23 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 21:56:23 +0000 Subject: hg: jdk8/build/jdk: 82 new changesets Message-ID: <20120905221125.E2D814790D@hg.openjdk.java.net> Changeset: 906acc4f3c78 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/906acc4f3c78 Added tag jdk8-b54 for changeset 70ad0ed1d6ce ! .hgtags Changeset: ecc1c8085ec7 Author: bae Date: 2012-08-17 11:22 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ecc1c8085ec7 7150594: VM chash in JCK api/java_awt/Image/ConvolveOp/ tests for 64 bit jdk8 on linux. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/medialib/mlib_sys.c Changeset: 61076e7e3c04 Author: lana Date: 2012-08-27 11:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/61076e7e3c04 Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: b41845694f39 Author: serb Date: 2012-08-13 17:43 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b41845694f39 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Reviewed-by: art, anthony Contributed-by: Marco Dinacci ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m Changeset: adbef77870e1 Author: leonidr Date: 2012-08-13 17:53 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/adbef77870e1 7159381: [macosx] Dock Icon defaults to Generic Java Application Category Reviewed-by: anthony ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m Changeset: f63010f4655d Author: kizune Date: 2012-08-13 19:19 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f63010f4655d Merge Changeset: 0025dab4c283 Author: kizune Date: 2012-08-13 19:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0025dab4c283 7177144: [macosx] Drag and drop not working (regression in 7u6) Reviewed-by: art, serb ! src/share/classes/java/awt/EventQueue.java Changeset: f003387c33ad Author: omajid Date: 2012-08-14 17:11 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f003387c33ad 7190813: (launcher) RPATH needs to have additional paths Reviewed-by: anthony, ksrini ! make/common/Program.gmk ! make/sun/jawt/Makefile + test/tools/launcher/RunpathTest.java Changeset: 164919db548b Author: rupashka Date: 2012-08-15 14:33 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/164919db548b 7190543: Nimbus LaF: regression: JSplitPane is not opaque -- or should it? Reviewed-by: alexsch + test/javax/swing/JSplitPane/4201995/bug4201995.java Changeset: 65d874d16d59 Author: serb Date: 2012-08-15 15:02 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/65d874d16d59 7172187: [macosx] JAWT native CALayer not positioned over Canvas Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/PlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m Changeset: 8d570757fe95 Author: rupashka Date: 2012-08-17 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8d570757fe95 7190597: Nimbus: regtest for 4235420 fails Reviewed-by: alexsch + test/javax/swing/JTable/4235420/bug4235420.java Changeset: 2fe9c1f0b16b Author: dingxmin Date: 2012-08-20 13:16 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2fe9c1f0b16b 7188612: JTable's AccessibleJTable throws IllegalComponentStateException instead of null Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java Changeset: fbf21a561c45 Author: malenkov Date: 2012-08-20 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fbf21a561c45 7189112: java.beans.Introspector misses write methods Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7189112.java Changeset: 8a2bc6e82d81 Author: rupashka Date: 2012-08-21 14:37 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a2bc6e82d81 6866747: J2SE_Swing_Reg:can not see any HSB tab Reviewed-by: alexsch - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java Changeset: d769dbb87c49 Author: zhouyx Date: 2012-08-24 11:35 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d769dbb87c49 7193169: The code example in javadoc of Component.java misses 'implements' keyword Reviewed-by: anthony ! src/share/classes/java/awt/Component.java Changeset: e3122759abe3 Author: anthony Date: 2012-08-24 14:58 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e3122759abe3 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) Summary: Constrain window dimensions with screen bounds and GL_MAX_TEXTURE_SIZE Reviewed-by: art, serb ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m + src/share/classes/sun/awt/TextureSizeConstraining.java + test/java/awt/Frame/HugeFrame/HugeFrame.java Changeset: eaec23aae76a Author: lana Date: 2012-08-27 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/eaec23aae76a Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: f54660c18774 Author: serb Date: 2012-08-28 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f54660c18774 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Reviewed-by: leonidr ! src/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java Changeset: 5378c339ed47 Author: lana Date: 2012-08-28 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5378c339ed47 Merge - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java Changeset: 717ed00b7787 Author: sherman Date: 2012-08-09 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/717ed00b7787 7189363: Regex Pattern compilation buggy for special sequences Summary: fixed the incorrect implementation in expr(...) Reviewed-by: psandoz, alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 57b5025548d6 Author: mullan Date: 2012-08-10 09:12 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/57b5025548d6 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null Reviewed-by: valeriep ! src/share/classes/sun/security/provider/certpath/BasicChecker.java Changeset: 629f357fc17b Author: mullan Date: 2012-08-10 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/629f357fc17b Merge Changeset: 114fbbeb8f75 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/114fbbeb8f75 7107613: scalability bloker in javax.crypto.CryptoPermissions Summary: Changed the type of field "perms" from Hashtable to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/CryptoPermissions.java Changeset: 175036ada2e3 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/175036ada2e3 7107616: scalability bloker in javax.crypto.JceSecurityManager Summary: Changed the type of field "exemptCache" from HashMap to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/JceSecurityManager.java Changeset: 9e97dacbfd35 Author: valeriep Date: 2012-08-10 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9e97dacbfd35 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Summary: Saved the last cipher key value and skip key expansion if key value is the same. Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/crypto/provider/AESCrypt.java Changeset: 449c17c7a63a Author: lana Date: 2012-08-10 12:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/449c17c7a63a Merge Changeset: e8b14276d434 Author: lana Date: 2012-08-10 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8b14276d434 Merge Changeset: e7d125f2575b Author: chegar Date: 2012-08-12 22:56 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e7d125f2575b 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Reviewed-by: chegar Contributed-by: Christian Schulte ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/ProxySelector/MultiThreadedSystemProxies.java Changeset: bf0c6f91bc22 Author: luchsh Date: 2012-08-13 19:51 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bf0c6f91bc22 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown Reviewed-by: alanb ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java Changeset: 399c2adf3ad6 Author: chegar Date: 2012-08-13 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/399c2adf3ad6 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Reviewed-by: chegar Contributed-by: Shirish Kuncolienkar ! src/solaris/native/java/net/NetworkInterface.c Changeset: 5e5bdfd18325 Author: vinnie Date: 2012-08-13 14:06 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e5bdfd18325 7190945: pkcs11 problem loading NSS libs on Ubuntu Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/pkcs11/Secmod.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/keystore.jks Changeset: f0bf7358ba23 Author: jfranck Date: 2012-08-09 17:49 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f0bf7358ba23 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerAnnotation.java Changeset: 35e024c6a62c Author: andrew Date: 2012-08-15 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/35e024c6a62c 7110151: Use underlying platform's zlib library for Java zlib support Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and building on more than just MACOSX. Reviewed-by: sherman, alanb ! make/com/sun/java/pack/Makefile ! make/common/Program.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/java/jli/Makefile ! make/java/zip/Makefile ! make/jdk_generic_profile.sh ! make/sun/splashscreen/Makefile ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zip_util.c Changeset: da14e2c90bcb Author: robm Date: 2012-08-15 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/da14e2c90bcb 6931128: (spec) File attribute tests fail when run as root. Reviewed-by: alanb ! src/share/classes/java/io/File.java ! test/java/io/File/Basic.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/File/SymLinks.java + test/java/io/File/Util.java Changeset: 39b01268b845 Author: coffeys Date: 2012-08-16 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/39b01268b845 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! test/Makefile + test/com/sun/corba/cachedSocket/7056731.sh + test/com/sun/corba/cachedSocket/Hello.idl + test/com/sun/corba/cachedSocket/HelloClient.java + test/com/sun/corba/cachedSocket/HelloServer.java Changeset: 56d8756749bd Author: coffeys Date: 2012-08-16 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/56d8756749bd 7185965: Build error in javadoc make stage for bundles not containing crypto package Reviewed-by: chegar ! make/common/shared/Defs-java.gmk Changeset: e48a9a1c14e3 Author: alanb Date: 2012-08-16 11:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e48a9a1c14e3 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Reviewed-by: andrew ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 4fb8792725d5 Author: alanb Date: 2012-08-16 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4fb8792725d5 7191892: ProblemList.txt updates (8/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: e50a39d011b5 Author: alanb Date: 2012-08-16 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e50a39d011b5 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/registry/readTest/readTest.sh Changeset: 4993f8aa7f2e Author: dingxmin Date: 2012-08-17 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4993f8aa7f2e 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c Changeset: 6b2ebf3c4964 Author: mullan Date: 2012-08-17 14:32 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6b2ebf3c4964 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/x509/URIName.java + test/sun/security/x509/URIName/Parse.java Changeset: 509421263cdd Author: dcubed Date: 2012-08-17 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/509421263cdd 7191322: add test for 7064927 to java.lang.instrument Summary: Add support for canRetransform attribute to the test manager. Add test for 7064927. Reviewed-by: dsamersoff, sspitsyn, ohair ! test/java/lang/instrument/ATransformerManagementTestCase.java + test/java/lang/instrument/DummyClassWithLVT.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh + test/java/lang/instrument/retransformAgent.mf Changeset: 16f2865aac24 Author: ksrini Date: 2012-08-17 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/16f2865aac24 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java Changeset: a2359f0f9533 Author: alanb Date: 2012-08-19 13:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a2359f0f9533 7192275: Minimize LogManager dependencies on java.beans Summary: Reduce dependency to PropertyChangeListener and PropertyChangeEvent. Also add basic test coverage. Reviewed-by: dcubed, dsamersoff, mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Listeners.java + test/java/util/logging/ListenersWithSM.java + test/java/util/logging/java.policy Changeset: 5e7cfe034df4 Author: alanb Date: 2012-08-19 13:29 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e7cfe034df4 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! test/java/nio/file/WatchService/MayFlies.java Changeset: 86c963b1dbf8 Author: weijun Date: 2012-08-20 07:59 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/86c963b1dbf8 7192202: Make sure keytool prints both unknown and unparseable extensions Reviewed-by: mullan + test/sun/security/tools/keytool/UnknownAndUnparseable.java Changeset: 59aa7660ade4 Author: robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessBuilder/Basic.java Changeset: 6d29c2af040f Author: alanb Date: 2012-08-21 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6d29c2af040f 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Reviewed-by: alanb Contributed-by: Shirish Kuncolienkar ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java + test/java/nio/channels/SelectionKey/RacyRegister.java Changeset: 131a683a2ce0 Author: naoto Date: 2012-08-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/131a683a2ce0 6336885: RFE: Locale Data Deployment Enhancements 4609153: Provide locale data for Indic locales 5104387: Support for gl_ES locale (galician language) 6337471: desktop/system locale preferences support 7056139: (cal) SPI support for locale-dependent Calendar parameters 7058206: Provide CalendarData SPI for week params and display field value names 7073852: Support multiple scripts for digits and decimal symbols per locale 7079560: [Fmt-Da] Context dependent month names support in SimpleDateFormat 7171324: getAvailableLocales() of locale sensitive services should return the actual availability of locales 7151414: (cal) Support calendar type identification 7168528: LocaleServiceProvider needs to be aware of Locale extensions 7171372: (cal) locale's default Calendar should be created if unknown calendar is specified Summary: JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (part 1 w/o packaging changes. by Naoto Sato and Masayoshi Okutsu) Reviewed-by: erikj, sherman, peytoia ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/java/mapfile-vers ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/java/util/Makefile ! make/sun/Makefile + make/sun/cldr/Makefile ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! make/sun/text/Makefile ! make/tools/Makefile + make/tools/cldrconverter/Makefile + make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java + make/tools/src/build/tools/cldrconverter/Bundle.java + make/tools/src/build/tools/cldrconverter/BundleGenerator.java + make/tools/src/build/tools/cldrconverter/CLDRConverter.java + make/tools/src/build/tools/cldrconverter/CalendarType.java + make/tools/src/build/tools/cldrconverter/Container.java + make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java + make/tools/src/build/tools/cldrconverter/Entry.java + make/tools/src/build/tools/cldrconverter/IgnoredContainer.java + make/tools/src/build/tools/cldrconverter/KeyContainer.java + make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java + make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java + make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java + make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java + make/tools/src/build/tools/cldrconverter/StringArrayElement.java + make/tools/src/build/tools/cldrconverter/StringArrayEntry.java + make/tools/src/build/tools/cldrconverter/StringEntry.java + make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java + make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcCLDR.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcProperties.gmk ! makefiles/Tools.gmk + src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c - src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java - src/share/classes/java/text/CollationRules.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/NumberFormat.java - src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java + src/share/classes/java/util/spi/CalendarDataProvider.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/javax/swing/JSpinner.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java ! src/share/classes/sun/text/resources/FormatData.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java + src/share/classes/sun/text/resources/ar/CollationData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java + src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java + src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/be/CollationData_be.java + src/share/classes/sun/text/resources/be/FormatData_be.java + src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/bg/CollationData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/ca/CollationData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/cs/CollationData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/da/CollationData_da.java + src/share/classes/sun/text/resources/da/FormatData_da.java + src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/de/FormatData_de.java + src/share/classes/sun/text/resources/de/FormatData_de_AT.java + src/share/classes/sun/text/resources/de/FormatData_de_CH.java + src/share/classes/sun/text/resources/de/FormatData_de_DE.java + src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/el/CollationData_el.java + src/share/classes/sun/text/resources/el/FormatData_el.java + src/share/classes/sun/text/resources/el/FormatData_el_CY.java + src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/en/FormatData_en.java + src/share/classes/sun/text/resources/en/FormatData_en_AU.java + src/share/classes/sun/text/resources/en/FormatData_en_CA.java + src/share/classes/sun/text/resources/en/FormatData_en_GB.java + src/share/classes/sun/text/resources/en/FormatData_en_IE.java + src/share/classes/sun/text/resources/en/FormatData_en_IN.java + src/share/classes/sun/text/resources/en/FormatData_en_MT.java + src/share/classes/sun/text/resources/en/FormatData_en_NZ.java + src/share/classes/sun/text/resources/en/FormatData_en_PH.java + src/share/classes/sun/text/resources/en/FormatData_en_SG.java + src/share/classes/sun/text/resources/en/FormatData_en_US.java + src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/es/CollationData_es.java + src/share/classes/sun/text/resources/es/FormatData_es.java + src/share/classes/sun/text/resources/es/FormatData_es_AR.java + src/share/classes/sun/text/resources/es/FormatData_es_BO.java + src/share/classes/sun/text/resources/es/FormatData_es_CL.java + src/share/classes/sun/text/resources/es/FormatData_es_CO.java + src/share/classes/sun/text/resources/es/FormatData_es_CR.java + src/share/classes/sun/text/resources/es/FormatData_es_DO.java + src/share/classes/sun/text/resources/es/FormatData_es_EC.java + src/share/classes/sun/text/resources/es/FormatData_es_ES.java + src/share/classes/sun/text/resources/es/FormatData_es_GT.java + src/share/classes/sun/text/resources/es/FormatData_es_HN.java + src/share/classes/sun/text/resources/es/FormatData_es_MX.java + src/share/classes/sun/text/resources/es/FormatData_es_NI.java + src/share/classes/sun/text/resources/es/FormatData_es_PA.java + src/share/classes/sun/text/resources/es/FormatData_es_PE.java + src/share/classes/sun/text/resources/es/FormatData_es_PR.java + src/share/classes/sun/text/resources/es/FormatData_es_PY.java + src/share/classes/sun/text/resources/es/FormatData_es_SV.java + src/share/classes/sun/text/resources/es/FormatData_es_US.java + src/share/classes/sun/text/resources/es/FormatData_es_UY.java + src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/et/CollationData_et.java + src/share/classes/sun/text/resources/et/FormatData_et.java + src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/fi/CollationData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fr/CollationData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java + src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/ga/FormatData_ga.java + src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/hi/CollationData_hi.java + src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hr/CollationData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hu/CollationData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/in/FormatData_in.java + src/share/classes/sun/text/resources/in/FormatData_in_ID.java + src/share/classes/sun/text/resources/is/CollationData_is.java + src/share/classes/sun/text/resources/is/FormatData_is.java + src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/it/FormatData_it.java + src/share/classes/sun/text/resources/it/FormatData_it_CH.java + src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/iw/CollationData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/ja/CollationData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ko/CollationData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/lt/CollationData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lv/CollationData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/mk/CollationData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/ms/FormatData_ms.java + src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/mt/FormatData_mt.java + src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/nl/FormatData_nl.java + src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java + src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/no/CollationData_no.java + src/share/classes/sun/text/resources/no/FormatData_no.java + src/share/classes/sun/text/resources/no/FormatData_no_NO.java + src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/pl/CollationData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pt/FormatData_pt.java + src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java + src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/ro/CollationData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ru/CollationData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/sk/CollationData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sl/CollationData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sq/CollationData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sr/CollationData_sr.java + src/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr.java + src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java + src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sv/CollationData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java + src/share/classes/sun/text/resources/th/BreakIteratorRules_th.java + src/share/classes/sun/text/resources/th/CollationData_th.java + src/share/classes/sun/text/resources/th/FormatData_th.java + src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/thai_dict - src/share/classes/sun/text/resources/thai_dict + src/share/classes/sun/text/resources/tr/CollationData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/uk/CollationData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/vi/CollationData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/zh/CollationData_zh.java + src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java + src/share/classes/sun/text/resources/zh/CollationData_zh_TW.java + src/share/classes/sun/text/resources/zh/FormatData_zh.java + src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java + src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java + src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java + src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/BuddhistCalendar.java - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java + src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java + src/share/classes/sun/util/cldr/resources/21_0_1/LICENSE + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldml.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldmlSupplemental.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_001.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_AE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_BH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_EG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_IQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_JO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_KW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_OM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_QA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_TN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_YE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be_BY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem_ZM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg_BG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_BD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs_CZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da_DK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_AT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz_BT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_CY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_GR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_JM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_TT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_UM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US_POSIX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_VI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_419.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_AR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_BO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_DO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_EC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_HN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_MX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_NI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_SV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_UY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_VE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et_EE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_IR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo_FO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_KM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_YT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he_IL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr_HR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu_HU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy_AM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ia.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id_ID.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is_IS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja_JP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka_GE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea_CV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl_KZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl_GL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km_KH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko_KR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo_LA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt_LT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv_LV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk_MK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_BN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_MY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my_MM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_NP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_AW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_CW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_NL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_SX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl_PL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_AO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_BR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_GW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_PT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_ST.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_RO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk_SK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl_SI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_SO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq_AL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_SZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_LS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_SE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl_TJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th_TH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to_TO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr_TR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi_VN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_TW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/metaZones.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/numberingSystems.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/supplementalData.xml ! src/share/classes/sun/util/locale/LocaleUtils.java + src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/AvailableLanguageTags.java + src/share/classes/sun/util/locale/provider/BreakDictionary.java + src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CollationRules.java + src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java + src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DecimalFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/HostLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/JRELocaleConstants.java + src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template + src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java + src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + src/share/classes/sun/util/locale/provider/NumberFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java + src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleData.java - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/resources/OpenListResourceBundle.java - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java + src/share/classes/sun/util/resources/ar/CalendarData_ar.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties + src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties + src/share/classes/sun/util/resources/be/CalendarData_be.properties + src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties + src/share/classes/sun/util/resources/be/LocaleNames_be.properties + src/share/classes/sun/util/resources/bg/CalendarData_bg.properties + src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties + src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties + src/share/classes/sun/util/resources/ca/CalendarData_ca.properties + src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties + src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties + src/share/classes/sun/util/resources/cs/CalendarData_cs.properties + src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties + src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties + src/share/classes/sun/util/resources/da/CalendarData_da.properties + src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties + src/share/classes/sun/util/resources/da/LocaleNames_da.properties + src/share/classes/sun/util/resources/de/CalendarData_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties + src/share/classes/sun/util/resources/de/LocaleNames_de.properties + src/share/classes/sun/util/resources/de/TimeZoneNames_de.java + src/share/classes/sun/util/resources/el/CalendarData_el.properties + src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties + src/share/classes/sun/util/resources/el/LocaleNames_el.properties + src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties + src/share/classes/sun/util/resources/en/CalendarData_en.properties + src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties + src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties + src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties + src/share/classes/sun/util/resources/en/LocaleNames_en.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties + src/share/classes/sun/util/resources/en/TimeZoneNames_en.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_CA.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_GB.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_IE.java + src/share/classes/sun/util/resources/es/CalendarData_es.properties + src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties + src/share/classes/sun/util/resources/es/CalendarData_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PE.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties + src/share/classes/sun/util/resources/es/LocaleNames_es.properties + src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties + src/share/classes/sun/util/resources/es/TimeZoneNames_es.java + src/share/classes/sun/util/resources/et/CalendarData_et.properties + src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties + src/share/classes/sun/util/resources/et/LocaleNames_et.properties + src/share/classes/sun/util/resources/fi/CalendarData_fi.properties + src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties + src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties + src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties + src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java + src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties + src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties + src/share/classes/sun/util/resources/hi/CalendarData_hi.properties + src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties + src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties + src/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java + src/share/classes/sun/util/resources/hr/CalendarData_hr.properties + src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties + src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties + src/share/classes/sun/util/resources/hu/CalendarData_hu.properties + src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties + src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties + src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties + src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties + src/share/classes/sun/util/resources/in/LocaleNames_in.properties + src/share/classes/sun/util/resources/is/CalendarData_is.properties + src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties + src/share/classes/sun/util/resources/is/LocaleNames_is.properties + src/share/classes/sun/util/resources/it/CalendarData_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties + src/share/classes/sun/util/resources/it/LocaleNames_it.properties + src/share/classes/sun/util/resources/it/TimeZoneNames_it.java + src/share/classes/sun/util/resources/iw/CalendarData_iw.properties + src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties + src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties + src/share/classes/sun/util/resources/ja/CalendarData_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties + src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties + src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java + src/share/classes/sun/util/resources/ko/CalendarData_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties + src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties + src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java + src/share/classes/sun/util/resources/lt/CalendarData_lt.properties + src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties + src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties + src/share/classes/sun/util/resources/lv/CalendarData_lv.properties + src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties + src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties + src/share/classes/sun/util/resources/mk/CalendarData_mk.properties + src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties + src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties + src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties + src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties + src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties + src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties + src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties + src/share/classes/sun/util/resources/nl/CalendarData_nl.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties + src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties + src/share/classes/sun/util/resources/no/CalendarData_no.properties + src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties + src/share/classes/sun/util/resources/no/LocaleNames_no.properties + src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties + src/share/classes/sun/util/resources/pl/CalendarData_pl.properties + src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties + src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java + src/share/classes/sun/util/resources/ro/CalendarData_ro.properties + src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties + src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties + src/share/classes/sun/util/resources/ru/CalendarData_ru.properties + src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties + src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties + src/share/classes/sun/util/resources/sk/CalendarData_sk.properties + src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties + src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties + src/share/classes/sun/util/resources/sl/CalendarData_sl.properties + src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties + src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties + src/share/classes/sun/util/resources/sq/CalendarData_sq.properties + src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties + src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties + src/share/classes/sun/util/resources/sv/CalendarData_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties + src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties + src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java + src/share/classes/sun/util/resources/th/CalendarData_th.properties + src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties + src/share/classes/sun/util/resources/th/LocaleNames_th.properties + src/share/classes/sun/util/resources/tr/CalendarData_tr.properties + src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties + src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties + src/share/classes/sun/util/resources/uk/CalendarData_uk.properties + src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties + src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties + src/share/classes/sun/util/resources/vi/CalendarData_vi.properties + src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties + src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties + src/share/classes/sun/util/resources/zh/CalendarData_zh.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java + src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java + src/solaris/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/solaris/native/java/lang/java_props_macosx.c + src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + test/java/text/Format/DateFormat/ContextMonthNamesTest.java + test/java/text/Format/NumberFormat/MultipleNumberScriptTest.java + test/java/util/Calendar/CalendarTypeTest.java ! test/java/util/Locale/Bug6989440.java + test/java/util/Locale/ExtensionsTest.java ! test/java/util/Locale/LocaleCategory.sh + test/java/util/Locale/LocaleProviders.java + test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/ProviderTest.java + test/java/util/PluggableLocale/SupportedLocalesTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e7b53fe85540 Author: dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java ! src/windows/classes/java/lang/Terminator.java Changeset: de5a85353f4d Author: alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Greene ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java Changeset: faf4528aea4e Author: naoto Date: 2012-08-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/faf4528aea4e 7193601: Build breakage with the fix to 6336885 (build-infra build) Reviewed-by: mduigou ! makefiles/CompileJavaClasses.gmk Changeset: a7cdfd16e36e Author: alanb Date: 2012-08-24 19:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a7cdfd16e36e 7193933: More ProblemList.txt updates (8/2012) Reviewed-by: darcy, chegar ! test/ProblemList.txt Changeset: bd91a601265c Author: khazra Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bd91a601265c 7168172: (fs) Files.isReadable slow on Windows Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java Changeset: d52081a08d11 Author: mchung Date: 2012-08-24 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d52081a08d11 7193339: Prepare system classes be defined by a non-null module loader Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 61ddc8ce7f3b Author: weijun Date: 2012-08-27 10:23 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/61ddc8ce7f3b 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/auto/FileKeyTab.java Changeset: 96990c9da294 Author: lana Date: 2012-08-27 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/96990c9da294 Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: fe496675b5e7 Author: weijun Date: 2012-08-28 17:25 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fe496675b5e7 7194472: FileKeyTab.java test fails on Windows Reviewed-by: alanb ! test/sun/security/krb5/auto/FileKeyTab.java Changeset: 06d0478023ca Author: jjg Date: 2012-08-28 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/06d0478023ca 7194032: update tests for upcoming changes for jtreg Reviewed-by: alanb, iris ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh Changeset: 997e0d6238b7 Author: jjg Date: 2012-08-28 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/997e0d6238b7 7194035: update tests for upcoming changes for jtreg Reviewed-by: alanb, sspitsyn ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh Changeset: c5099c988cce Author: alanb Date: 2012-08-28 11:12 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c5099c988cce 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Reviewed-by: dholmes, alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java Changeset: 8b90182f2b33 Author: mullan Date: 2012-08-28 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8b90182f2b33 7192896: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: ca7f914b5fea Author: mullan Date: 2012-08-28 08:46 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ca7f914b5fea Merge Changeset: bfd5ecb1b4aa Author: dcubed Date: 2012-08-28 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bfd5ecb1b4aa 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Reviewed-by: alanb ! test/ProblemList.txt Changeset: 2bb076d17162 Author: lana Date: 2012-08-28 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2bb076d17162 Merge ! make/common/Program.gmk - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: d75666f36cfe Author: lana Date: 2012-08-30 20:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d75666f36cfe Merge - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java Changeset: 1f37a6b26a6b Author: malenkov Date: 2012-06-15 21:01 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1f37a6b26a6b 7162473: ConstructorFinder/FieldFinder/MethodFinder gives access to restricted classes Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/FieldFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java Changeset: 35f97cef5c26 Author: malenkov Date: 2012-06-19 20:34 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/35f97cef5c26 7162476: XMLDecoder security issue via ClassFinder Reviewed-by: art, ahgross ! make/sun/Makefile - make/sun/beans/Makefile + src/share/classes/com/sun/beans/editors/BooleanEditor.java + src/share/classes/com/sun/beans/editors/ByteEditor.java + src/share/classes/com/sun/beans/editors/ColorEditor.java + src/share/classes/com/sun/beans/editors/DoubleEditor.java + src/share/classes/com/sun/beans/editors/EnumEditor.java + src/share/classes/com/sun/beans/editors/FloatEditor.java + src/share/classes/com/sun/beans/editors/FontEditor.java + src/share/classes/com/sun/beans/editors/IntegerEditor.java + src/share/classes/com/sun/beans/editors/LongEditor.java + src/share/classes/com/sun/beans/editors/NumberEditor.java + src/share/classes/com/sun/beans/editors/ShortEditor.java + src/share/classes/com/sun/beans/editors/StringEditor.java ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java ! src/share/classes/com/sun/beans/finder/ClassFinder.java ! src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java + src/share/classes/com/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java ! test/java/beans/Introspector/4520754/Test4520754.java ! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java ! test/java/beans/PropertyEditor/Test6963811.java Changeset: bc84e7d15615 Author: malenkov Date: 2012-07-31 21:01 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc84e7d15615 7183701: [TEST] closed/java/beans/security/TestClassFinder.java - compilation failed Reviewed-by: rupashka ! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java ! test/java/beans/PropertyEditor/Test6963811.java Changeset: 82351952278f Author: bagiras Date: 2012-08-30 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/82351952278f 7163201: Simplify toolkit internals references Reviewed-by: art, anthony, ahgross ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/javax/swing/ClientPropertyKey.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java ! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: bc21b21d8387 Author: bagiras Date: 2012-07-23 15:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc21b21d8387 7180036: Build failure in Mac platform caused by fix # 7163201 Reviewed-by: art, kizune, ahgross ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 32ac225d85f1 Author: bagiras Date: 2012-07-25 19:46 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/32ac225d85f1 7185678: java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java failed with NPE Reviewed-by: art, ahgross ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java Changeset: b195c7431fbc Author: lana Date: 2012-08-30 20:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b195c7431fbc Merge ! make/sun/Makefile - make/sun/beans/Makefile ! src/share/classes/java/awt/EventQueue.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java Changeset: e946d8fcbd70 Author: malenkov Date: 2012-08-31 09:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e946d8fcbd70 7194567: Improve long term persistence of java.beans objects Reviewed-by: ahgross, art ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java Changeset: 0c20f5dbede9 Author: lana Date: 2012-08-31 12:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0c20f5dbede9 Merge Changeset: a4f0043a5621 Author: jrose Date: 2012-08-17 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a4f0043a5621 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Reviewed-by: twisti, kvn ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/BigArityTest.java - test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 26a8b57bd6c0 Author: twisti Date: 2012-08-24 15:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/26a8b57bd6c0 Merge - test/java/lang/invoke/MaxTest.java Changeset: a43f1cd05776 Author: jrose Date: 2012-08-28 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a43f1cd05776 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 59231f2cb6e1 Author: twisti Date: 2012-08-28 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/59231f2cb6e1 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Reviewed-by: kvn ! test/java/lang/invoke/PermuteArgsTest.java Changeset: 3f42c0d924d2 Author: twisti Date: 2012-08-31 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3f42c0d924d2 Merge Changeset: 6f41c7242a2e Author: jcoomes Date: 2012-08-31 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6f41c7242a2e Merge - test/java/lang/invoke/MaxTest.java Changeset: 1f3f4b333341 Author: jcoomes Date: 2012-09-05 12:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1f3f4b333341 Merge - make/sun/beans/Makefile - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java From david.katleman at oracle.com Wed Sep 5 23:10:09 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 05 Sep 2012 23:10:09 +0000 Subject: hg: jdk8/build/langtools: 8 new changesets Message-ID: <20120905231026.299C047917@hg.openjdk.java.net> Changeset: c47742f53f99 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c47742f53f99 Added tag jdk8-b54 for changeset 9cf72631baf5 ! .hgtags Changeset: 9d47f4850714 Author: jjh Date: 2012-08-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9d47f4850714 7191449: update copyright year to match last edit in jdk8 langtools repository Reviewed-by: jjh Contributed-by: steve.sides at oracle.com ! make/jprt.properties ! make/tools/anttasks/CompilePropertiesTask.java ! make/tools/anttasks/GenStubsTask.java ! make/tools/anttasks/SelectToolTask.java ! make/tools/compileproperties/CompileProperties.java ! make/tools/genstubs/GenStubs.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/api/7086261/T7086261.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/IllegalDot.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/typevars/T7148242.java ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/parser/T4881269.java ! test/tools/javac/processing/TestWarnErrorCount.java Changeset: 5ac2e9ee969e Author: jjg Date: 2012-08-17 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/5ac2e9ee969e 7192449: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 464f52f59f7d Author: sundar Date: 2012-08-20 21:24 +0530 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/464f52f59f7d 7181320: javac NullPointerException for switch labels with cast to String expressions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/StringsInSwitch/7181320/BinOpInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CastInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel1.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel2.java Changeset: 37008b4cd97a Author: jjg Date: 2012-08-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/37008b4cd97a 7192744: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/T6920317.java Changeset: c9749226cdde Author: ksrini Date: 2012-08-27 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c9749226cdde 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 542c87b8ce7f Author: lana Date: 2012-08-27 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/542c87b8ce7f Merge Changeset: e48e7e1f026b Author: lana Date: 2012-08-30 20:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e48e7e1f026b Merge From david.holmes at oracle.com Thu Sep 6 01:02:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Sep 2012 11:02:42 +1000 Subject: debuginfo/diz files in built images In-Reply-To: <367958348.1241630.1346857250712.JavaMail.root@redhat.com> References: <367958348.1241630.1346857250712.JavaMail.root@redhat.com> Message-ID: <5047F632.90007@oracle.com> Andrew, On 6/09/2012 1:00 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Interesting point. >> >> Should .diz files be removed when packaging JDK/JRE for Linux ? >> > > Specifically talking about packaging, distro build systems already handle > stripping, etc. themselves so we've been setting STRIP_POLICY=no_strip. > However, this still creates the diz files, even though the debuginfo is > still in the binaries. > > I have a couple of changesets to fix this, one for HotSpot& one for JDK, > basically making diz production conditional on STRIP_POLICY not being set > to no_strip. I'll try and upstream them, if that sounds the correct thing > to do. We already have ENABLE_FULL_DEBUG_SYMBOLS to control whether we should try to produce the debuginfo files. And ZIP_DEBUGINFO_FILES to determine whether we then zip it to produce the .diz file. My query is whether those files should then end up in the jre and jdk images that the build produces. I had thought no because the Oracle JDKs don't contain them and our RE processes have to exclude them when creating our bundles. Further, there is a bug in the build logic that causes a JRE to get diz files for libraries that aren't there. I thought a separate debuginfo.zip target might be better and leave them out of the images. Do other distros "package" things based on the jre and jdk images produced by the build or do they use the raw build artefacts directly? Thanks, David >> 2012/9/5 David Holmes: >>> Dan, >>> >>> Sorry, not meaning to ruffle your feathers. >>> >>> The reason I say the diz-in-image story is unclear is because there >>> are no >>> explicit rules that indicates that diz files should end up in a JDK >>> or JRE >>> image. I can accept that everything should go in a full JDK image. >>> But a JRE >>> is a JDK with a bunch of things left out and some of those things >>> are >>> libraries. But because diz files are not mentioned explicitly in >>> the rules >>> for making images we actually get the diz files for the libraries >>> that were >>> removed! They are simply copied from the build artifacts location >>> to the jre >>> image location specifically libattach.diz and libsaproc.diz. Maybe >>> that was >>> a simple oversight. >>> >>> Additionally it is unclear to me why we have diz files for some >>> libraries >>> and not others? >>> >>> Anyway as I said this will need to be modified for the profile >>> work, in >>> consultation with all the interested parties. >>> >>> Thanks, >>> David >>> >>> On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: >>>> >>>> On 9/2/12 9:37 PM, David Holmes wrote: >>>>> >>>>> Hi Dan, >>>>> >>>>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> On 9/2/12 7:26 PM, David Holmes wrote: >>>>>>> >>>>>>> The build will create debuginfo/diz files as requested - that's >>>>>>> fine. >>>>>>> >>>>>>> What I'm unclear about is where those files should actually >>>>>>> appear in >>>>>>> our build artifacts, specifically the jdk/jre images that are >>>>>>> created. >>>>>>> >>>>>>> Internally when we create binary images RE strips all the >>>>>>> debuginfo/diz files out. >>>>>> >>>>>> >>>>>> Not quite. The RE makefiles will put debug info files into a >>>>>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>>>>> .map and .pdb files. For the regular bundles, the RE makefiles >>>>>> will not include debug info files. Not quite the same as >>>>>> stripping them out. >>>>> >>>>> >>>>> Not trying to split hairs but if the image contains them and the >>>>> RE >>>>> bundle of the image does not, then the RE process is stripping >>>>> them out. >>>> >>>> >>>> The above is implying that there is a single RE bundle and that >>>> hasn't >>>> been true for the tar-style universe for quite a long time; the >>>> demo >>>> bundle was added by around JDK8-B20 or so. For the package-style >>>> universe, I don't think that has ever been true. >>>> >>>> RE's makefiles take the image generated by the build and package >>>> up the >>>> various files into two or more bundles. I believe each platform >>>> has two >>>> styles of bundles. For Solaris, SVR4 style packages and tar/zip >>>> bundles. >>>> For Windows, an EXE installer and tar/zip bundles. For Linux RPM >>>> packages >>>> and tar/ZIP bundles. >>>> >>>> So I'll stick with my assertion that the RE process is placing >>>> debug info >>>> files into a separate bundle and is not stripping them out. >>>> >>>> >>>> >>>>> >>>>>>> But the build itself seems to treat them in an ad-hoc manner: >>>>>>> >>>>>>> - The new build deliberately excludes debuginfo/diz files >>>>>>> associated >>>>>>> with binaries, but will include any related to libraries (via >>>>>>> generic >>>>>>> copying routine). (It's obvious from the comments related to >>>>>>> this that >>>>>>> there is some puzzlement as to this reasoning.) >>>>>> >>>>>> >>>>>> Sorry I haven't looked at the new build system. >>>>> >>>>> >>>>> It tries to emulate the old build. >>>>> >>>>>>> - The old build also tries to exclude the files associated with >>>>>>> binaries, but only handles .debuginfo not .diz :( >>>>>> >>>>>> >>>>>> During one round in the FDS project, I included .debuginfo/.diz >>>>>> files >>>>>> right next to some of the binaries. Apparently that's not >>>>>> allowed >>>>>> without >>>>>> explicit permission. The contents of the "bin" directory are >>>>>> controlled >>>>>> and there are tests to verify those contents. >>>>>> >>>>>> I changed the Makefiles for the few binaries that support FDS to >>>>>> not >>>>>> install the debug info files with the binaries, but they are >>>>>> left in >>>>>> the normal build artifacts location if someone has the need to >>>>>> use >>>>>> them. Of course, I've had queries for debug info files for the >>>>>> binaries >>>>>> to be included in the debuginfo.zip bundles. I'm not planning to >>>>>> fight >>>>>> that battle. >>>>> >>>>> >>>>> Okay that explains the special handling for binaries. So how do >>>>> these >>>>> then get into the debuginfo.zip? Or don't they? >>>> >>>> >>>> They don't. They are only available via the build artifacts that >>>> are archived. >>>> >>>> >>>> >>>>> >>>>>>> Those associated with libraries just seem to get copied if they >>>>>>> happen >>>>>>> to be there >>>>>> >>>>>> >>>>>> All of the logic that copies debug info files to the image >>>>>> should do >>>>>> so if they happen to be there. Not all component support FDS now >>>>>> or >>>>>> in the future so the logic needs to adapt to what is built. >>>>>> >>>>>> >>>>>>> As I said this all seems very ad-hoc to me. I would expect to >>>>>>> see no >>>>>>> debuginfo/diz files in a created image by default, and have a >>>>>>> separate >>>>>>> target that would produce a tar file of all the debuginfo/diz >>>>>>> files >>>>>>> ready to overlay on an existing image. >>>>>> >>>>>> >>>>>> Close. The image has to have the debug info or .diz files in >>>>>> order for >>>>>> the RE makefiles to generate the debuginfo.zip files. It is the >>>>>> RE >>>>>> makefiles that handle the packaging. Just like the demos are >>>>>> always >>>>>> built and it is the RE makefiles that put them in a separate >>>>>> bundle. >>>>> >>>>> >>>>> So therein lies the problem. RE lies outside of the OpenJDK build >>>>> system. If the RE Makefiles can copy an image they can copy the >>>>> debuginfo files too. I'd much rather see no debuginfo files in >>>>> the >>>>> built images (unless requested) and a distinct debuginfo related >>>>> target (that RE could use if they choose). That would seem to be >>>>> simpler all round. >>>> >>>> >>>> My understanding is that "the image" is supposed to be the >>>> complete >>>> image if every bundle is extracted. I believe that is how the >>>> packages >>>> are sanity checked to be complete. RE's Makefiles are meant to >>>> process >>>> "the image" into bundles. They aren't meant to add files of their >>>> own. >>>> >>>> If you are planning to change the meaning of "the image" or if you >>>> are planning to put files into bundles that are not in "the >>>> image", >>>> then you'll need to coordinate with RE and whoever does the >>>> package >>>> inventory testing. >>>> >>>> Also, if you change the way this works, keep in mind that some of >>>> the >>>> Makefiles generate their objects into a temporary directory and >>>> then >>>> copy things from that temporary directory to the image. Other >>>> Makefiles >>>> generate their objects directly into the image. For the latter, >>>> you'll >>>> have to move the debug info file(s) out of the image into some >>>> other >>>> place where it can be picked up by whatever bundling process you >>>> create >>>> to make the debuginfo.zip file. >>>> >>>> >>>> >>>>> >>>>>>> Thoughts/comments? >>>>>>> >>>>>>> I have to deal with this for the SE Profile work, where we will >>>>>>> not >>>>>>> want these files present in any of the images. >>>>>> >>>>>> >>>>>> It should be fine if the Embedded profile does not generate >>>>>> debug info >>>>>> files or if the Embedded profile generates debug info, but does >>>>>> not >>>>>> copy the debug info files into the image area. The RE makefiles >>>>>> will >>>>>> handle the presence or absence of debug info files. >>>>> >>>>> >>>>> These are not embedded profiles, these are just profiles - it is >>>>> all >>>>> to be part of SE in Java 8. The build is supposed to create an >>>>> image >>>>> corresponding to each profile. I can certainly specialise the >>>>> handling >>>>> of the debuginfo files for the profiles, but it seemed to me that >>>>> the >>>>> overall debuginfo-in-image story was rather unclear. >>>> >>>> >>>> I'm sorry you think that the debuginfo-in-image story is unclear. >>>> I thought I did a pretty good job integrating FDS into the whole >>>> OpenJDK build process somewhat seamlessly. I guess not. >>>> >>>> The key things to remember in all this is that debug info files >>>> (like the demos) have to end up in a separate bundle or bundles. >>>> So if you change the way this is all implemented, you still have >>>> to follow the separate bundle rule. >>>> >>>> >>>> >>>>> >>>>>> However, the non-Embedded profile needs to continue to generate >>>>>> and >>>>>> copy debug info files for those components that already support >>>>>> FDS. >>>>>> If you change the non-Embedded logic to not copy the debug info >>>>>> files >>>>>> into the image area, the RE debuginfo.zip bundle will not be >>>>>> created >>>>>> and that will break FDS. >>>>> >>>>> >>>>> RE processes will have to change to handle profiles in any case. >>>>> I >>>>> think they'd rather get a debuginfo.zip out of the build than >>>>> having >>>>> to create it themselves. >>>> >>>> >>>> Interesting and not something that I have ever heard. I got the >>>> impression that RE needed to have control over what was bundled >>>> and how it was bundled. It's kind of hard to certify/vouch for a >>>> process when you don't do it yourself, but that's not really my >>>> call. >>>> >>>> Good luck with the tweaking of the build and packaging processes. >>>> Just remember: There be dragons here! >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> David >> > From david.holmes at oracle.com Thu Sep 6 01:09:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Sep 2012 11:09:14 +1000 Subject: debuginfo/diz files in built images In-Reply-To: <50475B05.4010405@oracle.com> References: <5044075E.50301@oracle.com> <50441A3C.5040001@oracle.com> <504425F9.6020405@oracle.com> <5046074C.8080402@oracle.com> <50472D69.1060209@oracle.com> <50475B05.4010405@oracle.com> Message-ID: <5047F7BA.1030602@oracle.com> On 6/09/2012 12:00 AM, Daniel D. Daugherty wrote: > On 9/5/12 4:46 AM, David Holmes wrote: >> Dan, >> >> Sorry, not meaning to ruffle your feathers. > > Not ruffled. Just very tired of FDS. Understood. Thanks for your patience and forbearance. :) > If the libraries are removed from the image, then that same logic should > also remove debug info files or .diz files. Maybe I'm misunderstanding > something here. The logic to do so is flawed. Here's how libattach gets excluded: # Attach library is JDK only NOTJRE_SHARED_LIBS += $(LIB_PREFIX)attach.$(LIBRARY_SUFFIX) but the debuginfo.diz file is not also added when it should be. >> Additionally it is unclear to me why we have diz files for some >> libraries and not others? > > I implemented complete FDS for Linux and Solaris for hotspot. > I implemented FDS for Linux and Solaris for Runtime and Serviceability > related libraries in the JDK. I did not implement FDS for any other > team's libraries. Thanks for clarifying. I don't recognize all the libraries by name so couldn't tell what the logical grouping was. Cheers, David ----- > Of course, Win* has had FDS since JDK1.4.1 so complete FDS is > implemented everywhere on Windows. > > >> Anyway as I said this will need to be modified for the profile work, >> in consultation with all the interested parties. > > Please keep me in the loop. > > Dan > > >> >> Thanks, >> David >> >> On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: >>> On 9/2/12 9:37 PM, David Holmes wrote: >>>> Hi Dan, >>>> >>>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>>>> On 9/2/12 7:26 PM, David Holmes wrote: >>>>>> The build will create debuginfo/diz files as requested - that's fine. >>>>>> >>>>>> What I'm unclear about is where those files should actually appear in >>>>>> our build artifacts, specifically the jdk/jre images that are >>>>>> created. >>>>>> >>>>>> Internally when we create binary images RE strips all the >>>>>> debuginfo/diz files out. >>>>> >>>>> Not quite. The RE makefiles will put debug info files into a >>>>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>>>> .map and .pdb files. For the regular bundles, the RE makefiles >>>>> will not include debug info files. Not quite the same as >>>>> stripping them out. >>>> >>>> Not trying to split hairs but if the image contains them and the RE >>>> bundle of the image does not, then the RE process is stripping them >>>> out. >>> >>> The above is implying that there is a single RE bundle and that hasn't >>> been true for the tar-style universe for quite a long time; the demo >>> bundle was added by around JDK8-B20 or so. For the package-style >>> universe, I don't think that has ever been true. >>> >>> RE's makefiles take the image generated by the build and package up the >>> various files into two or more bundles. I believe each platform has two >>> styles of bundles. For Solaris, SVR4 style packages and tar/zip bundles. >>> For Windows, an EXE installer and tar/zip bundles. For Linux RPM >>> packages >>> and tar/ZIP bundles. >>> >>> So I'll stick with my assertion that the RE process is placing debug >>> info >>> files into a separate bundle and is not stripping them out. >>> >>> >>>> >>>>>> But the build itself seems to treat them in an ad-hoc manner: >>>>>> >>>>>> - The new build deliberately excludes debuginfo/diz files associated >>>>>> with binaries, but will include any related to libraries (via generic >>>>>> copying routine). (It's obvious from the comments related to this >>>>>> that >>>>>> there is some puzzlement as to this reasoning.) >>>>> >>>>> Sorry I haven't looked at the new build system. >>>> >>>> It tries to emulate the old build. >>>> >>>>>> - The old build also tries to exclude the files associated with >>>>>> binaries, but only handles .debuginfo not .diz :( >>>>> >>>>> During one round in the FDS project, I included .debuginfo/.diz files >>>>> right next to some of the binaries. Apparently that's not allowed >>>>> without >>>>> explicit permission. The contents of the "bin" directory are >>>>> controlled >>>>> and there are tests to verify those contents. >>>>> >>>>> I changed the Makefiles for the few binaries that support FDS to not >>>>> install the debug info files with the binaries, but they are left in >>>>> the normal build artifacts location if someone has the need to use >>>>> them. Of course, I've had queries for debug info files for the >>>>> binaries >>>>> to be included in the debuginfo.zip bundles. I'm not planning to fight >>>>> that battle. >>>> >>>> Okay that explains the special handling for binaries. So how do these >>>> then get into the debuginfo.zip? Or don't they? >>> >>> They don't. They are only available via the build artifacts that >>> are archived. >>> >>> >>>> >>>>>> Those associated with libraries just seem to get copied if they >>>>>> happen >>>>>> to be there >>>>> >>>>> All of the logic that copies debug info files to the image should do >>>>> so if they happen to be there. Not all component support FDS now or >>>>> in the future so the logic needs to adapt to what is built. >>>>> >>>>> >>>>>> As I said this all seems very ad-hoc to me. I would expect to see no >>>>>> debuginfo/diz files in a created image by default, and have a >>>>>> separate >>>>>> target that would produce a tar file of all the debuginfo/diz files >>>>>> ready to overlay on an existing image. >>>>> >>>>> Close. The image has to have the debug info or .diz files in order for >>>>> the RE makefiles to generate the debuginfo.zip files. It is the RE >>>>> makefiles that handle the packaging. Just like the demos are always >>>>> built and it is the RE makefiles that put them in a separate bundle. >>>> >>>> So therein lies the problem. RE lies outside of the OpenJDK build >>>> system. If the RE Makefiles can copy an image they can copy the >>>> debuginfo files too. I'd much rather see no debuginfo files in the >>>> built images (unless requested) and a distinct debuginfo related >>>> target (that RE could use if they choose). That would seem to be >>>> simpler all round. >>> >>> My understanding is that "the image" is supposed to be the complete >>> image if every bundle is extracted. I believe that is how the packages >>> are sanity checked to be complete. RE's Makefiles are meant to process >>> "the image" into bundles. They aren't meant to add files of their own. >>> >>> If you are planning to change the meaning of "the image" or if you >>> are planning to put files into bundles that are not in "the image", >>> then you'll need to coordinate with RE and whoever does the package >>> inventory testing. >>> >>> Also, if you change the way this works, keep in mind that some of the >>> Makefiles generate their objects into a temporary directory and then >>> copy things from that temporary directory to the image. Other Makefiles >>> generate their objects directly into the image. For the latter, you'll >>> have to move the debug info file(s) out of the image into some other >>> place where it can be picked up by whatever bundling process you create >>> to make the debuginfo.zip file. >>> >>> >>>> >>>>>> Thoughts/comments? >>>>>> >>>>>> I have to deal with this for the SE Profile work, where we will not >>>>>> want these files present in any of the images. >>>>> >>>>> It should be fine if the Embedded profile does not generate debug info >>>>> files or if the Embedded profile generates debug info, but does not >>>>> copy the debug info files into the image area. The RE makefiles will >>>>> handle the presence or absence of debug info files. >>>> >>>> These are not embedded profiles, these are just profiles - it is all >>>> to be part of SE in Java 8. The build is supposed to create an image >>>> corresponding to each profile. I can certainly specialise the handling >>>> of the debuginfo files for the profiles, but it seemed to me that the >>>> overall debuginfo-in-image story was rather unclear. >>> >>> I'm sorry you think that the debuginfo-in-image story is unclear. >>> I thought I did a pretty good job integrating FDS into the whole >>> OpenJDK build process somewhat seamlessly. I guess not. >>> >>> The key things to remember in all this is that debug info files >>> (like the demos) have to end up in a separate bundle or bundles. >>> So if you change the way this is all implemented, you still have >>> to follow the separate bundle rule. >>> >>> >>>> >>>>> However, the non-Embedded profile needs to continue to generate and >>>>> copy debug info files for those components that already support FDS. >>>>> If you change the non-Embedded logic to not copy the debug info files >>>>> into the image area, the RE debuginfo.zip bundle will not be created >>>>> and that will break FDS. >>>> >>>> RE processes will have to change to handle profiles in any case. I >>>> think they'd rather get a debuginfo.zip out of the build than having >>>> to create it themselves. >>> >>> Interesting and not something that I have ever heard. I got the >>> impression that RE needed to have control over what was bundled >>> and how it was bundled. It's kind of hard to certify/vouch for a >>> process when you don't do it yourself, but that's not really my >>> call. >>> >>> Good luck with the tweaking of the build and packaging processes. >>> Just remember: There be dragons here! >>> >>> Dan >>> >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> David From kelly.ohair at oracle.com Thu Sep 6 01:43:10 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 5 Sep 2012 18:43:10 -0700 Subject: Windows build failure when building JLI In-Reply-To: <8015E8B0-EC66-4256-A20E-7880E99C6828@oracle.com> References: <50448851.90808@oracle.com> <5044909E.5000507@oracle.com> <50449A61.5070504@oracle.com> <8015E8B0-EC66-4256-A20E-7880E99C6828@oracle.com> Message-ID: On Sep 4, 2012, at 4:53 AM, Magnus Ihse Bursie wrote: >> BTW, what's the reason to continue the new build infrastructure development in a separate project (build-infra), not in the master workspace? > > There are strict formal rules on the build forest, that every single commit should have a WebRev and a CR. That would be highly impractical since build-infra is still under active development. > > /Magnus What Magnus says is true, however we should be doing more sync ups with jdk8/build, my apologies for that. Hopefully, we can do a sync up very soon. -kto From kelly.ohair at oracle.com Thu Sep 6 04:08:53 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 5 Sep 2012 21:08:53 -0700 Subject: Need reviewers: more predictable binaries Message-ID: Need a reviewer for this change. http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ It does change source, but it's effectively a build change. The goal here is to try and create more predictable binary files and remove the possibility that a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. So two changes: * sort the .o files during links so they are always provided to the linker in the same order. * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files will always have a consistent string literal in them, making it easier to compare binaries between builds. Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in macros but it only will get evaluated in the source file being compiled. It is rare that macros using __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. -kto From fredrik.ohrstrom at oracle.com Thu Sep 6 06:59:06 2012 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Thu, 6 Sep 2012 08:59:06 +0200 Subject: Need reviewers: more predictable binaries In-Reply-To: References: Message-ID: <86F56FBF-BAC4-40DC-B05D-A6DA96305B34@oracle.com> Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the source files? At some time in the future?. //Fredrik 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: > > Need a reviewer for this change. > > http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > > It does change source, but it's effectively a build change. > > The goal here is to try and create more predictable binary files and remove the possibility that > a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. > > So two changes: > * sort the .o files during links so they are always provided to the linker in the same order. > * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled > > The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler > and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files > will always have a consistent string literal in them, making it easier to compare binaries between builds. > Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. > The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in > macros but it only will get evaluated in the source file being compiled. It is rare that macros using > __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. > > -kto From tim.bell at oracle.com Thu Sep 6 07:16:06 2012 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 06 Sep 2012 00:16:06 -0700 Subject: Need reviewers: more predictable binaries In-Reply-To: References: Message-ID: <50484DB6.8070806@oracle.com> On 09/05/12 21:08, Kelly O'Hair wrote: > Need a reviewer for this change. > > http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > > It does change source, but it's effectively a build change. > > The goal here is to try and create more predictable binary files and remove the possibility that > a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. > > So two changes: > * sort the .o files during links so they are always provided to the linker in the same order. > * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled > > The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler > and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files > will always have a consistent string literal in them, making it easier to compare binaries between builds. > Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. > The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in > macros but it only will get evaluated in the source file being compiled. It is rare that macros using > __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. > > -kto Looks good ... this is long overdue and it is a pattern we all need to use going forward. Approved. Tim From artem.ananiev at oracle.com Thu Sep 6 10:53:59 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 06 Sep 2012 14:53:59 +0400 Subject: Windows build failure when building JLI In-Reply-To: References: <50448851.90808@oracle.com> <5044909E.5000507@oracle.com> <50449A61.5070504@oracle.com> <8015E8B0-EC66-4256-A20E-7880E99C6828@oracle.com> Message-ID: <504880C7.4060101@oracle.com> On 9/6/2012 5:43 AM, Kelly O'Hair wrote: > > On Sep 4, 2012, at 4:53 AM, Magnus Ihse Bursie wrote: > >>> BTW, what's the reason to continue the new build infrastructure >>> development in a separate project (build-infra), not in the >>> master workspace? >> >> There are strict formal rules on the build forest, that every >> single commit should have a WebRev and a CR. That would be highly >> impractical since build-infra is still under active development. Usually a project is merged to JDK mainline, when it's more or less ready - at least, this is what we did with Mac OS X port. So in other words, the new build system should be considered as experimental at the current moment? >> /Magnus > > What Magnus says is true, however we should be doing more sync ups > with jdk8/build, my apologies for that. > > Hopefully, we can do a sync up very soon. That's good news. Thanks, Artem > -kto From erik.joelsson at oracle.com Thu Sep 6 15:28:33 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 06 Sep 2012 17:28:33 +0200 Subject: Need reviewers: more predictable binaries In-Reply-To: References: Message-ID: <5048C121.1030709@oracle.com> I would like to have sorts added to Demo.gmk too. I just hit a case where it caused a difference for me between old build and build-infra. /Erik On 2012-09-06 06:08, Kelly O'Hair wrote: > Need a reviewer for this change. > > http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > > It does change source, but it's effectively a build change. > > The goal here is to try and create more predictable binary files and remove the possibility that > a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. > > So two changes: > * sort the .o files during links so they are always provided to the linker in the same order. > * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled > > The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler > and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files > will always have a consistent string literal in them, making it easier to compare binaries between builds. > Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. > The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in > macros but it only will get evaluated in the source file being compiled. It is rare that macros using > __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. > > -kto From kelly.ohair at oracle.com Thu Sep 6 16:23:34 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 6 Sep 2012 09:23:34 -0700 Subject: Need reviewers: more predictable binaries In-Reply-To: <5048C121.1030709@oracle.com> References: <5048C121.1030709@oracle.com> Message-ID: <7162AED0-477B-4B20-B426-39C3AB3FABC1@oracle.com> I'll fix that. -kto On Sep 6, 2012, at 8:28 AM, Erik Joelsson wrote: > I would like to have sorts added to Demo.gmk too. I just hit a case where it caused a difference for me between old build and build-infra. > > /Erik > > On 2012-09-06 06:08, Kelly O'Hair wrote: >> Need a reviewer for this change. >> >> http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ >> >> It does change source, but it's effectively a build change. >> >> The goal here is to try and create more predictable binary files and remove the possibility that >> a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. >> >> So two changes: >> * sort the .o files during links so they are always provided to the linker in the same order. >> * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled >> >> The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler >> and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files >> will always have a consistent string literal in them, making it easier to compare binaries between builds. >> Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. >> The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in >> macros but it only will get evaluated in the source file being compiled. It is rare that macros using >> __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. >> >> -kto From kelly.ohair at oracle.com Thu Sep 6 16:29:05 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 6 Sep 2012 09:29:05 -0700 Subject: Need reviewers: more predictable binaries In-Reply-To: <86F56FBF-BAC4-40DC-B05D-A6DA96305B34@oracle.com> References: <86F56FBF-BAC4-40DC-B05D-A6DA96305B34@oracle.com> Message-ID: <688FB041-D240-4744-A374-B2644B579A5E@oracle.com> Yes, but I feel like I need to get some kind of approval from a higher level before I try and declare that use of THIS_FILE is a 'jdk convention', and that will trigger long debates :^( I also need to deal with hotspot, which is a bit trickier because of the macros being expanded in include files (inline method bodies inside *.hpp files). -kto On Sep 5, 2012, at 11:59 PM, Fredrik ?hrstr?m wrote: > Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the source files? At some time in the future?. > > //Fredrik > > 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: > >> >> Need a reviewer for this change. >> >> http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ >> >> It does change source, but it's effectively a build change. >> >> The goal here is to try and create more predictable binary files and remove the possibility that >> a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. >> >> So two changes: >> * sort the .o files during links so they are always provided to the linker in the same order. >> * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled >> >> The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler >> and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files >> will always have a consistent string literal in them, making it easier to compare binaries between builds. >> Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. >> The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in >> macros but it only will get evaluated in the source file being compiled. It is rare that macros using >> __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. >> >> -kto > From mark.reinhold at oracle.com Thu Sep 6 20:29:23 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 06 Sep 2012 13:29:23 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: michael.fang@oracle.com; Wed, 05 Sep 2012 14:08:54 PDT; <5047BF66.7080704@oracle.com> Message-ID: <20120906202923.834A7856@eggemoggin.niobe.net> 2012/9/5 14:08 -0700, michael.fang at oracle.com: > Please help to review the new JDK8 file for the following CR: > 7196354 check-in jdk.tbom file to openjdk repo > > The webrev is located at: > http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ This file needs a more descriptive name, especially if it's going to be in the root of the source tree. Suggestion: translated-files.xml . Is there a DTD or a schema for this file? I can guess what most of it means, but I might guess incorrectly. [line 8] "OpenJDK" isn't a component, it's a community. I think you mean "JDK" here. The "JDK" / "JRE" division in this file is somewhat artificial and likely to become incorrect over time -- not every developer knows exactly which files are in the JRE vs. the full JDK. I suggest doing away with that division and simply sorting the file-set elements by source file name. At a glance it looks like the source and target attributes for any given file are identical. Do you expect there to be cases where they're different? > ... > > Mark: > Since the dev team will need to maintain this file in the future (modifying it > if you add or delete resource files), I temporarily put down your name as > contact for the file. Please figure out the proper owner and we can update it > again. We don't put contact names in source code. Please remove my name, and do not add another. > ... > > In the future, if any bug/rfe requires adding/deleting resource files, the dev > work should include updating this file to reflect the correct resource file > list. (and please ask me to review it). If you expect other people to update this file over time then you need to document that expectation somewhere and, as importantly, you need to document the syntax and semantics of the file. Fortunately we have a way to do that, namely the JEP process (http://openjdk.java.net/jeps/). I suggest you draft a JEP for this and circulate it for review along with the webrev. - Mark From John.Coomes at oracle.com Thu Sep 6 20:57:34 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 6 Sep 2012 13:57:34 -0700 Subject: Need reviewers: more predictable binaries In-Reply-To: <688FB041-D240-4744-A374-B2644B579A5E@oracle.com> References: <86F56FBF-BAC4-40DC-B05D-A6DA96305B34@oracle.com> <688FB041-D240-4744-A374-B2644B579A5E@oracle.com> Message-ID: <20553.3646.656223.621103@oracle.com> Kelly O'Hair (kelly.ohair at oracle.com) wrote: > Yes, but I feel like I need to get some kind of approval from a higher level before I try and declare that > use of THIS_FILE is a 'jdk convention', and that will trigger long debates :^( > > I also need to deal with hotspot, which is a bit trickier because of the macros being expanded in include > files (inline method bodies inside *.hpp files). There is also the fact that the basenames are not unique. Maybe it won't be an issue, but someone should really check. Have you looked at normalizing to the path relative to the repo root? -John > On Sep 5, 2012, at 11:59 PM, Fredrik ?hrstr?m wrote: > > > Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the source files? At some time in the future?. > > > > //Fredrik > > > > 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: > > > >> > >> Need a reviewer for this change. > >> > >> http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > >> > >> It does change source, but it's effectively a build change. > >> > >> The goal here is to try and create more predictable binary files and remove the possibility that > >> a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. > >> > >> So two changes: > >> * sort the .o files during links so they are always provided to the linker in the same order. > >> * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled > >> > >> The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler > >> and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files > >> will always have a consistent string literal in them, making it easier to compare binaries between builds. > >> Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. > >> The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in > >> macros but it only will get evaluated in the source file being compiled. It is rare that macros using > >> __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. > >> > >> -kto > > > From michael.fang at oracle.com Thu Sep 6 23:46:08 2012 From: michael.fang at oracle.com (Michael Fang) Date: Thu, 06 Sep 2012 16:46:08 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: <20120906202923.834A7856@eggemoggin.niobe.net> References: <20120906202923.834A7856@eggemoggin.niobe.net> Message-ID: <504935C0.30705@oracle.com> Hi Mark, Thanks for the review and feedback. Please see my comments inline below. thanks, -michael On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote: > 2012/9/5 14:08 -0700, michael.fang at oracle.com: >> Please help to review the new JDK8 file for the following CR: >> 7196354 check-in jdk.tbom file to openjdk repo >> >> The webrev is located at: >> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ > This file needs a more descriptive name, especially if it's going to be > in the root of the source tree. Suggestion: translated-files.xml . The translation drop system is now an Oracle-wide translation system and we are strongly recommended to follow the standard naming convention for all Oracle products, which is component-name.tbom. I have checked with the team and we can move the file away from the root of the source tree to, for example, jdk/make/jdk.tbom. > > Is there a DTD or a schema for this file? I can guess what most of it > means, but I might guess incorrectly. The XSD is available in NLSTOOLS ADE label. nlstools/lights2/Extractor/src/java/xsd/tbom.xsd It's internal information. I will find it and forward it to you separately. > > [line 8] "OpenJDK" isn't a component, it's a community. I think you mean > "JDK" here. Yes, JDK. > > The "JDK" / "JRE" division in this file is somewhat artificial and likely > to become incorrect over time -- not every developer knows exactly which > files are in the JRE vs. the full JDK. I suggest doing away with that > division and simply sorting the file-set elements by source file name. JDK and JRE are translated into different sets of languages. 2 languages for JDK and 10 for JRE. We used to divide the files this way in order to translate the files into the correct set of languages. But it's not necessary now. Sorting by groups or projects may be fine. Whatever is easy for the groups/teams to find and maintain their files. > > At a glance it looks like the source and target attributes for any given > file are identical. Do you expect there to be cases where they're > different? In jdk.tbom, source and target are the same for all files. But on jdkclosed.tbom, the man page files have different source and target directories. > >> ... >> >> Mark: >> Since the dev team will need to maintain this file in the future (modifying it >> if you add or delete resource files), I temporarily put down your name as >> contact for the file. Please figure out the proper owner and we can update it >> again. > We don't put contact names in source code. Please remove my name, and do > not add another. OK, I will remove it. > >> ... >> >> In the future, if any bug/rfe requires adding/deleting resource files, the dev >> work should include updating this file to reflect the correct resource file >> list. (and please ask me to review it). > If you expect other people to update this file over time then you need > to document that expectation somewhere and, as importantly, you need to > document the syntax and semantics of the file. Fortunately we have a > way to do that, namely the JEP process (http://openjdk.java.net/jeps/). > I suggest you draft a JEP for this and circulate it for review along > with the webrev. I will look into it. > > - Mark From kelly.ohair at oracle.com Fri Sep 7 00:39:01 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 6 Sep 2012 17:39:01 -0700 Subject: Need reviewers: more predictable binaries In-Reply-To: <20553.3646.656223.621103@oracle.com> References: <86F56FBF-BAC4-40DC-B05D-A6DA96305B34@oracle.com> <688FB041-D240-4744-A374-B2644B579A5E@oracle.com> <20553.3646.656223.621103@oracle.com> Message-ID: On Sep 6, 2012, at 1:57 PM, John Coomes wrote: > Kelly O'Hair (kelly.ohair at oracle.com) wrote: >> Yes, but I feel like I need to get some kind of approval from a higher level before I try and declare that >> use of THIS_FILE is a 'jdk convention', and that will trigger long debates :^( >> >> I also need to deal with hotspot, which is a bit trickier because of the macros being expanded in include >> files (inline method bodies inside *.hpp files). > > There is also the fact that the basenames are not unique. Maybe it > won't be an issue, but someone should really check. They aren't necessarily. But even if they were relative paths, you can't guarantee they would be unique then. The __FILE__ value is basically not well defined, anyone depending on it is probably in trouble. > > > Have you looked at normalizing to the path relative to the repo root? > If I could come up with a simple formula that did not involve a repeated exec of sed or a shell for every compilation, I could change THIS_FILE to a 'relative to the repo root' path. Just haven't come up with a good solution yet. But that could be an improvement later, e.g. ROOT_DIR:=$(shell hg root) # Or set it in top Makefile somehow? -DTHIS_FILE='"$(subst $(ROOT_DIR)/,./,$(@D))$(@F)"' might work, but it's a bit more complicated than that. -kto > > -John > >> On Sep 5, 2012, at 11:59 PM, Fredrik ?hrstr?m wrote: >> >>> Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the source files? At some time in the future?. >>> >>> //Fredrik >>> >>> 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: >>> >>>> >>>> Need a reviewer for this change. >>>> >>>> http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ >>>> >>>> It does change source, but it's effectively a build change. >>>> >>>> The goal here is to try and create more predictable binary files and remove the possibility that >>>> a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. >>>> >>>> So two changes: >>>> * sort the .o files during links so they are always provided to the linker in the same order. >>>> * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled >>>> >>>> The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler >>>> and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files >>>> will always have a consistent string literal in them, making it easier to compare binaries between builds. >>>> Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. >>>> The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in >>>> macros but it only will get evaluated in the source file being compiled. It is rare that macros using >>>> __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. >>>> >>>> -kto >>> >> From magnus.ihse.bursie at oracle.com Fri Sep 7 11:21:18 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 07 Sep 2012 13:21:18 +0200 Subject: Windows build failure when building JLI In-Reply-To: <504880C7.4060101@oracle.com> References: <50448851.90808@oracle.com> <5044909E.5000507@oracle.com> <50449A61.5070504@oracle.com> <8015E8B0-EC66-4256-A20E-7880E99C6828@oracle.com> <504880C7.4060101@oracle.com> Message-ID: <5049D8AE.8040806@oracle.com> On 2012-09-06 12:53, Artem Ananiev wrote: > > On 9/6/2012 5:43 AM, Kelly O'Hair wrote: >> >> On Sep 4, 2012, at 4:53 AM, Magnus Ihse Bursie wrote: >> >>>> BTW, what's the reason to continue the new build infrastructure >>>> development in a separate project (build-infra), not in the >>>> master workspace? >>> >>> There are strict formal rules on the build forest, that every >>> single commit should have a WebRev and a CR. That would be highly >>> impractical since build-infra is still under active development. > > Usually a project is merged to JDK mainline, when it's more or less > ready - at least, this is what we did with Mac OS X port. So in other > words, the new build system should be considered as experimental at > the current moment? Yes. The decision was made to start pushing the new build system to the mainline, as a non-default addition, at an early stage to get wide exposure to different build environments, even though it was not "ready". /Magnus From gnu.andrew at redhat.com Fri Sep 7 13:15:44 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Sep 2012 09:15:44 -0400 (EDT) Subject: debuginfo/diz files in built images In-Reply-To: <5047F632.90007@oracle.com> Message-ID: <633998898.2413580.1347023744179.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > On 6/09/2012 1:00 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Interesting point. > >> > >> Should .diz files be removed when packaging JDK/JRE for Linux ? > >> > > > > Specifically talking about packaging, distro build systems already > > handle > > stripping, etc. themselves so we've been setting > > STRIP_POLICY=no_strip. > > However, this still creates the diz files, even though the > > debuginfo is > > still in the binaries. > > > > I have a couple of changesets to fix this, one for HotSpot& one > > for JDK, > > basically making diz production conditional on STRIP_POLICY not > > being set > > to no_strip. I'll try and upstream them, if that sounds the > > correct thing > > to do. > > We already have ENABLE_FULL_DEBUG_SYMBOLS to control whether we > should > try to produce the debuginfo files. No. That implies (at least by the naming) whether or not the binaries/libraries are built with debugging symbols, not whether or not they are stripped into separate files. That is governed by STRIP_POLICY as far as I can tell. I have thought of turning off ENABLE_FULL_DEBUG_SYMBOLS based on the existing Makefile logic, but this sounds like I'm turning off debug symbols which I very much DON'T want to do. To me, the right solution seems to be to implement STRIP_POLICY=no_strip correctly. We still want debugging symbols as we had before. We don't want superfluous copies in diz files. > And ZIP_DEBUGINFO_FILES to > determine > whether we then zip it to produce the .diz file. > > My query is whether those files should then end up in the jre and jdk > images that the build produces. I had thought no because the Oracle > JDKs > don't contain them and our RE processes have to exclude them when > creating our bundles. Further, there is a bug in the build logic that > causes a JRE to get diz files for libraries that aren't there. I > thought > a separate debuginfo.zip target might be better and leave them out of > the images. > > Do other distros "package" things based on the jre and jdk images > produced by the build or do they use the raw build artefacts > directly? > The ones I'm aware of use the images, but we don't want these diz files. Distros have their own ways of stripping debug info and packaging it separately that has been in place for many years before this was added to OpenJDK. However, if someone was doing a local build, I presume they'd want them wherever they'd be picked up automatically by the debugger, not hidden away somewhere. To be honest, these changes have been nothing but a pain for us, changing the type of debug info produced to STABS on some architectures and removing needed debug info from files (until we learnt about STRIP_POLICY). The build prior to FDS was preferable and these major build changes seem to have been rushed through too quickly, especially to 7u. > Thanks, > David > > > >> 2012/9/5 David Holmes: > >>> Dan, > >>> > >>> Sorry, not meaning to ruffle your feathers. > >>> > >>> The reason I say the diz-in-image story is unclear is because > >>> there > >>> are no > >>> explicit rules that indicates that diz files should end up in a > >>> JDK > >>> or JRE > >>> image. I can accept that everything should go in a full JDK > >>> image. > >>> But a JRE > >>> is a JDK with a bunch of things left out and some of those things > >>> are > >>> libraries. But because diz files are not mentioned explicitly in > >>> the rules > >>> for making images we actually get the diz files for the libraries > >>> that were > >>> removed! They are simply copied from the build artifacts location > >>> to the jre > >>> image location specifically libattach.diz and libsaproc.diz. > >>> Maybe > >>> that was > >>> a simple oversight. > >>> > >>> Additionally it is unclear to me why we have diz files for some > >>> libraries > >>> and not others? > >>> > >>> Anyway as I said this will need to be modified for the profile > >>> work, in > >>> consultation with all the interested parties. > >>> > >>> Thanks, > >>> David > >>> > >>> On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: > >>>> > >>>> On 9/2/12 9:37 PM, David Holmes wrote: > >>>>> > >>>>> Hi Dan, > >>>>> > >>>>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: > >>>>>> > >>>>>> On 9/2/12 7:26 PM, David Holmes wrote: > >>>>>>> > >>>>>>> The build will create debuginfo/diz files as requested - > >>>>>>> that's > >>>>>>> fine. > >>>>>>> > >>>>>>> What I'm unclear about is where those files should actually > >>>>>>> appear in > >>>>>>> our build artifacts, specifically the jdk/jre images that are > >>>>>>> created. > >>>>>>> > >>>>>>> Internally when we create binary images RE strips all the > >>>>>>> debuginfo/diz files out. > >>>>>> > >>>>>> > >>>>>> Not quite. The RE makefiles will put debug info files into a > >>>>>> separate debuginfo.zip file. This includes .debuginfo, .diz, > >>>>>> .map and .pdb files. For the regular bundles, the RE makefiles > >>>>>> will not include debug info files. Not quite the same as > >>>>>> stripping them out. > >>>>> > >>>>> > >>>>> Not trying to split hairs but if the image contains them and > >>>>> the > >>>>> RE > >>>>> bundle of the image does not, then the RE process is stripping > >>>>> them out. > >>>> > >>>> > >>>> The above is implying that there is a single RE bundle and that > >>>> hasn't > >>>> been true for the tar-style universe for quite a long time; the > >>>> demo > >>>> bundle was added by around JDK8-B20 or so. For the package-style > >>>> universe, I don't think that has ever been true. > >>>> > >>>> RE's makefiles take the image generated by the build and package > >>>> up the > >>>> various files into two or more bundles. I believe each platform > >>>> has two > >>>> styles of bundles. For Solaris, SVR4 style packages and tar/zip > >>>> bundles. > >>>> For Windows, an EXE installer and tar/zip bundles. For Linux RPM > >>>> packages > >>>> and tar/ZIP bundles. > >>>> > >>>> So I'll stick with my assertion that the RE process is placing > >>>> debug info > >>>> files into a separate bundle and is not stripping them out. > >>>> > >>>> > >>>> > >>>>> > >>>>>>> But the build itself seems to treat them in an ad-hoc manner: > >>>>>>> > >>>>>>> - The new build deliberately excludes debuginfo/diz files > >>>>>>> associated > >>>>>>> with binaries, but will include any related to libraries (via > >>>>>>> generic > >>>>>>> copying routine). (It's obvious from the comments related to > >>>>>>> this that > >>>>>>> there is some puzzlement as to this reasoning.) > >>>>>> > >>>>>> > >>>>>> Sorry I haven't looked at the new build system. > >>>>> > >>>>> > >>>>> It tries to emulate the old build. > >>>>> > >>>>>>> - The old build also tries to exclude the files associated > >>>>>>> with > >>>>>>> binaries, but only handles .debuginfo not .diz :( > >>>>>> > >>>>>> > >>>>>> During one round in the FDS project, I included > >>>>>> .debuginfo/.diz > >>>>>> files > >>>>>> right next to some of the binaries. Apparently that's not > >>>>>> allowed > >>>>>> without > >>>>>> explicit permission. The contents of the "bin" directory are > >>>>>> controlled > >>>>>> and there are tests to verify those contents. > >>>>>> > >>>>>> I changed the Makefiles for the few binaries that support FDS > >>>>>> to > >>>>>> not > >>>>>> install the debug info files with the binaries, but they are > >>>>>> left in > >>>>>> the normal build artifacts location if someone has the need to > >>>>>> use > >>>>>> them. Of course, I've had queries for debug info files for the > >>>>>> binaries > >>>>>> to be included in the debuginfo.zip bundles. I'm not planning > >>>>>> to > >>>>>> fight > >>>>>> that battle. > >>>>> > >>>>> > >>>>> Okay that explains the special handling for binaries. So how do > >>>>> these > >>>>> then get into the debuginfo.zip? Or don't they? > >>>> > >>>> > >>>> They don't. They are only available via the build artifacts that > >>>> are archived. > >>>> > >>>> > >>>> > >>>>> > >>>>>>> Those associated with libraries just seem to get copied if > >>>>>>> they > >>>>>>> happen > >>>>>>> to be there > >>>>>> > >>>>>> > >>>>>> All of the logic that copies debug info files to the image > >>>>>> should do > >>>>>> so if they happen to be there. Not all component support FDS > >>>>>> now > >>>>>> or > >>>>>> in the future so the logic needs to adapt to what is built. > >>>>>> > >>>>>> > >>>>>>> As I said this all seems very ad-hoc to me. I would expect to > >>>>>>> see no > >>>>>>> debuginfo/diz files in a created image by default, and have a > >>>>>>> separate > >>>>>>> target that would produce a tar file of all the debuginfo/diz > >>>>>>> files > >>>>>>> ready to overlay on an existing image. > >>>>>> > >>>>>> > >>>>>> Close. The image has to have the debug info or .diz files in > >>>>>> order for > >>>>>> the RE makefiles to generate the debuginfo.zip files. It is > >>>>>> the > >>>>>> RE > >>>>>> makefiles that handle the packaging. Just like the demos are > >>>>>> always > >>>>>> built and it is the RE makefiles that put them in a separate > >>>>>> bundle. > >>>>> > >>>>> > >>>>> So therein lies the problem. RE lies outside of the OpenJDK > >>>>> build > >>>>> system. If the RE Makefiles can copy an image they can copy the > >>>>> debuginfo files too. I'd much rather see no debuginfo files in > >>>>> the > >>>>> built images (unless requested) and a distinct debuginfo > >>>>> related > >>>>> target (that RE could use if they choose). That would seem to > >>>>> be > >>>>> simpler all round. > >>>> > >>>> > >>>> My understanding is that "the image" is supposed to be the > >>>> complete > >>>> image if every bundle is extracted. I believe that is how the > >>>> packages > >>>> are sanity checked to be complete. RE's Makefiles are meant to > >>>> process > >>>> "the image" into bundles. They aren't meant to add files of > >>>> their > >>>> own. > >>>> > >>>> If you are planning to change the meaning of "the image" or if > >>>> you > >>>> are planning to put files into bundles that are not in "the > >>>> image", > >>>> then you'll need to coordinate with RE and whoever does the > >>>> package > >>>> inventory testing. > >>>> > >>>> Also, if you change the way this works, keep in mind that some > >>>> of > >>>> the > >>>> Makefiles generate their objects into a temporary directory and > >>>> then > >>>> copy things from that temporary directory to the image. Other > >>>> Makefiles > >>>> generate their objects directly into the image. For the latter, > >>>> you'll > >>>> have to move the debug info file(s) out of the image into some > >>>> other > >>>> place where it can be picked up by whatever bundling process you > >>>> create > >>>> to make the debuginfo.zip file. > >>>> > >>>> > >>>> > >>>>> > >>>>>>> Thoughts/comments? > >>>>>>> > >>>>>>> I have to deal with this for the SE Profile work, where we > >>>>>>> will > >>>>>>> not > >>>>>>> want these files present in any of the images. > >>>>>> > >>>>>> > >>>>>> It should be fine if the Embedded profile does not generate > >>>>>> debug info > >>>>>> files or if the Embedded profile generates debug info, but > >>>>>> does > >>>>>> not > >>>>>> copy the debug info files into the image area. The RE > >>>>>> makefiles > >>>>>> will > >>>>>> handle the presence or absence of debug info files. > >>>>> > >>>>> > >>>>> These are not embedded profiles, these are just profiles - it > >>>>> is > >>>>> all > >>>>> to be part of SE in Java 8. The build is supposed to create an > >>>>> image > >>>>> corresponding to each profile. I can certainly specialise the > >>>>> handling > >>>>> of the debuginfo files for the profiles, but it seemed to me > >>>>> that > >>>>> the > >>>>> overall debuginfo-in-image story was rather unclear. > >>>> > >>>> > >>>> I'm sorry you think that the debuginfo-in-image story is > >>>> unclear. > >>>> I thought I did a pretty good job integrating FDS into the whole > >>>> OpenJDK build process somewhat seamlessly. I guess not. > >>>> > >>>> The key things to remember in all this is that debug info files > >>>> (like the demos) have to end up in a separate bundle or bundles. > >>>> So if you change the way this is all implemented, you still have > >>>> to follow the separate bundle rule. > >>>> > >>>> > >>>> > >>>>> > >>>>>> However, the non-Embedded profile needs to continue to > >>>>>> generate > >>>>>> and > >>>>>> copy debug info files for those components that already > >>>>>> support > >>>>>> FDS. > >>>>>> If you change the non-Embedded logic to not copy the debug > >>>>>> info > >>>>>> files > >>>>>> into the image area, the RE debuginfo.zip bundle will not be > >>>>>> created > >>>>>> and that will break FDS. > >>>>> > >>>>> > >>>>> RE processes will have to change to handle profiles in any > >>>>> case. > >>>>> I > >>>>> think they'd rather get a debuginfo.zip out of the build than > >>>>> having > >>>>> to create it themselves. > >>>> > >>>> > >>>> Interesting and not something that I have ever heard. I got the > >>>> impression that RE needed to have control over what was bundled > >>>> and how it was bundled. It's kind of hard to certify/vouch for a > >>>> process when you don't do it yourself, but that's not really my > >>>> call. > >>>> > >>>> Good luck with the tweaking of the build and packaging > >>>> processes. > >>>> Just remember: There be dragons here! > >>>> > >>>> Dan > >>>> > >>>> > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> David > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Fri Sep 7 22:44:16 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 08 Sep 2012 08:44:16 +1000 Subject: debuginfo/diz files in built images In-Reply-To: <633998898.2413580.1347023744179.JavaMail.root@redhat.com> References: <633998898.2413580.1347023744179.JavaMail.root@redhat.com> Message-ID: <504A78C0.7070800@oracle.com> On 7/09/2012 11:15 PM, Andrew Hughes wrote: >> On 6/09/2012 1:00 AM, Andrew Hughes wrote: >>>> >>>> Should .diz files be removed when packaging JDK/JRE for Linux ? >>>> >>> >>> Specifically talking about packaging, distro build systems already >>> handle >>> stripping, etc. themselves so we've been setting >>> STRIP_POLICY=no_strip. >>> However, this still creates the diz files, even though the >>> debuginfo is >>> still in the binaries. >>> >>> I have a couple of changesets to fix this, one for HotSpot& one >>> for JDK, >>> basically making diz production conditional on STRIP_POLICY not >>> being set >>> to no_strip. I'll try and upstream them, if that sounds the >>> correct thing to do. >> >> We already have ENABLE_FULL_DEBUG_SYMBOLS to control whether we >> should try to produce the debuginfo files. > > No. That implies (at least by the naming) whether or not the binaries/libraries > are built with debugging symbols, not whether or not they are stripped into separate > files. That is governed by STRIP_POLICY as far as I can tell. That is not my understanding. STRIP_POLICY is applied to the built libraries/binaries as a final step in creating the images. That is quite distinct to the creation of the debuginfo files when the libraries/binaries are actually built. This is certainly the case for hotspot and I believe also those parts of the JDK for which FDS was enabled/applied. David ----- > I have thought of turning off ENABLE_FULL_DEBUG_SYMBOLS based on the existing > Makefile logic, but this sounds like I'm turning off debug symbols which I very much > DON'T want to do. To me, the right solution seems to be to implement STRIP_POLICY=no_strip > correctly. > > We still want debugging symbols as we had before. We don't want superfluous copies > in diz files. > >> And ZIP_DEBUGINFO_FILES to >> determine >> whether we then zip it to produce the .diz file. >> >> My query is whether those files should then end up in the jre and jdk >> images that the build produces. I had thought no because the Oracle >> JDKs >> don't contain them and our RE processes have to exclude them when >> creating our bundles. Further, there is a bug in the build logic that >> causes a JRE to get diz files for libraries that aren't there. I >> thought >> a separate debuginfo.zip target might be better and leave them out of >> the images. >> >> Do other distros "package" things based on the jre and jdk images >> produced by the build or do they use the raw build artefacts >> directly? >> > > The ones I'm aware of use the images, but we don't want these diz files. > Distros have their own ways of stripping debug info and packaging it > separately that has been in place for many years before this was added > to OpenJDK. > > However, if someone was doing a local build, I presume they'd want them > wherever they'd be picked up automatically by the debugger, not hidden > away somewhere. > > To be honest, these changes have been nothing but a pain for us, changing > the type of debug info produced to STABS on some architectures and removing > needed debug info from files (until we learnt about STRIP_POLICY). The build > prior to FDS was preferable and these major build changes seem to have been > rushed through too quickly, especially to 7u. > >> Thanks, >> David >> >> >>>> 2012/9/5 David Holmes: >>>>> Dan, >>>>> >>>>> Sorry, not meaning to ruffle your feathers. >>>>> >>>>> The reason I say the diz-in-image story is unclear is because >>>>> there >>>>> are no >>>>> explicit rules that indicates that diz files should end up in a >>>>> JDK >>>>> or JRE >>>>> image. I can accept that everything should go in a full JDK >>>>> image. >>>>> But a JRE >>>>> is a JDK with a bunch of things left out and some of those things >>>>> are >>>>> libraries. But because diz files are not mentioned explicitly in >>>>> the rules >>>>> for making images we actually get the diz files for the libraries >>>>> that were >>>>> removed! They are simply copied from the build artifacts location >>>>> to the jre >>>>> image location specifically libattach.diz and libsaproc.diz. >>>>> Maybe >>>>> that was >>>>> a simple oversight. >>>>> >>>>> Additionally it is unclear to me why we have diz files for some >>>>> libraries >>>>> and not others? >>>>> >>>>> Anyway as I said this will need to be modified for the profile >>>>> work, in >>>>> consultation with all the interested parties. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 4/09/2012 11:51 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> On 9/2/12 9:37 PM, David Holmes wrote: >>>>>>> >>>>>>> Hi Dan, >>>>>>> >>>>>>> On 3/09/2012 12:47 PM, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>> On 9/2/12 7:26 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>> The build will create debuginfo/diz files as requested - >>>>>>>>> that's >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> What I'm unclear about is where those files should actually >>>>>>>>> appear in >>>>>>>>> our build artifacts, specifically the jdk/jre images that are >>>>>>>>> created. >>>>>>>>> >>>>>>>>> Internally when we create binary images RE strips all the >>>>>>>>> debuginfo/diz files out. >>>>>>>> >>>>>>>> >>>>>>>> Not quite. The RE makefiles will put debug info files into a >>>>>>>> separate debuginfo.zip file. This includes .debuginfo, .diz, >>>>>>>> .map and .pdb files. For the regular bundles, the RE makefiles >>>>>>>> will not include debug info files. Not quite the same as >>>>>>>> stripping them out. >>>>>>> >>>>>>> >>>>>>> Not trying to split hairs but if the image contains them and >>>>>>> the >>>>>>> RE >>>>>>> bundle of the image does not, then the RE process is stripping >>>>>>> them out. >>>>>> >>>>>> >>>>>> The above is implying that there is a single RE bundle and that >>>>>> hasn't >>>>>> been true for the tar-style universe for quite a long time; the >>>>>> demo >>>>>> bundle was added by around JDK8-B20 or so. For the package-style >>>>>> universe, I don't think that has ever been true. >>>>>> >>>>>> RE's makefiles take the image generated by the build and package >>>>>> up the >>>>>> various files into two or more bundles. I believe each platform >>>>>> has two >>>>>> styles of bundles. For Solaris, SVR4 style packages and tar/zip >>>>>> bundles. >>>>>> For Windows, an EXE installer and tar/zip bundles. For Linux RPM >>>>>> packages >>>>>> and tar/ZIP bundles. >>>>>> >>>>>> So I'll stick with my assertion that the RE process is placing >>>>>> debug info >>>>>> files into a separate bundle and is not stripping them out. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>> But the build itself seems to treat them in an ad-hoc manner: >>>>>>>>> >>>>>>>>> - The new build deliberately excludes debuginfo/diz files >>>>>>>>> associated >>>>>>>>> with binaries, but will include any related to libraries (via >>>>>>>>> generic >>>>>>>>> copying routine). (It's obvious from the comments related to >>>>>>>>> this that >>>>>>>>> there is some puzzlement as to this reasoning.) >>>>>>>> >>>>>>>> >>>>>>>> Sorry I haven't looked at the new build system. >>>>>>> >>>>>>> >>>>>>> It tries to emulate the old build. >>>>>>> >>>>>>>>> - The old build also tries to exclude the files associated >>>>>>>>> with >>>>>>>>> binaries, but only handles .debuginfo not .diz :( >>>>>>>> >>>>>>>> >>>>>>>> During one round in the FDS project, I included >>>>>>>> .debuginfo/.diz >>>>>>>> files >>>>>>>> right next to some of the binaries. Apparently that's not >>>>>>>> allowed >>>>>>>> without >>>>>>>> explicit permission. The contents of the "bin" directory are >>>>>>>> controlled >>>>>>>> and there are tests to verify those contents. >>>>>>>> >>>>>>>> I changed the Makefiles for the few binaries that support FDS >>>>>>>> to >>>>>>>> not >>>>>>>> install the debug info files with the binaries, but they are >>>>>>>> left in >>>>>>>> the normal build artifacts location if someone has the need to >>>>>>>> use >>>>>>>> them. Of course, I've had queries for debug info files for the >>>>>>>> binaries >>>>>>>> to be included in the debuginfo.zip bundles. I'm not planning >>>>>>>> to >>>>>>>> fight >>>>>>>> that battle. >>>>>>> >>>>>>> >>>>>>> Okay that explains the special handling for binaries. So how do >>>>>>> these >>>>>>> then get into the debuginfo.zip? Or don't they? >>>>>> >>>>>> >>>>>> They don't. They are only available via the build artifacts that >>>>>> are archived. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>> Those associated with libraries just seem to get copied if >>>>>>>>> they >>>>>>>>> happen >>>>>>>>> to be there >>>>>>>> >>>>>>>> >>>>>>>> All of the logic that copies debug info files to the image >>>>>>>> should do >>>>>>>> so if they happen to be there. Not all component support FDS >>>>>>>> now >>>>>>>> or >>>>>>>> in the future so the logic needs to adapt to what is built. >>>>>>>> >>>>>>>> >>>>>>>>> As I said this all seems very ad-hoc to me. I would expect to >>>>>>>>> see no >>>>>>>>> debuginfo/diz files in a created image by default, and have a >>>>>>>>> separate >>>>>>>>> target that would produce a tar file of all the debuginfo/diz >>>>>>>>> files >>>>>>>>> ready to overlay on an existing image. >>>>>>>> >>>>>>>> >>>>>>>> Close. The image has to have the debug info or .diz files in >>>>>>>> order for >>>>>>>> the RE makefiles to generate the debuginfo.zip files. It is >>>>>>>> the >>>>>>>> RE >>>>>>>> makefiles that handle the packaging. Just like the demos are >>>>>>>> always >>>>>>>> built and it is the RE makefiles that put them in a separate >>>>>>>> bundle. >>>>>>> >>>>>>> >>>>>>> So therein lies the problem. RE lies outside of the OpenJDK >>>>>>> build >>>>>>> system. If the RE Makefiles can copy an image they can copy the >>>>>>> debuginfo files too. I'd much rather see no debuginfo files in >>>>>>> the >>>>>>> built images (unless requested) and a distinct debuginfo >>>>>>> related >>>>>>> target (that RE could use if they choose). That would seem to >>>>>>> be >>>>>>> simpler all round. >>>>>> >>>>>> >>>>>> My understanding is that "the image" is supposed to be the >>>>>> complete >>>>>> image if every bundle is extracted. I believe that is how the >>>>>> packages >>>>>> are sanity checked to be complete. RE's Makefiles are meant to >>>>>> process >>>>>> "the image" into bundles. They aren't meant to add files of >>>>>> their >>>>>> own. >>>>>> >>>>>> If you are planning to change the meaning of "the image" or if >>>>>> you >>>>>> are planning to put files into bundles that are not in "the >>>>>> image", >>>>>> then you'll need to coordinate with RE and whoever does the >>>>>> package >>>>>> inventory testing. >>>>>> >>>>>> Also, if you change the way this works, keep in mind that some >>>>>> of >>>>>> the >>>>>> Makefiles generate their objects into a temporary directory and >>>>>> then >>>>>> copy things from that temporary directory to the image. Other >>>>>> Makefiles >>>>>> generate their objects directly into the image. For the latter, >>>>>> you'll >>>>>> have to move the debug info file(s) out of the image into some >>>>>> other >>>>>> place where it can be picked up by whatever bundling process you >>>>>> create >>>>>> to make the debuginfo.zip file. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>> Thoughts/comments? >>>>>>>>> >>>>>>>>> I have to deal with this for the SE Profile work, where we >>>>>>>>> will >>>>>>>>> not >>>>>>>>> want these files present in any of the images. >>>>>>>> >>>>>>>> >>>>>>>> It should be fine if the Embedded profile does not generate >>>>>>>> debug info >>>>>>>> files or if the Embedded profile generates debug info, but >>>>>>>> does >>>>>>>> not >>>>>>>> copy the debug info files into the image area. The RE >>>>>>>> makefiles >>>>>>>> will >>>>>>>> handle the presence or absence of debug info files. >>>>>>> >>>>>>> >>>>>>> These are not embedded profiles, these are just profiles - it >>>>>>> is >>>>>>> all >>>>>>> to be part of SE in Java 8. The build is supposed to create an >>>>>>> image >>>>>>> corresponding to each profile. I can certainly specialise the >>>>>>> handling >>>>>>> of the debuginfo files for the profiles, but it seemed to me >>>>>>> that >>>>>>> the >>>>>>> overall debuginfo-in-image story was rather unclear. >>>>>> >>>>>> >>>>>> I'm sorry you think that the debuginfo-in-image story is >>>>>> unclear. >>>>>> I thought I did a pretty good job integrating FDS into the whole >>>>>> OpenJDK build process somewhat seamlessly. I guess not. >>>>>> >>>>>> The key things to remember in all this is that debug info files >>>>>> (like the demos) have to end up in a separate bundle or bundles. >>>>>> So if you change the way this is all implemented, you still have >>>>>> to follow the separate bundle rule. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> However, the non-Embedded profile needs to continue to >>>>>>>> generate >>>>>>>> and >>>>>>>> copy debug info files for those components that already >>>>>>>> support >>>>>>>> FDS. >>>>>>>> If you change the non-Embedded logic to not copy the debug >>>>>>>> info >>>>>>>> files >>>>>>>> into the image area, the RE debuginfo.zip bundle will not be >>>>>>>> created >>>>>>>> and that will break FDS. >>>>>>> >>>>>>> >>>>>>> RE processes will have to change to handle profiles in any >>>>>>> case. >>>>>>> I >>>>>>> think they'd rather get a debuginfo.zip out of the build than >>>>>>> having >>>>>>> to create it themselves. >>>>>> >>>>>> >>>>>> Interesting and not something that I have ever heard. I got the >>>>>> impression that RE needed to have control over what was bundled >>>>>> and how it was bundled. It's kind of hard to certify/vouch for a >>>>>> process when you don't do it yourself, but that's not really my >>>>>> call. >>>>>> >>>>>> Good luck with the tweaking of the build and packaging >>>>>> processes. >>>>>> Just remember: There be dragons here! >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>> >>> >> > From weijun.wang at oracle.com Mon Sep 10 02:36:42 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2012 10:36:42 +0800 Subject: Code review request: 7142426: [macosx] cannot build if the not-yet-build jdk is in PATH In-Reply-To: <50247704.8040308@oracle.com> References: <50247704.8040308@oracle.com> Message-ID: <504D523A.4070305@oracle.com> The rungen script has not forced the use of java in $JAVA_HOME. Since I always put the to-be-built java at the top of $PATH, the script fails because that java exists but its runtime is still not fully built. Please take a look at my fix http://cr.openjdk.java.net/~weijun/7142426/webrev.00/ Also, I'm not sure where runjava is used. If it's really useless, we can remove the file, as well as the reference in jdk/make/java/jobjc/Makefile. The bug was closed by RE but I'll re-open it if you believe this is a real bug. Thanks Max From magnus.ihse.bursie at oracle.com Mon Sep 10 11:26:10 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Sep 2012 13:26:10 +0200 Subject: The future of partial builds Message-ID: <504DCE52.5080804@oracle.com> I'd like to start a discussion about the partial builds; what problem they solve and the best way to solve these problems in the new build-infra world. I'm currently investigating on how to handle the equivalence to partial builds in the new build system. My goal is to see to it that the new build system does not offer any loss of functionality when developing in the JDK -- after all, it is supposed to be a improvement, not a step backwards. However, the current way of doing partial builds is probably not suitable for the new build system. Therefore, I'd like to take a step back and get it down to a bit more of a functional spec, specifying some common scenarios and requirements on work. As I understand it, there are effectively two tricks which are used in the current build system: 1) "Partial builds". This means that you check out just a single sub-repo, not the complete forest, and build just that repo. Build artifacts that are needed from other repos are copied from an external binary blob, the "import JDK". 2) "Subdirectory builds" (not sure if this trick has any well-known name). This means that you use the fact that the makefiles are organised hierarchically, and do e.g. "cd jdk/make/java/nio ; make" to re-build just the NIO files. For this trick to work, you need to know what makefile builds the files you are working with. Trick 1) is used to avoid spending time on building other repos than the one you're interested in, and trick 2) is used to avoid spending time on building other parts of the repo, apart from the subset of the repo you're working with. Is this a somewhat correct understanding? Am I missing something? Are there some other reason apart from speeding up the build to do partial builds? How many users out there are actually using partial builds? /Magnus From magnus.ihse.bursie at oracle.com Mon Sep 10 11:43:00 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Sep 2012 13:43:00 +0200 Subject: Is the "skip boot cycle" trick still needed? Message-ID: <504DD244.50501@oracle.com> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? /Magnus From chris.hegarty at oracle.com Mon Sep 10 11:59:03 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Sep 2012 12:59:03 +0100 Subject: The future of partial builds In-Reply-To: <504DCE52.5080804@oracle.com> References: <504DCE52.5080804@oracle.com> Message-ID: <504DD607.3050702@oracle.com> On 10/09/2012 12:26, Magnus Ihse Bursie wrote: > I'd like to start a discussion about the partial builds; what problem > they solve and the best way to solve these problems in the new > build-infra world. > > I'm currently investigating on how to handle the equivalence to partial > builds in the new build system. My goal is to see to it that the new > build system does not offer any loss of functionality when developing in > the JDK -- after all, it is supposed to be a improvement, not a step > backwards. > > However, the current way of doing partial builds is probably not > suitable for the new build system. > > Therefore, I'd like to take a step back and get it down to a bit more of > a functional spec, specifying some common scenarios and requirements on > work. > > As I understand it, there are effectively two tricks which are used in > the current build system: > > 1) "Partial builds". This means that you check out just a single > sub-repo, not the complete forest, and build just that repo. Build > artifacts that are needed from other repos are copied from an external > binary blob, the "import JDK". > > 2) "Subdirectory builds" (not sure if this trick has any well-known > name). This means that you use the fact that the makefiles are organised > hierarchically, and do e.g. "cd jdk/make/java/nio ; make" to re-build > just the NIO files. For this trick to work, you need to know what > makefile builds the files you are working with. > > Trick 1) is used to avoid spending time on building other repos than the > one you're interested in, and trick 2) is used to avoid spending time on > building other parts of the repo, apart from the subset of the repo > you're working with. > > Is this a somewhat correct understanding? Am I missing something? Are > there some other reason apart from speeding up the build to do partial > builds? How many users out there are actually using partial builds? I do partial and subdirectory incremental builds. Typically of the jdk repo. The main reason is to speed up the development cycle. Subdirectory incremental builds can complete in a few seconds, and this can aide a productive development cycle. I favor partial over full builds as some of the platforms/hardware we have can take much longer to build all repos, when they are of very little interest to what I happen to be working on at the time. Yes, there are risks, I both understand and accept them. I would like to see some flavor of these supported in the new-build system. -Chris. > > /Magnus From Alan.Bateman at oracle.com Mon Sep 10 12:13:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Sep 2012 13:13:17 +0100 Subject: The future of partial builds In-Reply-To: <504DCE52.5080804@oracle.com> References: <504DCE52.5080804@oracle.com> Message-ID: <504DD95D.5060600@oracle.com> I think this is a great topic to discuss. At least within Oracle then I think the majority of people do partial builds in their local environment. When I say "partial build" then I mean they build a subset of repositories, not all of them. So folks working in the jdk repository tend to just build that repository with everything else coming from whatever import JDK they are using. Partial builds are of course very fragile and frequently people have problems because they aren't using a matching import JDK. Also periodically we have flag days, say changes that impact langtools+jdk or hotspot+jdk and these usually cause a bit of disruption until the changes get into a promoted build and into the import JDK that people use. As to why people do partial builds then it's probably a mix of issues including disk space, time to do the first build, and of course it's just the way that we've always done it. Another thing is that I think most people (at least in Oracle) don't build images either, they run + debug with the build output in $OUTPUTDIR so no rt.jar, etc. When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. -Alan. From magnus.ihse.bursie at oracle.com Mon Sep 10 14:00:32 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Sep 2012 16:00:32 +0200 Subject: The future of partial builds In-Reply-To: <504DD95D.5060600@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> Message-ID: <504DF280.9010505@oracle.com> On 2012-09-10 14:13, Alan Bateman wrote: > When you say "sub-directory builds" then I think you mean incremental > builds, or "poor-man increment builds" as I call it. I think the > majority of people working in the jdk repository, at least in Oracle, > do this because they know the area and know which make files that > re-build the files that they have changed. Incremental builds are > generally not very reliable but seem to be "good enough" for most > people needs, at least those that aren't doing significant > refactoring. The main motive of course is to be able to re-build in a > few seconds and the #1 goal of any new build system has to be fast > incremental builds. In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). These two can of course be combined. I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. /Magnus From magnus.ihse.bursie at oracle.com Mon Sep 10 14:20:01 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Sep 2012 16:20:01 +0200 Subject: The future of partial builds In-Reply-To: <504DD95D.5060600@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> Message-ID: <504DF711.8080802@oracle.com> On 2012-09-10 14:13, Alan Bateman wrote: > > I think this is a great topic to discuss. > > At least within Oracle then I think the majority of people do partial > builds in their local environment. When I say "partial build" then I > mean they build a subset of repositories, not all of them. So folks > working in the jdk repository tend to just build that repository with > everything else coming from whatever import JDK they are using. > Partial builds are of course very fragile and frequently people have > problems because they aren't using a matching import JDK. Also > periodically we have flag days, say changes that impact langtools+jdk > or hotspot+jdk and these usually cause a bit of disruption until the > changes get into a promoted build and into the import JDK that people > use. As to why people do partial builds then it's probably a mix of > issues including disk space, time to do the first build, and of course > it's just the way that we've always done it. In build-infra, there is currently a "somewhat partial build" feature that is implemented like this: 1) You check out a "master forest", containing all repos. You only need to do this checkout once, and you are not required to pull/update it (unless you want to keep up with changes -- like on a flag day). 2) For subsequent work, you can clone just a single repo (let's call it "my_hotspot"), and doing some configure magic (currently a bit complicated, but that can be rewritten to be simpler) which will point to the "master forest" but replace the hotspot repo in the master forest with "my_hotspot".. 3) The first time you build "my_hotspot", it will rebuild the whole forest (but with hotspot replaced with my_hotspot). However, if you never pull/update the master forest, this will be a one-time event. Subsequent builds will see that nothing has changed in the master forest, and only changes in my_hotspot will be recompiled. The pros with this solution is: 1) help with flag days -- just pull/update the master forest and rebuild. 2) you can always build the complete product. 3) you save some disk space by only cloning the complete forest once. However: 1) you will still need disk space for build output for the complete forest, for every single repo. 2) you will still need to recompile the whole forest for each new single repo you clone. Do you think this will make the solution not good enough? I think it is possible and not too hard to change this solution slightly, so you would only need to compile the master forest once, and then new single repos can use that build output as well as using the source code from the master forest. Though proper dependency checking might be harder, and there will be semantic issues about the meaning of things like "make clean" that can be surprising. Is this something you think is worth pursuing? To completely eliminate compiling the whole product at least once seems much harder. I can't really see a good way of using "import JDKs" the way they've been used in the old build system. I imagine one possibility is to prepare a tar ball, including a complete cloned forest (for a certain point in time) and a build directory with build artifacts corresponding to that source code and your platform(s) of choice, and have people download that as starting point. It seems like a lot of work, though. Do you think that is needed to get the new build system accepted? /Magnus From weijun.wang at oracle.com Mon Sep 10 14:48:02 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2012 22:48:02 +0800 Subject: The future of partial builds In-Reply-To: <504DF711.8080802@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> Message-ID: <504DFDA2.4060007@oracle.com> It's not uncommon that I just clone the repo(s), do a quick build, run several tests and abandon it, for example, if I want to try my code changes on a different platform (from my daily work machine). Therefore I find the jdk-only build very useful. -Max On 09/10/2012 10:20 PM, Magnus Ihse Bursie wrote: > On 2012-09-10 14:13, Alan Bateman wrote: >> >> I think this is a great topic to discuss. >> >> At least within Oracle then I think the majority of people do partial >> builds in their local environment. When I say "partial build" then I >> mean they build a subset of repositories, not all of them. So folks >> working in the jdk repository tend to just build that repository with >> everything else coming from whatever import JDK they are using. >> Partial builds are of course very fragile and frequently people have >> problems because they aren't using a matching import JDK. Also >> periodically we have flag days, say changes that impact langtools+jdk >> or hotspot+jdk and these usually cause a bit of disruption until the >> changes get into a promoted build and into the import JDK that people >> use. As to why people do partial builds then it's probably a mix of >> issues including disk space, time to do the first build, and of course >> it's just the way that we've always done it. > > > In build-infra, there is currently a "somewhat partial build" feature > that is implemented like this: > 1) You check out a "master forest", containing all repos. You only need > to do this checkout once, and you are not required to pull/update it > (unless you want to keep up with changes -- like on a flag day). > > 2) For subsequent work, you can clone just a single repo (let's call it > "my_hotspot"), and doing some configure magic (currently a bit > complicated, but that can be rewritten to be simpler) which will point > to the "master forest" but replace the hotspot repo in the master forest > with "my_hotspot".. > > 3) The first time you build "my_hotspot", it will rebuild the whole > forest (but with hotspot replaced with my_hotspot). However, if you > never pull/update the master forest, this will be a one-time event. > Subsequent builds will see that nothing has changed in the master > forest, and only changes in my_hotspot will be recompiled. > > The pros with this solution is: > 1) help with flag days -- just pull/update the master forest and rebuild. > 2) you can always build the complete product. > 3) you save some disk space by only cloning the complete forest once. > > However: > 1) you will still need disk space for build output for the complete > forest, for every single repo. > 2) you will still need to recompile the whole forest for each new single > repo you clone. > > Do you think this will make the solution not good enough? > > I think it is possible and not too hard to change this solution > slightly, so you would only need to compile the master forest once, and > then new single repos can use that build output as well as using the > source code from the master forest. Though proper dependency checking > might be harder, and there will be semantic issues about the meaning of > things like "make clean" that can be surprising. Is this something you > think is worth pursuing? > > To completely eliminate compiling the whole product at least once seems > much harder. I can't really see a good way of using "import JDKs" the > way they've been used in the old build system. I imagine one possibility > is to prepare a tar ball, including a complete cloned forest (for a > certain point in time) and a build directory with build artifacts > corresponding to that source code and your platform(s) of choice, and > have people download that as starting point. It seems like a lot of > work, though. Do you think that is needed to get the new build system > accepted? > > /Magnus From weijun.wang at oracle.com Mon Sep 10 14:52:19 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2012 22:52:19 +0800 Subject: The future of partial builds In-Reply-To: <504DFDA2.4060007@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> <504DFDA2.4060007@oracle.com> Message-ID: <504DFEA3.6060002@oracle.com> Sorry I was not clear, by "clone the repo(s)", I mean either only the jdk repo, or plus the jdk/*/closed ones. I almost never clone other repos (langtools, hotspot, ...). -Max On 09/10/2012 10:48 PM, Weijun Wang wrote: > It's not uncommon that I just clone the repo(s), do a quick build, run > several tests and abandon it, for example, if I want to try my code > changes on a different platform (from my daily work machine). Therefore > I find the jdk-only build very useful. > > -Max > > On 09/10/2012 10:20 PM, Magnus Ihse Bursie wrote: >> On 2012-09-10 14:13, Alan Bateman wrote: >>> >>> I think this is a great topic to discuss. >>> >>> At least within Oracle then I think the majority of people do partial >>> builds in their local environment. When I say "partial build" then I >>> mean they build a subset of repositories, not all of them. So folks >>> working in the jdk repository tend to just build that repository with >>> everything else coming from whatever import JDK they are using. >>> Partial builds are of course very fragile and frequently people have >>> problems because they aren't using a matching import JDK. Also >>> periodically we have flag days, say changes that impact langtools+jdk >>> or hotspot+jdk and these usually cause a bit of disruption until the >>> changes get into a promoted build and into the import JDK that people >>> use. As to why people do partial builds then it's probably a mix of >>> issues including disk space, time to do the first build, and of course >>> it's just the way that we've always done it. >> >> >> In build-infra, there is currently a "somewhat partial build" feature >> that is implemented like this: >> 1) You check out a "master forest", containing all repos. You only need >> to do this checkout once, and you are not required to pull/update it >> (unless you want to keep up with changes -- like on a flag day). >> >> 2) For subsequent work, you can clone just a single repo (let's call it >> "my_hotspot"), and doing some configure magic (currently a bit >> complicated, but that can be rewritten to be simpler) which will point >> to the "master forest" but replace the hotspot repo in the master forest >> with "my_hotspot".. >> >> 3) The first time you build "my_hotspot", it will rebuild the whole >> forest (but with hotspot replaced with my_hotspot). However, if you >> never pull/update the master forest, this will be a one-time event. >> Subsequent builds will see that nothing has changed in the master >> forest, and only changes in my_hotspot will be recompiled. >> >> The pros with this solution is: >> 1) help with flag days -- just pull/update the master forest and rebuild. >> 2) you can always build the complete product. >> 3) you save some disk space by only cloning the complete forest once. >> >> However: >> 1) you will still need disk space for build output for the complete >> forest, for every single repo. >> 2) you will still need to recompile the whole forest for each new single >> repo you clone. >> >> Do you think this will make the solution not good enough? >> >> I think it is possible and not too hard to change this solution >> slightly, so you would only need to compile the master forest once, and >> then new single repos can use that build output as well as using the >> source code from the master forest. Though proper dependency checking >> might be harder, and there will be semantic issues about the meaning of >> things like "make clean" that can be surprising. Is this something you >> think is worth pursuing? >> >> To completely eliminate compiling the whole product at least once seems >> much harder. I can't really see a good way of using "import JDKs" the >> way they've been used in the old build system. I imagine one possibility >> is to prepare a tar ball, including a complete cloned forest (for a >> certain point in time) and a build directory with build artifacts >> corresponding to that source code and your platform(s) of choice, and >> have people download that as starting point. It seems like a lot of >> work, though. Do you think that is needed to get the new build system >> accepted? >> >> /Magnus From jonathan.gibbons at oracle.com Mon Sep 10 15:09:13 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 08:09:13 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504DD244.50501@oracle.com> References: <504DD244.50501@oracle.com> Message-ID: <504E0299.6070709@oracle.com> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. -- Jon On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: > In the old system, one can set the oddly named SKIP_BOOT_CYCLE to > false (which, internally, sets the slightly more clearly named > DO_BOOT_CYCLE=true). This causes the product to build twice, the > second time using the first build result as the boot jdk. > > This has been used, as I understand it, as a "poor mans integration > test" -- if the build output could perform the feat of compiling the > JDK, then it can't be that broken. > > This kind of behaviour is not implemented in the new build system, and > I propose that it should not be. The cost for implementing this is > that all build system for all builds will be more complicated, but the > gains are more unclear. To me, this is just a test, and it's a bit odd > to have that as part of the build system. I also believe are now far > better tests using jtreg, and if they are lacking -- then the tests > should be improved, not the build system changed. > > Is there anyone who would be protesting if the SKIP_BOOT_CYCLE > functionality would be dropped in the new build system? > > /Magnus From jonathan.gibbons at oracle.com Mon Sep 10 15:15:54 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 08:15:54 -0700 Subject: The future of partial builds In-Reply-To: <504DCE52.5080804@oracle.com> References: <504DCE52.5080804@oracle.com> Message-ID: <504E042A.60208@oracle.com> Magnus, I'm guessing that most developers use partial builds. In the langtools/ world, we only build the langtools component, and even then, sometimes only javac. We can then use the result to run our tests. We do not want to -- and would strongly resist having to -- rebuild all of JDK every time we time we edit javac. In the jdk/ world, developers go as far as building build/classes, and avoid the downstream steps of building rt.jar and ct.sym. -- Jon On 09/10/2012 04:26 AM, Magnus Ihse Bursie wrote: > I'd like to start a discussion about the partial builds; what problem > they solve and the best way to solve these problems in the new > build-infra world. > > I'm currently investigating on how to handle the equivalence to > partial builds in the new build system. My goal is to see to it that > the new build system does not offer any loss of functionality when > developing in the JDK -- after all, it is supposed to be a > improvement, not a step backwards. > > However, the current way of doing partial builds is probably not > suitable for the new build system. > > Therefore, I'd like to take a step back and get it down to a bit more > of a functional spec, specifying some common scenarios and > requirements on work. > > As I understand it, there are effectively two tricks which are used in > the current build system: > > 1) "Partial builds". This means that you check out just a single > sub-repo, not the complete forest, and build just that repo. Build > artifacts that are needed from other repos are copied from an external > binary blob, the "import JDK". > > 2) "Subdirectory builds" (not sure if this trick has any well-known > name). This means that you use the fact that the makefiles are > organised hierarchically, and do e.g. "cd jdk/make/java/nio ; make" to > re-build just the NIO files. For this trick to work, you need to know > what makefile builds the files you are working with. > > Trick 1) is used to avoid spending time on building other repos than > the one you're interested in, and trick 2) is used to avoid spending > time on building other parts of the repo, apart from the subset of the > repo you're working with. > > Is this a somewhat correct understanding? Am I missing something? Are > there some other reason apart from speeding up the build to do partial > builds? How many users out there are actually using partial builds? > > /Magnus From jonathan.gibbons at oracle.com Mon Sep 10 15:36:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 08:36:05 -0700 Subject: The future of partial builds In-Reply-To: <504DF711.8080802@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> Message-ID: <504E08E5.8090605@oracle.com> Having to compile hotspot every time one creates a new repo seems like a very significant step backwards. I can clone and build langtools in 45 seconds. > $ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd > langtools ; lt.ant build-all-classes ) > destination directory: langtools ... > BUILD SUCCESSFUL > Total time: 23 seconds > > real 0m45.313s > user 0m23.909s > sys 0m12.461s -- Jon On 09/10/2012 07:20 AM, Magnus Ihse Bursie wrote: > On 2012-09-10 14:13, Alan Bateman wrote: >> >> I think this is a great topic to discuss. >> >> At least within Oracle then I think the majority of people do partial >> builds in their local environment. When I say "partial build" then I >> mean they build a subset of repositories, not all of them. So folks >> working in the jdk repository tend to just build that repository with >> everything else coming from whatever import JDK they are using. >> Partial builds are of course very fragile and frequently people have >> problems because they aren't using a matching import JDK. Also >> periodically we have flag days, say changes that impact langtools+jdk >> or hotspot+jdk and these usually cause a bit of disruption until the >> changes get into a promoted build and into the import JDK that people >> use. As to why people do partial builds then it's probably a mix of >> issues including disk space, time to do the first build, and of >> course it's just the way that we've always done it. > > > In build-infra, there is currently a "somewhat partial build" feature > that is implemented like this: > 1) You check out a "master forest", containing all repos. You only > need to do this checkout once, and you are not required to pull/update > it (unless you want to keep up with changes -- like on a flag day). > > 2) For subsequent work, you can clone just a single repo (let's call > it "my_hotspot"), and doing some configure magic (currently a bit > complicated, but that can be rewritten to be simpler) which will point > to the "master forest" but replace the hotspot repo in the master > forest with "my_hotspot".. > > 3) The first time you build "my_hotspot", it will rebuild the whole > forest (but with hotspot replaced with my_hotspot). However, if you > never pull/update the master forest, this will be a one-time event. > Subsequent builds will see that nothing has changed in the master > forest, and only changes in my_hotspot will be recompiled. > > The pros with this solution is: > 1) help with flag days -- just pull/update the master forest and rebuild. > 2) you can always build the complete product. > 3) you save some disk space by only cloning the complete forest once. > > However: > 1) you will still need disk space for build output for the complete > forest, for every single repo. > 2) you will still need to recompile the whole forest for each new > single repo you clone. > > Do you think this will make the solution not good enough? > > I think it is possible and not too hard to change this solution > slightly, so you would only need to compile the master forest once, > and then new single repos can use that build output as well as using > the source code from the master forest. Though proper dependency > checking might be harder, and there will be semantic issues about the > meaning of things like "make clean" that can be surprising. Is this > something you think is worth pursuing? > > To completely eliminate compiling the whole product at least once > seems much harder. I can't really see a good way of using "import > JDKs" the way they've been used in the old build system. I imagine one > possibility is to prepare a tar ball, including a complete cloned > forest (for a certain point in time) and a build directory with build > artifacts corresponding to that source code and your platform(s) of > choice, and have people download that as starting point. It seems like > a lot of work, though. Do you think that is needed to get the new > build system accepted? > > /Magnus From kumar.x.srinivasan at oracle.com Mon Sep 10 16:25:43 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 10 Sep 2012 09:25:43 -0700 Subject: The future of partial builds In-Reply-To: <504E08E5.8090605@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> <504E08E5.8090605@oracle.com> Message-ID: <504E1487.602@oracle.com> I focus on pack200, java launcher and javac, and for the launcher I am sometimes forced to use windows as the development platform. Building incrementally the launcher, saves me a lot of time. This is how it works: 1. make launcher specific files and test with ALT_OUTPUTDIR. 2. build all the tool launchers then build the sdk images and test. The second is much much longer but I have to grin and bear it. The idea of no incremental builds will cause a huge problem on windows for me. Thanks Kumar > Having to compile hotspot every time one creates a new repo seems like > a very significant step backwards. I can clone and build langtools in > 45 seconds. > >> $ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd >> langtools ; lt.ant build-all-classes ) >> destination directory: langtools > ... >> BUILD SUCCESSFUL >> Total time: 23 seconds >> >> real 0m45.313s >> user 0m23.909s >> sys 0m12.461s > > -- Jon > > > > On 09/10/2012 07:20 AM, Magnus Ihse Bursie wrote: >> On 2012-09-10 14:13, Alan Bateman wrote: >>> >>> I think this is a great topic to discuss. >>> >>> At least within Oracle then I think the majority of people do >>> partial builds in their local environment. When I say "partial >>> build" then I mean they build a subset of repositories, not all of >>> them. So folks working in the jdk repository tend to just build that >>> repository with everything else coming from whatever import JDK they >>> are using. Partial builds are of course very fragile and frequently >>> people have problems because they aren't using a matching import >>> JDK. Also periodically we have flag days, say changes that impact >>> langtools+jdk or hotspot+jdk and these usually cause a bit of >>> disruption until the changes get into a promoted build and into the >>> import JDK that people use. As to why people do partial builds then >>> it's probably a mix of issues including disk space, time to do the >>> first build, and of course it's just the way that we've always done it. >> >> >> In build-infra, there is currently a "somewhat partial build" >> feature that is implemented like this: >> 1) You check out a "master forest", containing all repos. You only >> need to do this checkout once, and you are not required to >> pull/update it (unless you want to keep up with changes -- like on a >> flag day). >> >> 2) For subsequent work, you can clone just a single repo (let's call >> it "my_hotspot"), and doing some configure magic (currently a bit >> complicated, but that can be rewritten to be simpler) which will >> point to the "master forest" but replace the hotspot repo in the >> master forest with "my_hotspot".. >> >> 3) The first time you build "my_hotspot", it will rebuild the whole >> forest (but with hotspot replaced with my_hotspot). However, if you >> never pull/update the master forest, this will be a one-time event. >> Subsequent builds will see that nothing has changed in the master >> forest, and only changes in my_hotspot will be recompiled. >> >> The pros with this solution is: >> 1) help with flag days -- just pull/update the master forest and >> rebuild. >> 2) you can always build the complete product. >> 3) you save some disk space by only cloning the complete forest once. >> >> However: >> 1) you will still need disk space for build output for the complete >> forest, for every single repo. >> 2) you will still need to recompile the whole forest for each new >> single repo you clone. >> >> Do you think this will make the solution not good enough? >> >> I think it is possible and not too hard to change this solution >> slightly, so you would only need to compile the master forest once, >> and then new single repos can use that build output as well as using >> the source code from the master forest. Though proper dependency >> checking might be harder, and there will be semantic issues about the >> meaning of things like "make clean" that can be surprising. Is this >> something you think is worth pursuing? >> >> To completely eliminate compiling the whole product at least once >> seems much harder. I can't really see a good way of using "import >> JDKs" the way they've been used in the old build system. I imagine >> one possibility is to prepare a tar ball, including a complete cloned >> forest (for a certain point in time) and a build directory with build >> artifacts corresponding to that source code and your platform(s) of >> choice, and have people download that as starting point. It seems >> like a lot of work, though. Do you think that is needed to get the >> new build system accepted? >> >> /Magnus > > > From philip.race at oracle.com Mon Sep 10 18:19:24 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 10 Sep 2012 11:19:24 -0700 Subject: The future of partial builds In-Reply-To: <504E08E5.8090605@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> <504E08E5.8090605@oracle.com> Message-ID: <504E2F2C.5090403@oracle.com> A huge step backwards. I don't want to have to clone or keep hotspot up to date and I prefer using the 'RE' builds of hotspot to any I would create. I have never found this fragile. Its worked well for over 10 years ... -phil. On 9/10/2012 8:36 AM, Jonathan Gibbons wrote: > Having to compile hotspot every time one creates a new repo seems like > a very significant step backwards. I can clone and build langtools in > 45 seconds. > >> $ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd >> langtools ; lt.ant build-all-classes ) >> destination directory: langtools > ... >> BUILD SUCCESSFUL >> Total time: 23 seconds >> >> real 0m45.313s >> user 0m23.909s >> sys 0m12.461s > > -- Jon > > > > On 09/10/2012 07:20 AM, Magnus Ihse Bursie wrote: >> On 2012-09-10 14:13, Alan Bateman wrote: >>> >>> I think this is a great topic to discuss. >>> >>> At least within Oracle then I think the majority of people do >>> partial builds in their local environment. When I say "partial >>> build" then I mean they build a subset of repositories, not all of >>> them. So folks working in the jdk repository tend to just build that >>> repository with everything else coming from whatever import JDK they >>> are using. Partial builds are of course very fragile and frequently >>> people have problems because they aren't using a matching import >>> JDK. Also periodically we have flag days, say changes that impact >>> langtools+jdk or hotspot+jdk and these usually cause a bit of >>> disruption until the changes get into a promoted build and into the >>> import JDK that people use. As to why people do partial builds then >>> it's probably a mix of issues including disk space, time to do the >>> first build, and of course it's just the way that we've always done it. >> >> >> In build-infra, there is currently a "somewhat partial build" >> feature that is implemented like this: >> 1) You check out a "master forest", containing all repos. You only >> need to do this checkout once, and you are not required to >> pull/update it (unless you want to keep up with changes -- like on a >> flag day). >> >> 2) For subsequent work, you can clone just a single repo (let's call >> it "my_hotspot"), and doing some configure magic (currently a bit >> complicated, but that can be rewritten to be simpler) which will >> point to the "master forest" but replace the hotspot repo in the >> master forest with "my_hotspot".. >> >> 3) The first time you build "my_hotspot", it will rebuild the whole >> forest (but with hotspot replaced with my_hotspot). However, if you >> never pull/update the master forest, this will be a one-time event. >> Subsequent builds will see that nothing has changed in the master >> forest, and only changes in my_hotspot will be recompiled. >> >> The pros with this solution is: >> 1) help with flag days -- just pull/update the master forest and >> rebuild. >> 2) you can always build the complete product. >> 3) you save some disk space by only cloning the complete forest once. >> >> However: >> 1) you will still need disk space for build output for the complete >> forest, for every single repo. >> 2) you will still need to recompile the whole forest for each new >> single repo you clone. >> >> Do you think this will make the solution not good enough? >> >> I think it is possible and not too hard to change this solution >> slightly, so you would only need to compile the master forest once, >> and then new single repos can use that build output as well as using >> the source code from the master forest. Though proper dependency >> checking might be harder, and there will be semantic issues about the >> meaning of things like "make clean" that can be surprising. Is this >> something you think is worth pursuing? >> >> To completely eliminate compiling the whole product at least once >> seems much harder. I can't really see a good way of using "import >> JDKs" the way they've been used in the old build system. I imagine >> one possibility is to prepare a tar ball, including a complete cloned >> forest (for a certain point in time) and a build directory with build >> artifacts corresponding to that source code and your platform(s) of >> choice, and have people download that as starting point. It seems >> like a lot of work, though. Do you think that is needed to get the >> new build system accepted? >> >> /Magnus > > > From mandy.chung at oracle.com Mon Sep 10 18:48:44 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Sep 2012 11:48:44 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E0299.6070709@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> Message-ID: <504E360C.2060600@oracle.com> I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy test case (building JDK with the newly built JDK) to catch issues early on. Such functionality makes it easy and convenient to do the skip boot cycle build via JPRT or our automated nightly builds. FWIW - skip boot cycle build has been especially useful for Jigsaw as there are significant changes to the layout as well as the runtime and we do that in our nightly builds. Mandy On 9/10/2012 8:09 AM, Jonathan Gibbons wrote: > Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be > concerned about its removal. > > Is it really that hard to provide the same functionality in the new > build system? Surely, it should just be a matter of a couple of > recursive makes at the top-level, the first into an "interim" build > dir and the second using the result of the first as its ALT_BOOTDIR. > > -- Jon > > > On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to >> false (which, internally, sets the slightly more clearly named >> DO_BOOT_CYCLE=true). This causes the product to build twice, the >> second time using the first build result as the boot jdk. >> >> This has been used, as I understand it, as a "poor mans integration >> test" -- if the build output could perform the feat of compiling the >> JDK, then it can't be that broken. >> >> This kind of behaviour is not implemented in the new build system, >> and I propose that it should not be. The cost for implementing this >> is that all build system for all builds will be more complicated, but >> the gains are more unclear. To me, this is just a test, and it's a >> bit odd to have that as part of the build system. I also believe are >> now far better tests using jtreg, and if they are lacking -- then the >> tests should be improved, not the build system changed. >> >> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE >> functionality would be dropped in the new build system? >> >> /Magnus > From igor.nekrestyanov at oracle.com Mon Sep 10 19:05:04 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 10 Sep 2012 12:05:04 -0700 Subject: The future of partial builds In-Reply-To: <504E2F2C.5090403@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> <504E08E5.8090605@oracle.com> <504E2F2C.5090403@oracle.com> Message-ID: <504E39E0.1030103@oracle.com> Can not agree more. For repos further in the food chain (such as deploy, etc) this is even worse. Often we do not really need to build jdk repo. We doing (quick) partial builds in Hudson to run tests continuously. We also often need to build on "test" systems where JDK build env is not set. Getting all of JDK build env there will slow things down. Usually we only upload what is needed to build specific deploy repo. -igor On 9/10/12 11:19 AM, Phil Race wrote: > A huge step backwards. > I don't want to have to clone or keep hotspot up to date > and I prefer using the 'RE' builds of hotspot to any I would create. > I have never found this fragile. Its worked well for over 10 years ... > > -phil. > > On 9/10/2012 8:36 AM, Jonathan Gibbons wrote: >> Having to compile hotspot every time one creates a new repo seems >> like a very significant step backwards. I can clone and build >> langtools in 45 seconds. >> >>> $ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd >>> langtools ; lt.ant build-all-classes ) >>> destination directory: langtools >> ... >>> BUILD SUCCESSFUL >>> Total time: 23 seconds >>> >>> real 0m45.313s >>> user 0m23.909s >>> sys 0m12.461s >> >> -- Jon >> >> >> >> On 09/10/2012 07:20 AM, Magnus Ihse Bursie wrote: >>> On 2012-09-10 14:13, Alan Bateman wrote: >>>> >>>> I think this is a great topic to discuss. >>>> >>>> At least within Oracle then I think the majority of people do >>>> partial builds in their local environment. When I say "partial >>>> build" then I mean they build a subset of repositories, not all of >>>> them. So folks working in the jdk repository tend to just build >>>> that repository with everything else coming from whatever import >>>> JDK they are using. Partial builds are of course very fragile and >>>> frequently people have problems because they aren't using a >>>> matching import JDK. Also periodically we have flag days, say >>>> changes that impact langtools+jdk or hotspot+jdk and these usually >>>> cause a bit of disruption until the changes get into a promoted >>>> build and into the import JDK that people use. As to why people do >>>> partial builds then it's probably a mix of issues including disk >>>> space, time to do the first build, and of course it's just the way >>>> that we've always done it. >>> >>> >>> In build-infra, there is currently a "somewhat partial build" >>> feature that is implemented like this: >>> 1) You check out a "master forest", containing all repos. You only >>> need to do this checkout once, and you are not required to >>> pull/update it (unless you want to keep up with changes -- like on a >>> flag day). >>> >>> 2) For subsequent work, you can clone just a single repo (let's call >>> it "my_hotspot"), and doing some configure magic (currently a bit >>> complicated, but that can be rewritten to be simpler) which will >>> point to the "master forest" but replace the hotspot repo in the >>> master forest with "my_hotspot".. >>> >>> 3) The first time you build "my_hotspot", it will rebuild the whole >>> forest (but with hotspot replaced with my_hotspot). However, if you >>> never pull/update the master forest, this will be a one-time event. >>> Subsequent builds will see that nothing has changed in the master >>> forest, and only changes in my_hotspot will be recompiled. >>> >>> The pros with this solution is: >>> 1) help with flag days -- just pull/update the master forest and >>> rebuild. >>> 2) you can always build the complete product. >>> 3) you save some disk space by only cloning the complete forest once. >>> >>> However: >>> 1) you will still need disk space for build output for the complete >>> forest, for every single repo. >>> 2) you will still need to recompile the whole forest for each new >>> single repo you clone. >>> >>> Do you think this will make the solution not good enough? >>> >>> I think it is possible and not too hard to change this solution >>> slightly, so you would only need to compile the master forest once, >>> and then new single repos can use that build output as well as using >>> the source code from the master forest. Though proper dependency >>> checking might be harder, and there will be semantic issues about >>> the meaning of things like "make clean" that can be surprising. Is >>> this something you think is worth pursuing? >>> >>> To completely eliminate compiling the whole product at least once >>> seems much harder. I can't really see a good way of using "import >>> JDKs" the way they've been used in the old build system. I imagine >>> one possibility is to prepare a tar ball, including a complete >>> cloned forest (for a certain point in time) and a build directory >>> with build artifacts corresponding to that source code and your >>> platform(s) of choice, and have people download that as starting >>> point. It seems like a lot of work, though. Do you think that is >>> needed to get the new build system accepted? >>> >>> /Magnus >> >> >> > From david.katleman at oracle.com Mon Sep 10 19:24:41 2012 From: david.katleman at oracle.com (David Katleman) Date: Mon, 10 Sep 2012 12:24:41 -0700 Subject: The future of partial builds In-Reply-To: <504DCE52.5080804@oracle.com> References: <504DCE52.5080804@oracle.com> Message-ID: <504E3E79.8060005@oracle.com> > Is this a somewhat correct understanding? Am I missing something? Are > there some other reason apart from speeding up the build to do partial > builds? How many users out there are actually using partial builds? I believe, as you've seen in the replies, the question is better rephrased as "How many users out there don't use partial builds?" RE builds are full builds, as are integrator builds for PIT. A full build by a developer is somewhat rare, mainly for environment changes (compilers, OS) or fixes that span repos, such as build infrastructure work. Thanks Dave On 9/10/2012 4:26 AM, Magnus Ihse Bursie wrote: > I'd like to start a discussion about the partial builds; what problem > they solve and the best way to solve these problems in the new > build-infra world. > > I'm currently investigating on how to handle the equivalence to > partial builds in the new build system. My goal is to see to it that > the new build system does not offer any loss of functionality when > developing in the JDK -- after all, it is supposed to be a > improvement, not a step backwards. > > However, the current way of doing partial builds is probably not > suitable for the new build system. > > Therefore, I'd like to take a step back and get it down to a bit more > of a functional spec, specifying some common scenarios and > requirements on work. > > As I understand it, there are effectively two tricks which are used in > the current build system: > > 1) "Partial builds". This means that you check out just a single > sub-repo, not the complete forest, and build just that repo. Build > artifacts that are needed from other repos are copied from an external > binary blob, the "import JDK". > > 2) "Subdirectory builds" (not sure if this trick has any well-known > name). This means that you use the fact that the makefiles are > organised hierarchically, and do e.g. "cd jdk/make/java/nio ; make" to > re-build just the NIO files. For this trick to work, you need to know > what makefile builds the files you are working with. > > Trick 1) is used to avoid spending time on building other repos than > the one you're interested in, and trick 2) is used to avoid spending > time on building other parts of the repo, apart from the subset of the > repo you're working with. > > Is this a somewhat correct understanding? Am I missing something? Are > there some other reason apart from speeding up the build to do partial > builds? How many users out there are actually using partial builds? > > /Magnus From ahughes at redhat.com Mon Sep 10 19:42:55 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 10 Sep 2012 15:42:55 -0400 (EDT) Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E360C.2060600@oracle.com> Message-ID: <1470040061.3251525.1347306175281.JavaMail.root@redhat.com> ----- Original Message ----- > I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy > test case (building JDK with the newly built JDK) to catch issues > early > on. Such functionality makes it easy and convenient to do the skip > boot cycle build via JPRT or our automated nightly builds. FWIW - > skip > boot cycle build has been especially useful for Jigsaw as there are > significant changes to the layout as well as the runtime and we do > that > in our nightly builds. > > Mandy > > On 9/10/2012 8:09 AM, Jonathan Gibbons wrote: > > Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would > > be > > concerned about its removal. > > > > Is it really that hard to provide the same functionality in the new > > build system? Surely, it should just be a matter of a couple of > > recursive makes at the top-level, the first into an "interim" build > > dir and the second using the result of the first as its > > ALT_BOOTDIR. > > > > -- Jon > > > > > > On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: > >> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to > >> false (which, internally, sets the slightly more clearly named > >> DO_BOOT_CYCLE=true). This causes the product to build twice, the > >> second time using the first build result as the boot jdk. > >> > >> This has been used, as I understand it, as a "poor mans > >> integration > >> test" -- if the build output could perform the feat of compiling > >> the > >> JDK, then it can't be that broken. > >> > >> This kind of behaviour is not implemented in the new build system, > >> and I propose that it should not be. The cost for implementing > >> this > >> is that all build system for all builds will be more complicated, > >> but > >> the gains are more unclear. To me, this is just a test, and it's a > >> bit odd to have that as part of the build system. I also believe > >> are > >> now far better tests using jtreg, and if they are lacking -- then > >> the > >> tests should be improved, not the build system changed. > >> > >> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE > >> functionality would be dropped in the new build system? > >> > >> /Magnus > > > I'd like to see it kept too. Part of IcedTea (which works as a build system on top of OpenJDK) does the same thing; in fact, it's the default and I wasn't aware that OpenJDK had the same option until it came up in conversation with Kelly. Personally, I don't push an update to IcedTea unless a full bootstrap has been completed. I've seen it point out too many issues not to do so. It's very possible that the build finished but the VM won't even fire up. This would be caught at build-time if a boot cycle was done. Yes, jtreg tests would catch this too, but they take more time & configuration than a simple second build, plus there are tests that are known to fail and areas that aren't tested. The build hammers a JDK pretty well, as we've found from getting gcj to do it! One particular issue is with the way the OpenJDK build is structured. I don't know if this has changed in the new build but I doubt it. Because langtools, corba, jaxp, jaxws & hotspot are built before the jdk on a full build, they inherently build against the bootstrap VMs version of classes they depend on (including some internal com.sun.* & sun.* classes). So the second build will build these against the latest versions rather than the bootstrap versions, effectively giving a free test that the JDK can still build itself as well. We spotted this in working on IcedTea, as obviously the internal classes aren't present on non-Sun/Oracle JDKs so the build had to patched to use the JDK source code. We also recently hit this problem in the opposite direction, where 7u has obviously been bootstrapped with itself, but not 6: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-September/004262.html So the best builds, IMO, are ones that bootstrap with JDK n-1 (6 with 7, 7 with 8), then do a second cycle with themselves. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kumar.x.srinivasan at oracle.com Mon Sep 10 21:00:34 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 10 Sep 2012 14:00:34 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E360C.2060600@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <504E360C.2060600@oracle.com> Message-ID: <504E54F2.3070701@oracle.com> also it is being used by the jdk tl/etc integrator to build PIT bundles. I agree with the others it has been very useful in the past. Kumar > I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy > test case (building JDK with the newly built JDK) to catch issues > early on. Such functionality makes it easy and convenient to do the > skip boot cycle build via JPRT or our automated nightly builds. FWIW > - skip boot cycle build has been especially useful for Jigsaw as there > are significant changes to the layout as well as the runtime and we do > that in our nightly builds. > > Mandy > > On 9/10/2012 8:09 AM, Jonathan Gibbons wrote: >> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would >> be concerned about its removal. >> >> Is it really that hard to provide the same functionality in the new >> build system? Surely, it should just be a matter of a couple of >> recursive makes at the top-level, the first into an "interim" build >> dir and the second using the result of the first as its ALT_BOOTDIR. >> >> -- Jon >> >> >> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to >>> false (which, internally, sets the slightly more clearly named >>> DO_BOOT_CYCLE=true). This causes the product to build twice, the >>> second time using the first build result as the boot jdk. >>> >>> This has been used, as I understand it, as a "poor mans integration >>> test" -- if the build output could perform the feat of compiling the >>> JDK, then it can't be that broken. >>> >>> This kind of behaviour is not implemented in the new build system, >>> and I propose that it should not be. The cost for implementing this >>> is that all build system for all builds will be more complicated, >>> but the gains are more unclear. To me, this is just a test, and it's >>> a bit odd to have that as part of the build system. I also believe >>> are now far better tests using jtreg, and if they are lacking -- >>> then the tests should be improved, not the build system changed. >>> >>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE >>> functionality would be dropped in the new build system? >>> >>> /Magnus >> From michael.fang at oracle.com Mon Sep 10 21:26:13 2012 From: michael.fang at oracle.com (Michael Fang) Date: Mon, 10 Sep 2012 14:26:13 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: <504935C0.30705@oracle.com> References: <20120906202923.834A7856@eggemoggin.niobe.net> <504935C0.30705@oracle.com> Message-ID: <504E5AF5.2070302@oracle.com> Hi Mark and all, I have updated the webrev: http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ It includes the following changes: - removed component division and contact names - removed redundant "target" attributes I am also moving the file from root of source tree to jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file naming convention used by the translation system, which is component-name.tbom. This is followed by all Oracle products requiring translation. We currently have no plan to publish the syntax and semantics to the openjdk community through JEP process. We would like to keep the syntax internal. When I review dev team's changes related to resource files, I will keep an eye on the files to be translated and translation language scope. thanks, -michael Server Globalization Technology On 12?09?06? 04:46 ??, Michael Fang wrote: > Hi Mark, > > Thanks for the review and feedback. > > Please see my comments inline below. > > thanks, > > -michael > > On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote: >> 2012/9/5 14:08 -0700, michael.fang at oracle.com: >>> Please help to review the new JDK8 file for the following CR: >>> 7196354 check-in jdk.tbom file to openjdk repo >>> >>> The webrev is located at: >>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ >> This file needs a more descriptive name, especially if it's going to be >> in the root of the source tree. Suggestion: translated-files.xml . > The translation drop system is now an Oracle-wide translation system > and we are strongly recommended to follow the standard naming > convention for all Oracle products, which is component-name.tbom. > > I have checked with the team and we can move the file away from the > root of the source tree to, for example, jdk/make/jdk.tbom. > >> >> Is there a DTD or a schema for this file? I can guess what most of it >> means, but I might guess incorrectly. > The XSD is available in NLSTOOLS ADE label. > nlstools/lights2/Extractor/src/java/xsd/tbom.xsd > It's internal information. I will find it and forward it to you > separately. >> >> [line 8] "OpenJDK" isn't a component, it's a community. I think you >> mean >> "JDK" here. > Yes, JDK. >> >> The "JDK" / "JRE" division in this file is somewhat artificial and >> likely >> to become incorrect over time -- not every developer knows exactly which >> files are in the JRE vs. the full JDK. I suggest doing away with that >> division and simply sorting the file-set elements by source file name. > JDK and JRE are translated into different sets of languages. 2 > languages for JDK and 10 for JRE. We used to divide the files this way > in order to translate the files into the correct set of languages. But > it's not necessary now. Sorting by groups or projects may be fine. > Whatever is easy for the groups/teams to find and maintain their files. >> >> At a glance it looks like the source and target attributes for any given >> file are identical. Do you expect there to be cases where they're >> different? > In jdk.tbom, source and target are the same for all files. But on > jdkclosed.tbom, the man page files have different source and target > directories. >> >>> ... >>> >>> Mark: >>> Since the dev team will need to maintain this file in the future >>> (modifying it >>> if you add or delete resource files), I temporarily put down your >>> name as >>> contact for the file. Please figure out the proper owner and we can >>> update it >>> again. >> We don't put contact names in source code. Please remove my name, >> and do >> not add another. > OK, I will remove it. >> >>> ... >>> >>> In the future, if any bug/rfe requires adding/deleting resource >>> files, the dev >>> work should include updating this file to reflect the correct >>> resource file >>> list. (and please ask me to review it). >> If you expect other people to update this file over time then you need >> to document that expectation somewhere and, as importantly, you need to >> document the syntax and semantics of the file. Fortunately we have a >> way to do that, namely the JEP process (http://openjdk.java.net/jeps/). >> I suggest you draft a JEP for this and circulate it for review along >> with the webrev. > I will look into it. >> >> - Mark > From fredrik.ohrstrom at oracle.com Mon Sep 10 22:27:38 2012 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 11 Sep 2012 00:27:38 +0200 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E0299.6070709@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> Message-ID: <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. You can do: sh common/bin/boot_cycle.sh and it will create boot_cycle_1 in build, and build the complete product there (including images) then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the boot jdk. You can also add explicit configure arguments: sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=?.. and it will use the arguments to the configure invocations. The --with-boot-jdk= is of course adjusted for the second cycle. This boot_cycle.sh script has already demonstrated that --enable-debug generates binaries that crash on linux x64?? :-) something that we have to fix. //Fredrik 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: > Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. > > Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. > > -- Jon > > > On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. >> >> This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. >> >> This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. >> >> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? >> >> /Magnus > From jonathan.gibbons at oracle.com Mon Sep 10 23:00:48 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 16:00:48 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> Message-ID: <504E7120.7080701@oracle.com> Can we have a makefile target that invokes your script? E.g. make full-build. It is easier to document the list of public targets supported by the Makefiles than to describe a set of assorted extra scripts. And, it would fit more uniformly into the JPRT infrastructure. -- Jon On 09/10/2012 03:27 PM, Fredrik ?hrstr?m wrote: > You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. > > You can do: > > sh common/bin/boot_cycle.sh > > and it will create boot_cycle_1 in build, and build the complete product there (including images) > then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the boot jdk. > > You can also add explicit configure arguments: > sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=?.. > > and it will use the arguments to the configure invocations. The --with-boot-jdk= is of course > adjusted for the second cycle. > > This boot_cycle.sh script has already demonstrated that --enable-debug generates binaries > that crash on linux x64?? :-) something that we have to fix. > > //Fredrik > > 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: > >> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. >> >> Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. >> >> -- Jon >> >> >> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. >>> >>> This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. >>> >>> This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. >>> >>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? >>> >>> /Magnus From naoto.sato at oracle.com Tue Sep 11 05:57:14 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 10 Sep 2012 22:57:14 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: <504E5AF5.2070302@oracle.com> References: <20120906202923.834A7856@eggemoggin.niobe.net> <504935C0.30705@oracle.com> <504E5AF5.2070302@oracle.com> Message-ID: <504ED2BA.1070508@oracle.com> Hi Michael, Looks like the list does not reflect the recent changes introduced by the re-organization of the locale data (sun/util/resources). To me, just keeping an eye on the files sounds error prone. Would it be possible to add some automated check, say in "jcheck"? Naoto On 9/10/12 2:26 PM, Michael Fang wrote: > Hi Mark and all, > > I have updated the webrev: > http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ > > It includes the following changes: > > - removed component division and contact names > - removed redundant "target" attributes > > > I am also moving the file from root of source tree to jdk/make/jdk.tbom. > SGT strongly recommends we follow the standard file naming convention > used by the translation system, which is component-name.tbom. This is > followed by all Oracle products requiring translation. > > > We currently have no plan to publish the syntax and semantics to the > openjdk community through JEP process. We would like to keep the syntax > internal. When I review dev team's changes related to resource files, I > will keep an eye on the files to be translated and translation language > scope. > > thanks, > > -michael > Server Globalization Technology > > On 12?09?06? 04:46 ??, Michael Fang wrote: >> Hi Mark, >> >> Thanks for the review and feedback. >> >> Please see my comments inline below. >> >> thanks, >> >> -michael >> >> On 12?09?06? 01:29 ??, mark.reinhold at oracle.com wrote: >>> 2012/9/5 14:08 -0700, michael.fang at oracle.com: >>>> Please help to review the new JDK8 file for the following CR: >>>> 7196354 check-in jdk.tbom file to openjdk repo >>>> >>>> The webrev is located at: >>>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/ >>> This file needs a more descriptive name, especially if it's going to be >>> in the root of the source tree. Suggestion: translated-files.xml . >> The translation drop system is now an Oracle-wide translation system >> and we are strongly recommended to follow the standard naming >> convention for all Oracle products, which is component-name.tbom. >> >> I have checked with the team and we can move the file away from the >> root of the source tree to, for example, jdk/make/jdk.tbom. >> >>> >>> Is there a DTD or a schema for this file? I can guess what most of it >>> means, but I might guess incorrectly. >> The XSD is available in NLSTOOLS ADE label. >> nlstools/lights2/Extractor/src/java/xsd/tbom.xsd >> It's internal information. I will find it and forward it to you >> separately. >>> >>> [line 8] "OpenJDK" isn't a component, it's a community. I think you >>> mean >>> "JDK" here. >> Yes, JDK. >>> >>> The "JDK" / "JRE" division in this file is somewhat artificial and >>> likely >>> to become incorrect over time -- not every developer knows exactly which >>> files are in the JRE vs. the full JDK. I suggest doing away with that >>> division and simply sorting the file-set elements by source file name. >> JDK and JRE are translated into different sets of languages. 2 >> languages for JDK and 10 for JRE. We used to divide the files this way >> in order to translate the files into the correct set of languages. But >> it's not necessary now. Sorting by groups or projects may be fine. >> Whatever is easy for the groups/teams to find and maintain their files. >>> >>> At a glance it looks like the source and target attributes for any given >>> file are identical. Do you expect there to be cases where they're >>> different? >> In jdk.tbom, source and target are the same for all files. But on >> jdkclosed.tbom, the man page files have different source and target >> directories. >>> >>>> ... >>>> >>>> Mark: >>>> Since the dev team will need to maintain this file in the future >>>> (modifying it >>>> if you add or delete resource files), I temporarily put down your >>>> name as >>>> contact for the file. Please figure out the proper owner and we can >>>> update it >>>> again. >>> We don't put contact names in source code. Please remove my name, >>> and do >>> not add another. >> OK, I will remove it. >>> >>>> ... >>>> >>>> In the future, if any bug/rfe requires adding/deleting resource >>>> files, the dev >>>> work should include updating this file to reflect the correct >>>> resource file >>>> list. (and please ask me to review it). >>> If you expect other people to update this file over time then you need >>> to document that expectation somewhere and, as importantly, you need to >>> document the syntax and semantics of the file. Fortunately we have a >>> way to do that, namely the JEP process (http://openjdk.java.net/jeps/). >>> I suggest you draft a JEP for this and circulate it for review along >>> with the webrev. >> I will look into it. >>> >>> - Mark >> > From fredrik.ohrstrom at oracle.com Tue Sep 11 06:04:20 2012 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 11 Sep 2012 08:04:20 +0200 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E7120.7080701@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> Message-ID: <3F275856-0146-4991-BAF8-605D784C9EFF@oracle.com> Sure, that would be trivial. But is it a good design? You would need some way to differentiate configure arguments and make arguments on the command line. A nicer way would be to have --enable-boot-cycle on the configure script. The option was there for quite some time, in anticipation of this feature, however it seems to have been removed. //Fredrik 11 sep 2012 kl. 01:00 skrev Jonathan Gibbons: > Can we have a makefile target that invokes your script? E.g. make full-build. > > It is easier to document the list of public targets supported by the Makefiles than to describe a set of assorted extra scripts. And, it would fit more uniformly into the JPRT infrastructure. > > -- Jon > > On 09/10/2012 03:27 PM, Fredrik ?hrstr?m wrote: >> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. >> >> You can do: >> >> sh common/bin/boot_cycle.sh >> >> and it will create boot_cycle_1 in build, and build the complete product there (including images) >> then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the boot jdk. >> >> You can also add explicit configure arguments: >> sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=?.. >> >> and it will use the arguments to the configure invocations. The --with-boot-jdk= is of course >> adjusted for the second cycle. >> >> This boot_cycle.sh script has already demonstrated that --enable-debug generates binaries >> that crash on linux x64?? :-) something that we have to fix. >> >> //Fredrik >> >> 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: >> >>> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. >>> >>> Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. >>> >>> -- Jon >>> >>> >>> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. >>>> >>>> This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. >>>> >>>> This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. >>>> >>>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? >>>> >>>> /Magnus > From Alan.Bateman at oracle.com Tue Sep 11 08:30:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2012 09:30:48 +0100 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <1470040061.3251525.1347306175281.JavaMail.root@redhat.com> References: <1470040061.3251525.1347306175281.JavaMail.root@redhat.com> Message-ID: <504EF6B8.6040505@oracle.com> On 10/09/2012 20:42, Andrew Hughes wrote: > : > > Yes, jtreg tests would catch this too, but they take more time& configuration than a > simple second build, plus there are tests that are known to fail and areas that aren't tested. A topic for another thread but the goal is that all tests should pass, we don't do "known failures". We're not there yet but one "tool" to be aware of is the exclude list for tests in the jdk repository (jdk/test/ProblemList,txt). You've probably see reviews/change-sets go by where people add or remove tests. Buggy tests should be added there as it is pointless running them. If you run jtreg directly then the -exclude option is used to specify the file, if you run the tests via the Makefile targets then it adds -exclude by default. > One particular issue is with the way the OpenJDK build is structured. I don't know if this > has changed in the new build but I doubt it. Because langtools, corba, jaxp, jaxws& hotspot > are built before the jdk on a full build, they inherently build against the bootstrap VMs > version of classes they depend on (including some internal com.sun.*& sun.* classes). > So the second build will build these against the latest versions rather than the bootstrap > versions, effectively giving a free test that the JDK can still build itself as well. We > spotted this in working on IcedTea, as obviously the internal classes aren't present on > non-Sun/Oracle JDKs so the build had to patched to use the JDK source code. Yes, this is a big problem with the old build system although the activity in the corba, jaxp, and jaxws repositories is quite low so it's not noticed very often there. However there have been occasions, one or two in the last year, where we've had issues there and boot cycle builds have caught it. From what I can this is not an issue in the new build system. -Alan. From Dmitry.Samersoff at oracle.com Tue Sep 11 09:41:02 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Sep 2012 13:41:02 +0400 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E0299.6070709@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> Message-ID: <504F072E.1050609@oracle.com> Jonathan, Personally, I would prefer to have a separate set of tests - "smoke tests" and appropriate make target. e.g. make test instead of BOOT_CYCLE logic. Test suite should have known coverage and predictable effects, otherwise it makes an illusion of testing. -Dmitry On 2012-09-10 19:09, Jonathan Gibbons wrote: > Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be > concerned about its removal. > > Is it really that hard to provide the same functionality in the new > build system? Surely, it should just be a matter of a couple of > recursive makes at the top-level, the first into an "interim" build dir > and the second using the result of the first as its ALT_BOOTDIR. > > -- Jon > > > On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to >> false (which, internally, sets the slightly more clearly named >> DO_BOOT_CYCLE=true). This causes the product to build twice, the >> second time using the first build result as the boot jdk. >> >> This has been used, as I understand it, as a "poor mans integration >> test" -- if the build output could perform the feat of compiling the >> JDK, then it can't be that broken. >> >> This kind of behaviour is not implemented in the new build system, and >> I propose that it should not be. The cost for implementing this is >> that all build system for all builds will be more complicated, but the >> gains are more unclear. To me, this is just a test, and it's a bit odd >> to have that as part of the build system. I also believe are now far >> better tests using jtreg, and if they are lacking -- then the tests >> should be improved, not the build system changed. >> >> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE >> functionality would be dropped in the new build system? >> >> /Magnus > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From anthony.petrov at oracle.com Tue Sep 11 13:25:40 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Sep 2012 17:25:40 +0400 Subject: The future of partial builds In-Reply-To: <504DFEA3.6060002@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> <504DFDA2.4060007@oracle.com> <504DFEA3.6060002@oracle.com> Message-ID: <504F3BD4.1030809@oracle.com> +1 -- best regards, Anthony On 9/10/2012 6:52 PM, Weijun Wang wrote: > Sorry I was not clear, by "clone the repo(s)", I mean either only the > jdk repo, or plus the jdk/*/closed ones. I almost never clone other > repos (langtools, hotspot, ...). > > -Max > > On 09/10/2012 10:48 PM, Weijun Wang wrote: >> It's not uncommon that I just clone the repo(s), do a quick build, run >> several tests and abandon it, for example, if I want to try my code >> changes on a different platform (from my daily work machine). Therefore >> I find the jdk-only build very useful. >> >> -Max >> >> On 09/10/2012 10:20 PM, Magnus Ihse Bursie wrote: >>> On 2012-09-10 14:13, Alan Bateman wrote: >>>> >>>> I think this is a great topic to discuss. >>>> >>>> At least within Oracle then I think the majority of people do partial >>>> builds in their local environment. When I say "partial build" then I >>>> mean they build a subset of repositories, not all of them. So folks >>>> working in the jdk repository tend to just build that repository with >>>> everything else coming from whatever import JDK they are using. >>>> Partial builds are of course very fragile and frequently people have >>>> problems because they aren't using a matching import JDK. Also >>>> periodically we have flag days, say changes that impact langtools+jdk >>>> or hotspot+jdk and these usually cause a bit of disruption until the >>>> changes get into a promoted build and into the import JDK that people >>>> use. As to why people do partial builds then it's probably a mix of >>>> issues including disk space, time to do the first build, and of course >>>> it's just the way that we've always done it. >>> >>> >>> In build-infra, there is currently a "somewhat partial build" feature >>> that is implemented like this: >>> 1) You check out a "master forest", containing all repos. You only need >>> to do this checkout once, and you are not required to pull/update it >>> (unless you want to keep up with changes -- like on a flag day). >>> >>> 2) For subsequent work, you can clone just a single repo (let's call it >>> "my_hotspot"), and doing some configure magic (currently a bit >>> complicated, but that can be rewritten to be simpler) which will point >>> to the "master forest" but replace the hotspot repo in the master forest >>> with "my_hotspot".. >>> >>> 3) The first time you build "my_hotspot", it will rebuild the whole >>> forest (but with hotspot replaced with my_hotspot). However, if you >>> never pull/update the master forest, this will be a one-time event. >>> Subsequent builds will see that nothing has changed in the master >>> forest, and only changes in my_hotspot will be recompiled. >>> >>> The pros with this solution is: >>> 1) help with flag days -- just pull/update the master forest and >>> rebuild. >>> 2) you can always build the complete product. >>> 3) you save some disk space by only cloning the complete forest once. >>> >>> However: >>> 1) you will still need disk space for build output for the complete >>> forest, for every single repo. >>> 2) you will still need to recompile the whole forest for each new single >>> repo you clone. >>> >>> Do you think this will make the solution not good enough? >>> >>> I think it is possible and not too hard to change this solution >>> slightly, so you would only need to compile the master forest once, and >>> then new single repos can use that build output as well as using the >>> source code from the master forest. Though proper dependency checking >>> might be harder, and there will be semantic issues about the meaning of >>> things like "make clean" that can be surprising. Is this something you >>> think is worth pursuing? >>> >>> To completely eliminate compiling the whole product at least once seems >>> much harder. I can't really see a good way of using "import JDKs" the >>> way they've been used in the old build system. I imagine one possibility >>> is to prepare a tar ball, including a complete cloned forest (for a >>> certain point in time) and a build directory with build artifacts >>> corresponding to that source code and your platform(s) of choice, and >>> have people download that as starting point. It seems like a lot of >>> work, though. Do you think that is needed to get the new build system >>> accepted? >>> >>> /Magnus From anthony.petrov at oracle.com Tue Sep 11 13:37:54 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Sep 2012 17:37:54 +0400 Subject: The future of partial builds In-Reply-To: <504DF280.9010505@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> Message-ID: <504F3EB2.4090706@oracle.com> Magnus, You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) $ make And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). -- best regards, Anthony On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: > On 2012-09-10 14:13, Alan Bateman wrote: >> When you say "sub-directory builds" then I think you mean incremental >> builds, or "poor-man increment builds" as I call it. I think the >> majority of people working in the jdk repository, at least in Oracle, >> do this because they know the area and know which make files that >> re-build the files that they have changed. Incremental builds are >> generally not very reliable but seem to be "good enough" for most >> people needs, at least those that aren't doing significant >> refactoring. The main motive of course is to be able to re-build in a >> few seconds and the #1 goal of any new build system has to be fast >> incremental builds. > > In the new build system, fast incremental builds of Java code is > dependent on the new "smart javac", which unfortunately has still not > proven stable enough to be enabled by default, even in the experimental > build-infra forest. It is still our hope that it will turn out to be > good enough to be used as default, but I don't want to trust hope alone. > > As an interim solution, I have just created the following two shortcuts. > Both of these bypass the proper dependency detection. This means that > make will cut to the chase and recompile faster, but it also means that > you need to take over the responsibility of making sure dependencies are > correct. This is very similar to the "*-only" (e.g. hotspot-only) > targets that are current available in the new build system. > > First shortcut is to skip parts of the JDK makefile. By typing e.g. > "make jdk JDK_TARGET=classes", the JDK build will stop after building > the "classes" target (which compiles the majority of the JDK java > files). An even faster, but less safe, version is "make jdk-only > JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, > and only execute the "classes" target. In this way, absolutely no time > is spent before starting to compile Java classes. > > Second shortcut is to limit the classes that are recompiled by the JDK > "classes" target. Currently, *all* (more or less) Java classes in the > JDK is recompiled at once. While this speeds up things considerably at a > first time compilation, it makes all subsequent builds take the same > time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio > package will get compiled. This is, I think, similar (but not strictly > not identical) to the effect of "sub-directory builds". It is possible > to use an even more fine-grained filter, separated by comma, e.g. > JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of > Java files your filter includes, the faster the build will go (more or > less). > > These two can of course be combined. > > I would like to point out that this is hopefully a temporary solution -- > if proper dependency checking and incremental builds get fast enough, > this kind of trickery should not be needed. If this happens, we will > remove the support for these shortcuts since they do carry a risk of > improper builds. > > /Magnus From chris.hegarty at oracle.com Tue Sep 11 13:44:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 11 Sep 2012 14:44:59 +0100 Subject: The future of partial builds In-Reply-To: <504F3EB2.4090706@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> Message-ID: <504F405B.6010701@oracle.com> On 11/09/12 14:37, Anthony Petrov wrote: > Magnus, > > You've only explained how incremental builds could work for Java classes > in the new build-infra. What about incremental builds of native code? > E.g. in AWT we often do the following: > > $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) > $ make We do the same for java/net and sun/net. This greatly improves productivity when working platform specific issues ( and the only hardware configured to build is not lightning fast, I'm thinking of older sparc machines for example ). -Chris. > > And this re-builds both AWT classes and AWT native code (and some 2D > stuff too, btw). What has build-infra got to offer for incremental > builds of native code? > > Also, how fast are those incremental solutions (both the temporary, and > the expected final one) in build-infra? Performing the above commands > with the current build system takes literally just a few seconds on any > platform (given you've built the JDK repo once before, and it might took > like 10-30 minutes for the first build). > > -- > best regards, > Anthony > > On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >> On 2012-09-10 14:13, Alan Bateman wrote: >>> When you say "sub-directory builds" then I think you mean incremental >>> builds, or "poor-man increment builds" as I call it. I think the >>> majority of people working in the jdk repository, at least in Oracle, >>> do this because they know the area and know which make files that >>> re-build the files that they have changed. Incremental builds are >>> generally not very reliable but seem to be "good enough" for most >>> people needs, at least those that aren't doing significant >>> refactoring. The main motive of course is to be able to re-build in a >>> few seconds and the #1 goal of any new build system has to be fast >>> incremental builds. >> >> In the new build system, fast incremental builds of Java code is >> dependent on the new "smart javac", which unfortunately has still not >> proven stable enough to be enabled by default, even in the >> experimental build-infra forest. It is still our hope that it will >> turn out to be good enough to be used as default, but I don't want to >> trust hope alone. >> >> As an interim solution, I have just created the following two >> shortcuts. Both of these bypass the proper dependency detection. This >> means that make will cut to the chase and recompile faster, but it >> also means that you need to take over the responsibility of making >> sure dependencies are correct. This is very similar to the "*-only" >> (e.g. hotspot-only) targets that are current available in the new >> build system. >> >> First shortcut is to skip parts of the JDK makefile. By typing e.g. >> "make jdk JDK_TARGET=classes", the JDK build will stop after building >> the "classes" target (which compiles the majority of the JDK java >> files). An even faster, but less safe, version is "make jdk-only >> JDK_TARGET=classes-only", which will jump directly to the JDK >> Makefile, and only execute the "classes" target. In this way, >> absolutely no time is spent before starting to compile Java classes. >> >> Second shortcut is to limit the classes that are recompiled by the JDK >> "classes" target. Currently, *all* (more or less) Java classes in the >> JDK is recompiled at once. While this speeds up things considerably at >> a first time compilation, it makes all subsequent builds take the same >> time. By specifying e.g. JDK_FILTER=java/nio, only files in the >> java/nio package will get compiled. This is, I think, similar (but not >> strictly not identical) to the effect of "sub-directory builds". It is >> possible to use an even more fine-grained filter, separated by comma, >> e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller >> number of Java files your filter includes, the faster the build will >> go (more or less). >> >> These two can of course be combined. >> >> I would like to point out that this is hopefully a temporary solution >> -- if proper dependency checking and incremental builds get fast >> enough, this kind of trickery should not be needed. If this happens, >> we will remove the support for these shortcuts since they do carry a >> risk of improper builds. >> >> /Magnus From Alan.Bateman at oracle.com Tue Sep 11 14:33:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2012 15:33:01 +0100 Subject: The future of partial builds In-Reply-To: <504DF711.8080802@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF711.8080802@oracle.com> Message-ID: <504F4B9D.7080101@oracle.com> On 10/09/2012 15:20, Magnus Ihse Bursie wrote: > : > > In build-infra, there is currently a "somewhat partial build" feature > that is implemented like this: > 1) You check out a "master forest", containing all repos. You only > need to do this checkout once, and you are not required to pull/update > it (unless you want to keep up with changes -- like on a flag day). > > 2) For subsequent work, you can clone just a single repo (let's call > it "my_hotspot"), and doing some configure magic (currently a bit > complicated, but that can be rewritten to be simpler) which will point > to the "master forest" but replace the hotspot repo in the master > forest with "my_hotspot".. > > 3) The first time you build "my_hotspot", it will rebuild the whole > forest (but with hotspot replaced with my_hotspot). However, if you > never pull/update the master forest, this will be a one-time event. > Subsequent builds will see that nothing has changed in the master > forest, and only changes in my_hotspot will be recompiled. > > The pros with this solution is: > 1) help with flag days -- just pull/update the master forest and rebuild. > 2) you can always build the complete product. > 3) you save some disk space by only cloning the complete forest once. > > However: > 1) you will still need disk space for build output for the complete > forest, for every single repo. > 2) you will still need to recompile the whole forest for each new > single repo you clone. > > Do you think this will make the solution not good enough? > > I think it is possible and not too hard to change this solution > slightly, so you would only need to compile the master forest once, > and then new single repos can use that build output as well as using > the source code from the master forest. Though proper dependency > checking might be harder, and there will be semantic issues about the > meaning of things like "make clean" that can be surprising. Is this > something you think is worth pursuing? > > To completely eliminate compiling the whole product at least once > seems much harder. I can't really see a good way of using "import > JDKs" the way they've been used in the old build system. I imagine one > possibility is to prepare a tar ball, including a complete cloned > forest (for a certain point in time) and a build directory with build > artifacts corresponding to that source code and your platform(s) of > choice, and have people download that as starting point. It seems like > a lot of work, though. Do you think that is needed to get the new > build system accepted? > > /Magnus I've had to track down several issues over the years with partial builds that were caused by someone using the wrong import JDK. So in one sense I look forward to us having less issues. My personal view is that those that only build the jdk repository will need to get over this. If the initial build is fast and subsequent incremental builds are super fast then it might be okay. I'm much less sure about those that only build hotspot or only build langtools today, the benefits are less clear. Also for those building hotspot then it may be that need to test with libjvm dropped into a different JDK image, I think that is what people typically do today. -Alan. From magnus.ihse.bursie at oracle.com Tue Sep 11 14:45:01 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Sep 2012 16:45:01 +0200 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E7120.7080701@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> Message-ID: <504F4E6D.8030302@oracle.com> On 2012-09-11 01:00, Jonathan Gibbons wrote: > Can we have a makefile target that invokes your script? E.g. make > full-build. > > It is easier to document the list of public targets supported by the > Makefiles than to describe a set of assorted extra scripts. And, it > would fit more uniformly into the JPRT infrastructure. I agree that the boot cycle build fits better in as a make target. I have written an alternative solution for performing a boot cycle build, which I am about to check in. Now there is a new target, "bootcycle-images" which basically does: 1) make images 2) make images but with a new output directory (build//bootcycle-build) and using the previously build image as bootjdk, instead of the one specified to configure. As a result of implementing this, the autoconf files got some nice cleanup and refactoring as well. :-) /Magnus From Alan.Bateman at oracle.com Tue Sep 11 14:59:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2012 15:59:33 +0100 Subject: The future of partial builds In-Reply-To: <504DF280.9010505@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> Message-ID: <504F51D5.2060605@oracle.com> On 10/09/2012 15:00, Magnus Ihse Bursie wrote: > > In the new build system, fast incremental builds of Java code is > dependent on the new "smart javac", which unfortunately has still not > proven stable enough to be enabled by default, even in the > experimental build-infra forest. It is still our hope that it will > turn out to be good enough to be used as default, but I don't want to > trust hope alone. > > As an interim solution, I have just created the following two > shortcuts. Both of these bypass the proper dependency detection. This > means that make will cut to the chase and recompile faster, but it > also means that you need to take over the responsibility of making > sure dependencies are correct. This is very similar to the "*-only" > (e.g. hotspot-only) targets that are current available in the new > build system. > > First shortcut is to skip parts of the JDK makefile. By typing e.g. > "make jdk JDK_TARGET=classes", the JDK build will stop after building > the "classes" target (which compiles the majority of the JDK java > files). An even faster, but less safe, version is "make jdk-only > JDK_TARGET=classes-only", which will jump directly to the JDK > Makefile, and only execute the "classes" target. In this way, > absolutely no time is spent before starting to compile Java classes. > > Second shortcut is to limit the classes that are recompiled by the JDK > "classes" target. Currently, *all* (more or less) Java classes in the > JDK is recompiled at once. While this speeds up things considerably at > a first time compilation, it makes all subsequent builds take the same > time. By specifying e.g. JDK_FILTER=java/nio, only files in the > java/nio package will get compiled. This is, I think, similar (but not > strictly not identical) to the effect of "sub-directory builds". It is > possible to use an even more fine-grained filter, separated by comma, > e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller > number of Java files your filter includes, the faster the build will > go (more or less). > > These two can of course be combined. > > I would like to point out that this is hopefully a temporary solution > -- if proper dependency checking and incremental builds get fast > enough, this kind of trickery should not be needed. If this happens, > we will remove the support for these shortcuts since they do carry a > risk of improper builds. > > /Magnus I can't give you any feedback on this temporary solution without trying it (this isn't build-infra yet, right?). So far my experience is that touching native code and re-building is super fast, it's on par to executing specific make files in the old build (while wearing the appropriate amulet around one's neck of course). Touching java classes and re-building takes a long time, sometimes 1.5-2 minutes for me, so quite a bit slower than running specific make files. -Alan From mark.reinhold at oracle.com Tue Sep 11 15:09:46 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Sep 2012 08:09:46 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: michael.fang@oracle.com; Mon, 10 Sep 2012 14:26:13 PDT; <504E5AF5.2070302@oracle.com> Message-ID: <20120911150946.25E47491@eggemoggin.niobe.net> 2012/9/10 14:26 -0700, michael.fang at oracle.com: > I have updated the webrev: > http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ > > ... > > I am also moving the file from root of source tree to > jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file > naming convention used by the translation system, which is > component-name.tbom. This is followed by all Oracle products requiring > translation. > > We currently have no plan to publish the syntax and semantics to the openjdk > community through JEP process. We would like to keep the syntax internal. When > I review dev team's changes related to resource files, I will keep an eye on > the files to be translated and translation language scope. Thanks for the update. A file whose syntax and semantics are not publicly documented, whose content can only be validated by an employee of one company, and whose very name is dictated by that company has no place in an OpenJDK code repository. Please work with other Oracle engineers to find a place for this file in one of Oracle's related internal repositories. - Mark From michael.fang at oracle.com Tue Sep 11 15:11:37 2012 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 11 Sep 2012 08:11:37 -0700 Subject: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo In-Reply-To: <20120911150946.25E47491@eggemoggin.niobe.net> References: <20120911150946.25E47491@eggemoggin.niobe.net> Message-ID: <504F54A9.1020104@oracle.com> Thanks Mark for the comment. Yes, we will do that. thanks, -michael On 12?09?11? 08:09 ??, mark.reinhold at oracle.com wrote: > 2012/9/10 14:26 -0700, michael.fang at oracle.com: >> I have updated the webrev: >> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/ >> >> ... >> >> I am also moving the file from root of source tree to >> jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file >> naming convention used by the translation system, which is >> component-name.tbom. This is followed by all Oracle products requiring >> translation. >> >> We currently have no plan to publish the syntax and semantics to the openjdk >> community through JEP process. We would like to keep the syntax internal. When >> I review dev team's changes related to resource files, I will keep an eye on >> the files to be translated and translation language scope. > Thanks for the update. > > A file whose syntax and semantics are not publicly documented, whose > content can only be validated by an employee of one company, and whose > very name is dictated by that company has no place in an OpenJDK code > repository. > > Please work with other Oracle engineers to find a place for this file > in one of Oracle's related internal repositories. > > - Mark From jonathan.gibbons at oracle.com Mon Sep 10 16:04:26 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 09:04:26 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <3F275856-0146-4991-BAF8-605D784C9EFF@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> <3F275856-0146-4991-BAF8-605D784C9EFF@oracle.com> Message-ID: <504E0F8A.8020307@oracle.com> That would depend on the semantics of --enable-boot-cycle. Building with a boot cycle should not be a configuration option. The ability to do a boot cycle should (IMO) always be enabled. The choice of whether to build with a boot cycle should be made by the user at the time "make" is invoked, by specifying an appropriate target (or option). This links up with the separation discussion about partial builds, in that different devs choose to go to different points in the build sequence. The "full" build sequence should be to build a boot cycle build. But along the way are various targets of interest. These include build javac (of interest to langtools devs) build the equivalent of today's jdk/build/classes (of interest to jdk devs) build initial images (maybe of interest to integrators, etc, if not doing boot cycle build) build final images after boot cycle (for integrators, etc) As a developer, depending on where I am in the dev process, I want to be able to go to my desired point in the build sequence. Initially, I want to just build javac. Later on, I may want to go to "initial images". Eventally, near commit/push, I may want to do a full boot cycle build. I would not expect to have to reconfigure my build in order to do this. -- Jon On 09/10/2012 11:04 PM, Fredrik ?hrstr?m wrote: > Sure, that would be trivial. But is it a good design? You would need some way to differentiate configure arguments and make arguments on the command line. > > A nicer way would be to have --enable-boot-cycle on the configure script. The option was there for quite some time, in anticipation of this feature, > however it seems to have been removed. > > //Fredrik > > 11 sep 2012 kl. 01:00 skrev Jonathan Gibbons: > >> Can we have a makefile target that invokes your script? E.g. make full-build. >> >> It is easier to document the list of public targets supported by the Makefiles than to describe a set of assorted extra scripts. And, it would fit more uniformly into the JPRT infrastructure. >> >> -- Jon >> >> On 09/10/2012 03:27 PM, Fredrik ?hrstr?m wrote: >>> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. >>> >>> You can do: >>> >>> sh common/bin/boot_cycle.sh >>> >>> and it will create boot_cycle_1 in build, and build the complete product there (including images) >>> then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the boot jdk. >>> >>> You can also add explicit configure arguments: >>> sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=?.. >>> >>> and it will use the arguments to the configure invocations. The --with-boot-jdk= is of course >>> adjusted for the second cycle. >>> >>> This boot_cycle.sh script has already demonstrated that --enable-debug generates binaries >>> that crash on linux x64?? :-) something that we have to fix. >>> >>> //Fredrik >>> >>> 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: >>> >>>> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. >>>> >>>> Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. >>>> >>>> -- Jon >>>> >>>> >>>> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>>>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. >>>>> >>>>> This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. >>>>> >>>>> This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. >>>>> >>>>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? >>>>> >>>>> /Magnus From jonathan.gibbons at oracle.com Mon Sep 10 16:15:20 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 09:15:20 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504F072E.1050609@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <504F072E.1050609@oracle.com> Message-ID: <504E1218.4020304@oracle.com> Dmitry, I agree on the desire to have a good set of smoke tests, but there should be room in the world for both smoke tests and a full boot cycle build. We do not have to restrict ourselves to one or the other. -- Jon On 09/11/2012 02:41 AM, Dmitry Samersoff wrote: > Jonathan, > > Personally, I would prefer to have a separate set of tests - "smoke > tests" and appropriate make target. e.g. make test instead of BOOT_CYCLE > logic. > > Test suite should have known coverage and predictable effects, otherwise > it makes an illusion of testing. > > -Dmitry > > > On 2012-09-10 19:09, Jonathan Gibbons wrote: >> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be >> concerned about its removal. >> >> Is it really that hard to provide the same functionality in the new >> build system? Surely, it should just be a matter of a couple of >> recursive makes at the top-level, the first into an "interim" build dir >> and the second using the result of the first as its ALT_BOOTDIR. >> >> -- Jon >> >> >> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to >>> false (which, internally, sets the slightly more clearly named >>> DO_BOOT_CYCLE=true). This causes the product to build twice, the >>> second time using the first build result as the boot jdk. >>> >>> This has been used, as I understand it, as a "poor mans integration >>> test" -- if the build output could perform the feat of compiling the >>> JDK, then it can't be that broken. >>> >>> This kind of behaviour is not implemented in the new build system, and >>> I propose that it should not be. The cost for implementing this is >>> that all build system for all builds will be more complicated, but the >>> gains are more unclear. To me, this is just a test, and it's a bit odd >>> to have that as part of the build system. I also believe are now far >>> better tests using jtreg, and if they are lacking -- then the tests >>> should be improved, not the build system changed. >>> >>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE >>> functionality would be dropped in the new build system? >>> >>> /Magnus > From jonathan.gibbons at oracle.com Mon Sep 10 16:24:48 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2012 09:24:48 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504F4E6D.8030302@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> <504F4E6D.8030302@oracle.com> Message-ID: <504E1450.5010200@oracle.com> On 09/11/2012 07:45 AM, Magnus Ihse Bursie wrote: > On 2012-09-11 01:00, Jonathan Gibbons wrote: >> Can we have a makefile target that invokes your script? E.g. make >> full-build. >> >> It is easier to document the list of public targets supported by the >> Makefiles than to describe a set of assorted extra scripts. And, it >> would fit more uniformly into the JPRT infrastructure. > > I agree that the boot cycle build fits better in as a make target. > > I have written an alternative solution for performing a boot cycle > build, which I am about to check in. Now there is a new target, > "bootcycle-images" which basically does: > 1) make images > 2) make images but with a new output directory > (build//bootcycle-build) and using the previously build > image as bootjdk, instead of the one specified to configure. > > As a result of implementing this, the autoconf files got some nice > cleanup and refactoring as well. :-) > > /Magnus That sounds great; well done, and thank you. -- Jon From kelly.ohair at oracle.com Tue Sep 11 16:44:08 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 11 Sep 2012 09:44:08 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E0F8A.8020307@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> <3F275856-0146-4991-BAF8-605D784C9EFF@oracle.com> <504E0F8A.8020307@oracle.com> Message-ID: <3AB8D1A8-204D-4B05-98F4-DA752F38114C@oracle.com> I have to agree with Jonathan here. I don't think a boot cycle build should be a configure option. -kto On Sep 10, 2012, at 9:04 AM, Jonathan Gibbons wrote: > That would depend on the semantics of --enable-boot-cycle. > > Building with a boot cycle should not be a configuration option. The ability to do a boot cycle should (IMO) always be enabled. The choice of whether to build with a boot cycle should be made by the user at the time "make" is invoked, by specifying an appropriate target (or option). > > This links up with the separation discussion about partial builds, in that different devs choose to go to different points in the build sequence. The "full" build sequence should be to build a boot cycle build. But along the way are various targets of interest. These include > build javac (of interest to langtools devs) > build the equivalent of today's jdk/build/classes (of interest to jdk devs) > build initial images (maybe of interest to integrators, etc, if not doing boot cycle build) > build final images after boot cycle (for integrators, etc) > > As a developer, depending on where I am in the dev process, I want to be able to go to my desired point in the build sequence. Initially, I want to just build javac. Later on, I may want to go to "initial images". Eventally, near commit/push, I may want to do a full boot cycle build. I would not expect to have to reconfigure my build in order to do this. > > -- Jon > > > On 09/10/2012 11:04 PM, Fredrik ?hrstr?m wrote: >> Sure, that would be trivial. But is it a good design? You would need some way to differentiate configure arguments and make arguments on the command line. >> >> A nicer way would be to have --enable-boot-cycle on the configure script. The option was there for quite some time, in anticipation of this feature, >> however it seems to have been removed. >> >> //Fredrik >> >> 11 sep 2012 kl. 01:00 skrev Jonathan Gibbons: >> >>> Can we have a makefile target that invokes your script? E.g. make full-build. >>> >>> It is easier to document the list of public targets supported by the Makefiles than to describe a set of assorted extra scripts. And, it would fit more uniformly into the JPRT infrastructure. >>> >>> -- Jon >>> >>> On 09/10/2012 03:27 PM, Fredrik ?hrstr?m wrote: >>>> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. >>>> >>>> You can do: >>>> >>>> sh common/bin/boot_cycle.sh >>>> >>>> and it will create boot_cycle_1 in build, and build the complete product there (including images) >>>> then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the boot jdk. >>>> >>>> You can also add explicit configure arguments: >>>> sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=?.. >>>> >>>> and it will use the arguments to the configure invocations. The --with-boot-jdk= is of course >>>> adjusted for the second cycle. >>>> >>>> This boot_cycle.sh script has already demonstrated that --enable-debug generates binaries >>>> that crash on linux x64?? :-) something that we have to fix. >>>> >>>> //Fredrik >>>> >>>> 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: >>>> >>>>> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be concerned about its removal. >>>>> >>>>> Is it really that hard to provide the same functionality in the new build system? Surely, it should just be a matter of a couple of recursive makes at the top-level, the first into an "interim" build dir and the second using the result of the first as its ALT_BOOTDIR. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>>>>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false (which, internally, sets the slightly more clearly named DO_BOOT_CYCLE=true). This causes the product to build twice, the second time using the first build result as the boot jdk. >>>>>> >>>>>> This has been used, as I understand it, as a "poor mans integration test" -- if the build output could perform the feat of compiling the JDK, then it can't be that broken. >>>>>> >>>>>> This kind of behaviour is not implemented in the new build system, and I propose that it should not be. The cost for implementing this is that all build system for all builds will be more complicated, but the gains are more unclear. To me, this is just a test, and it's a bit odd to have that as part of the build system. I also believe are now far better tests using jtreg, and if they are lacking -- then the tests should be improved, not the build system changed. >>>>>> >>>>>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE functionality would be dropped in the new build system? >>>>>> >>>>>> /Magnus > From kelly.ohair at oracle.com Tue Sep 11 16:52:27 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 11 Sep 2012 09:52:27 -0700 Subject: Is the "skip boot cycle" trick still needed? In-Reply-To: <504E1450.5010200@oracle.com> References: <504DD244.50501@oracle.com> <504E0299.6070709@oracle.com> <2C63658B-FB35-42B3-B5B4-860E1563045F@oracle.com> <504E7120.7080701@oracle.com> <504F4E6D.8030302@oracle.com> <504E1450.5010200@oracle.com> Message-ID: <070B8AF7-08CF-4DBA-9BEA-7AD725EDC3F4@oracle.com> On Sep 10, 2012, at 9:24 AM, Jonathan Gibbons wrote: > On 09/11/2012 07:45 AM, Magnus Ihse Bursie wrote: >> On 2012-09-11 01:00, Jonathan Gibbons wrote: >>> Can we have a makefile target that invokes your script? E.g. make full-build. >>> >>> It is easier to document the list of public targets supported by the Makefiles than to describe a set of assorted extra scripts. And, it would fit more uniformly into the JPRT infrastructure. >> >> I agree that the boot cycle build fits better in as a make target. >> >> I have written an alternative solution for performing a boot cycle build, which I am about to check in. Now there is a new target, "bootcycle-images" which basically does: >> 1) make images >> 2) make images but with a new output directory (build//bootcycle-build) and using the previously build image as bootjdk, instead of the one specified to configure. >> >> As a result of implementing this, the autoconf files got some nice cleanup and refactoring as well. :-) >> >> /Magnus > > That sounds great; well done, and thank you. > > -- Jon That sounds fine. -kto From oehrstroem at gmail.com Tue Sep 11 18:23:55 2012 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 11 Sep 2012 20:23:55 +0200 Subject: The future of partial builds In-Reply-To: <504F51D5.2060605@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> Message-ID: Den tisdagen den 11:e september 2012 skrev Alan Bateman: > > So far my experience is that touching native code and re-building is super > fast, it's on par to executing specific make files in the old build (while > wearing the appropriate amulet around one's neck of course). Touching java > classes and re-building takes a long time, sometimes 1.5-2 minutes for me, > so quite a bit slower than running specific make files. Sounds good that native incremental builds works as they should. :-) Could you (in build-infra) please test --enable-sjavac and then touch java files and do incremental builds, and report your experience here. //Fredrik From Alan.Bateman at oracle.com Tue Sep 11 19:59:55 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2012 20:59:55 +0100 Subject: The future of partial builds In-Reply-To: References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> Message-ID: <504F983B.9010303@oracle.com> On 11/09/2012 19:23, Fredrik ?hrstr?m wrote: > > Den tisdagen den 11:e september 2012 skrev Alan Bateman: > > So far my experience is that touching native code and re-building > is super fast, it's on par to executing specific make files in the > old build (while wearing the appropriate amulet around one's neck > of course). Touching java classes and re-building takes a long > time, sometimes 1.5-2 minutes for me, so quite a bit slower than > running specific make files. > > > Sounds good that native incremental builds works as they should. :-) > Could you (in build-infra) please test --enable-sjavac and then touch > java files and do incremental builds, > and report your experience here. > > //Fredrik With a sjavac config I touched one source file and the incremental build took 36s so much better. In this case the one class caused 77 classes to be re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the other hand, the old make does it in 2s, mostly because it just re-compiled the 1 class without a care in the world as to who is using it. -Alan. From kelly.ohair at oracle.com Tue Sep 11 23:51:19 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 11 Sep 2012 23:51:19 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20120911235200.AFB4447A2A@hg.openjdk.java.net> Changeset: 9c434431d013 Author: ohair Date: 2012-09-11 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9c434431d013 7197771: Adjust jdk sources to avoid use of implementation defined value of __FILE__ 7180608: Sort the order of object files when building shared libraries Reviewed-by: ohrstrom, erikj, tbell ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/macosx/native/com/apple/laf/ScreenMenu.m ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiOut.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.c ! src/macosx/native/sun/awt/CSystemColors.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/macosx/native/sun/font/AWTStrike.m ! src/share/back/error_messages.h ! src/share/back/log_messages.h ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/instrument/JPLISAssert.h ! src/share/native/sun/awt/debug/debug_assert.h ! src/share/native/sun/awt/debug/debug_mem.c ! src/share/native/sun/awt/debug/debug_trace.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/share/npt/utf.h ! src/share/transport/shmem/shmemBase.h ! src/solaris/instrument/EncodingSupport_md.c ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c ! src/windows/native/sun/java2d/d3d/D3DPipeline.h ! src/windows/native/sun/windows/alloc.h ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/transport/shmem/shmem_md.c Changeset: 7ecc3a7cbe36 Author: ohair Date: 2012-09-11 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7ecc3a7cbe36 Merge ! make/common/Program.gmk - make/sun/beans/Makefile - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/java/lang/invoke/MaxTest.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java From fredrik.ohrstrom at oracle.com Wed Sep 12 05:46:16 2012 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 12 Sep 2012 07:46:16 +0200 Subject: The future of partial builds In-Reply-To: <504F983B.9010303@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> Message-ID: <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> 11 sep 2012 kl. 21:59 skrev Alan Bateman: > With a sjavac config I touched one source file and the incremental build took 36s so much better. In this case the one class caused 77 classes to be re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the other hand, the old make does it in 2s, mostly because it just re-compiled the 1 class without a care in the world as to who is using it. Excellent. I hope you realize how valuable it is that the build system recompiled the proper source files, then proceed to generate the the jni headers output because of native methods in those classes that were recompiled, then proceed to recompile only the shared libraries that implement these jni interfaces. Later we will make sure that if the recompile of the java source file does not change the jni header, it will not be updated/touched. Have you tried making an actual change in a Java source file that changes the public api? To see how the build system recompiles all packages that import from that changed package? Most of 36 seconds are spent in javac. Javac is extremely fast, but has a huuuuge startup time. In particular because the option -Xprefer:source is enabled in Setup.gmk inside jdk/makefiles This means that even though you recompile only a package, it will recompile all imported classes from source. For the jdk repository, thats a lot of classes! When I touch for example SignerOutputStream.java and remake, it takes 16 seconds to rebuild. When I remove -Xprefer:source in jdk/makefiles/Setup.gmk, touch, make (takes longer because the command line changes thus it had to drop the javac_state file) but then touch, then make again, it takes only 7 seconds to rebuild. Please try, and tell us what speed improvement you gained. We should now (perhaps) remove -Xprefer:source, and let javac pickup already compiled classes from the (correct?) class path. However, this begets the question why -Xprefer:source was added in the first place. If I remember correctly, this was over a year ago. It turns out that the default behavior for implicit compilation (which is necessary for sjavac:s multi core support) is to not recompile java source files when the class has a more recent timestamp than the source file. Sounds reasonable, until you realize that javac also takes into account the timestamps in rt.jar inside the jdk. Soooo, if you check out the source code on Monday, then download a newly built jdk on tuesday, and use this as the boot jdk, then the rt. jar timestamps will be newer than the source files you are trying to compile, and this somehow messes up the build! Perhaps this is only relevant when compiling langtools where there are other bootstrap intricasies. Perhaps not. Any masters of the javac universe out there who can help resolve this conundrum? //Fredrik From Alan.Bateman at oracle.com Wed Sep 12 09:54:46 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Sep 2012 10:54:46 +0100 Subject: The future of partial builds In-Reply-To: <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> Message-ID: <50505BE6.8080202@oracle.com> On 12/09/2012 06:46, Fredrik ?hrstr?m wrote: > : > Excellent. I hope you realize how valuable it is that the build system recompiled the proper source files, then proceed to generate the the jni headers output > because of native methods in those classes that were recompiled, then proceed to recompile only the shared libraries that implement these jni interfaces. > > Later we will make sure that if the recompile of the java source file does not change the jni header, it will not be updated/touched. > > Have you tried making an actual change in a Java source file that changes the public api? To see how the build system recompiles all packages > that import from that changed package? I am aware of how clever the new build is, too clever sometimes!! So when I removed the -Xprefer:source then it immediately detected my attempt at subterfuge: Dropping old javac_state since a new command line is used In terms of timings then it reduced that specific incremental build case from 33 to 22s, which I think it getting into the right ball park. -Alan From anthony.petrov at oracle.com Wed Sep 12 10:57:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Sep 2012 14:57:25 +0400 Subject: The future of partial builds In-Reply-To: <50505BE6.8080202@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> <50505BE6.8080202@oracle.com> Message-ID: <50506A95.5050700@oracle.com> On 9/12/2012 1:54 PM, Alan Bateman wrote: > On 12/09/2012 06:46, Fredrik ?hrstr?m wrote: >> : >> Excellent. I hope you realize how valuable it is that the build system >> recompiled the proper source files, then proceed to generate the the >> jni headers output >> because of native methods in those classes that were recompiled, then >> proceed to recompile only the shared libraries that implement these >> jni interfaces. >> >> Later we will make sure that if the recompile of the java source file >> does not change the jni header, it will not be updated/touched. >> >> Have you tried making an actual change in a Java source file that >> changes the public api? To see how the build system recompiles all >> packages >> that import from that changed package? > I am aware of how clever the new build is, too clever sometimes!! So > when I removed the -Xprefer:source then it immediately detected my > attempt at subterfuge: > > Dropping old javac_state since a new command line is used > > In terms of timings then it reduced that specific incremental build case > from 33 to 22s, which I think it getting into the right ball park. That sounds promising. Thanks for testing this. -- best regards, Anthony From jonathan.gibbons at oracle.com Wed Sep 12 15:54:10 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Sep 2012 08:54:10 -0700 Subject: The future of partial builds In-Reply-To: <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> Message-ID: <5050B022.3010509@oracle.com> On 09/11/2012 10:46 PM, Fredrik ?hrstr?m wrote: > However, this begets the question why -Xprefer:source was added in the first place. If I remember correctly, > this was over a year ago. It turns out that the default behavior for implicit compilation (which is necessary for sjavac:s multi core support) > is to not recompile java source files when the class has a more recent timestamp than the source file. > Sounds reasonable, until you realize that javac also takes into account the timestamps in rt.jar inside the jdk. > Soooo, if you check out the source code on Monday, then download a newly built jdk on tuesday, > and use this as the boot jdk, then the rt. jar timestamps will be newer than the source files you are trying to > compile, and this somehow messes up the build! When you are compiling JDK, you should not be reading or in any way dependent of the bootdir rt.jar (except insofar as it is needed to execute javac itself.) The compilation itself should not read bootdir rt.jar. Indeed, you should be able to set -Xbootclasspath to build/PLATFORM-ARCH/classes, which will initially be empty. -- Jon From kelly.ohair at oracle.com Wed Sep 12 18:45:30 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Sep 2012 11:45:30 -0700 Subject: The future of partial builds In-Reply-To: <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> Message-ID: <3C0B6F1F-3A28-4E4E-A948-C1AC13C2DB3A@oracle.com> On Sep 11, 2012, at 10:46 PM, Fredrik ?hrstr?m wrote: > 11 sep 2012 kl. 21:59 skrev Alan Bateman: >> With a sjavac config I touched one source file and the incremental build took 36s so much better. In this case the one class caused 77 classes to be re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the other hand, the old make does it in 2s, mostly because it just re-compiled the 1 class without a care in the world as to who is using it. > > Excellent. I hope you realize how valuable it is that the build system recompiled the proper source files, then proceed to generate the the jni headers output > because of native methods in those classes that were recompiled, then proceed to recompile only the shared libraries that implement these jni interfaces. > > Later we will make sure that if the recompile of the java source file does not change the jni header, it will not be updated/touched. > > Have you tried making an actual change in a Java source file that changes the public api? To see how the build system recompiles all packages > that import from that changed package? > > Most of 36 seconds are spent in javac. Javac is extremely fast, but has a huuuuge startup time. In particular > because the option -Xprefer:source is enabled in Setup.gmk inside jdk/makefiles > > This means that even though you recompile only a package, it will recompile all imported classes from source. > For the jdk repository, thats a lot of classes! > > When I touch for example SignerOutputStream.java and remake, it takes 16 seconds to rebuild. > When I remove -Xprefer:source in jdk/makefiles/Setup.gmk, touch, make (takes longer because the command line changes > thus it had to drop the javac_state file) but then touch, then make again, > it takes only 7 seconds to rebuild. Please try, and tell us what speed improvement you gained. > > We should now (perhaps) remove -Xprefer:source, and let javac pickup already compiled classes from the (correct?) class path. > > However, this begets the question why -Xprefer:source was added in the first place. If I remember correctly, > this was over a year ago. It turns out that the default behavior for implicit compilation (which is necessary for sjavac:s multi core support) > is to not recompile java source files when the class has a more recent timestamp than the source file. > Sounds reasonable, until you realize that javac also takes into account the timestamps in rt.jar inside the jdk. > Soooo, if you check out the source code on Monday, then download a newly built jdk on tuesday, > and use this as the boot jdk, then the rt. jar timestamps will be newer than the source files you are trying to > compile, and this somehow messes up the build! You just described why we added -Xprefer:source. The timestamps on imported jdks (rt.jar etc.) should be ignored and the source should always be favored. The alternative was to touch all your java source files everytime the import or boot jdk changes. It's been a while, but I think that was the story. -kto > > Perhaps this is only relevant when compiling langtools where there are other bootstrap intricasies. > Perhaps not. Any masters of the javac universe out there who can help resolve this conundrum? > > //Fredrik > > From kelly.ohair at oracle.com Wed Sep 12 18:49:35 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Sep 2012 11:49:35 -0700 Subject: The future of partial builds In-Reply-To: <504F3EB2.4090706@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> Message-ID: <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> Some stats on incremental builds. Not partial builds.. This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: -- Build times ---------- Target Start 2012-09-12 10:56:17 End 2012-09-12 11:09:55 00:00:30 corba 00:04:51 hotspot 00:00:23 jaxp 00:00:33 jaxws 00:04:43 jdk 00:01:59 jdk-images 00:00:39 langtools 00:13:38 TOTAL ------------------------- A repeated 'gmake images" with no changes took 31 seconds: -- Build times ---------- Target Start 2012-09-12 11:13:30 End 2012-09-12 11:14:01 00:00:02 corba 00:00:07 hotspot 00:00:02 jaxp 00:00:04 jaxws 00:00:08 jdk 00:00:07 jdk-images 00:00:01 langtools 00:00:31 TOTAL ------------------------- I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) and it took 2 minutes (this will improve significantly with smartjavac): -- Build times ---------- Target Start 2012-09-12 11:17:34 End 2012-09-12 11:19:32 00:00:00 corba 00:00:00 hotspot 00:00:00 jaxp 00:00:01 jaxws 00:01:56 jdk 00:00:01 langtools 00:01:58 TOTAL ------------------------- I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) and it took 37 seconds): -- Build times ---------- Target Start 2012-09-12 11:22:24 End 2012-09-12 11:23:01 00:00:00 corba 00:00:00 hotspot 00:00:00 jaxp 00:00:01 jaxws 00:00:35 jdk 00:00:01 langtools 00:00:37 TOTAL ------------------------- So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the new build-infra makefiles. The above builds are complete openjdk builds, with no import jdk needed, and no concerns about sync issues between jdk components (hotspot<->jdk). -kto On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: > Magnus, > > You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: > > $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) > $ make > > And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? > > Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). > > -- > best regards, > Anthony > > On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >> On 2012-09-10 14:13, Alan Bateman wrote: >>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >> These two can of course be combined. >> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >> /Magnus From igor.nekrestyanov at oracle.com Wed Sep 12 18:52:29 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 12 Sep 2012 11:52:29 -0700 Subject: The future of partial builds In-Reply-To: <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> Message-ID: <5050D9ED.7040904@oracle.com> What about windows? -igor On 9/12/12 11:49 AM, Kelly O'Hair wrote: > Some stats on incremental builds. Not partial builds.. > > This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch > for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: > > -- Build times ---------- > Target > Start 2012-09-12 10:56:17 > End 2012-09-12 11:09:55 > 00:00:30 corba > 00:04:51 hotspot > 00:00:23 jaxp > 00:00:33 jaxws > 00:04:43 jdk > 00:01:59 jdk-images > 00:00:39 langtools > 00:13:38 TOTAL > ------------------------- > > A repeated 'gmake images" with no changes took 31 seconds: > > -- Build times ---------- > Target > Start 2012-09-12 11:13:30 > End 2012-09-12 11:14:01 > 00:00:02 corba > 00:00:07 hotspot > 00:00:02 jaxp > 00:00:04 jaxws > 00:00:08 jdk > 00:00:07 jdk-images > 00:00:01 langtools > 00:00:31 TOTAL > ------------------------- > > I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) > and it took 2 minutes (this will improve significantly with smartjavac): > > -- Build times ---------- > Target > Start 2012-09-12 11:17:34 > End 2012-09-12 11:19:32 > 00:00:00 corba > 00:00:00 hotspot > 00:00:00 jaxp > 00:00:01 jaxws > 00:01:56 jdk > 00:00:01 langtools > 00:01:58 TOTAL > ------------------------- > > I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) > and it took 37 seconds): > > -- Build times ---------- > Target > Start 2012-09-12 11:22:24 > End 2012-09-12 11:23:01 > 00:00:00 corba > 00:00:00 hotspot > 00:00:00 jaxp > 00:00:01 jaxws > 00:00:35 jdk > 00:00:01 langtools > 00:00:37 TOTAL > ------------------------- > > So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. > > I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the > new build-infra makefiles. > > The above builds are complete openjdk builds, with no import jdk needed, and no concerns about > sync issues between jdk components (hotspot<->jdk). > > -kto > > > On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: > >> Magnus, >> >> You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: >> >> $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) >> $ make >> >> And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? >> >> Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). >> >> -- >> best regards, >> Anthony >> >> On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >>> On 2012-09-10 14:13, Alan Bateman wrote: >>>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >>> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >>> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >>> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >>> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >>> These two can of course be combined. >>> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >>> /Magnus From kelly.ohair at oracle.com Wed Sep 12 18:52:57 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Sep 2012 11:52:57 -0700 Subject: The future of partial builds In-Reply-To: <5050B022.3010509@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> <5050B022.3010509@oracle.com> Message-ID: <5513BCC2-76C4-44A6-A6A9-936AB68499C6@oracle.com> On Sep 12, 2012, at 8:54 AM, Jonathan Gibbons wrote: > On 09/11/2012 10:46 PM, Fredrik ?hrstr?m wrote: >> However, this begets the question why -Xprefer:source was added in the first place. If I remember correctly, >> this was over a year ago. It turns out that the default behavior for implicit compilation (which is necessary for sjavac:s multi core support) >> is to not recompile java source files when the class has a more recent timestamp than the source file. >> Sounds reasonable, until you realize that javac also takes into account the timestamps in rt.jar inside the jdk. >> Soooo, if you check out the source code on Monday, then download a newly built jdk on tuesday, >> and use this as the boot jdk, then the rt. jar timestamps will be newer than the source files you are trying to >> compile, and this somehow messes up the build! > > When you are compiling JDK, you should not be reading or in any way dependent of the bootdir rt.jar (except insofar as it is needed to execute javac itself.) The compilation itself should not read bootdir rt.jar. Indeed, you should be able to set -Xbootclasspath to build/PLATFORM-ARCH/classes, which will initially be empty. > > -- Jon As I recall, I thought it was corba or jaxp or jaxws that needed needed -Xprefer:source because those early compiles could not just leave out the boot rt.jar??? -kto From kelly.ohair at oracle.com Wed Sep 12 20:32:25 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Sep 2012 13:32:25 -0700 Subject: The future of partial builds In-Reply-To: <5050D9ED.7040904@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> <5050D9ED.7040904@oracle.com> Message-ID: <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the machine used (hardware vs. VM), how many CPUs etc. But it's a bit erratic, depends on lots of things. We are still working around some CYGWIN issues. The incremental builds should be similar. I don't have any numbers right now. We hope we can get MinGW/MSYS working which might reduce the overall time by 20% or more (a big guess) (Remember MKS will not work with the new build-infra Makefiles). Windows XP 32bit builds take a bit longer maybe 35mins?, but the XP systems have limited RAM and cpu capacity. Solaris, Linux, and Mac builds are pretty consistent, but Windows is another story. :^( What we have noticed is that a beefy PC running Windows XP can easily do 20min builds, but building in an area that is immune from On-Access AntiVirus scanning or turning On-Access scanning off. -kto On Sep 12, 2012, at 11:52 AM, Igor Nekrestyanov wrote: > What about windows? > > -igor > > On 9/12/12 11:49 AM, Kelly O'Hair wrote: >> Some stats on incremental builds. Not partial builds.. >> >> This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch >> for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: >> >> -- Build times ---------- >> Target >> Start 2012-09-12 10:56:17 >> End 2012-09-12 11:09:55 >> 00:00:30 corba >> 00:04:51 hotspot >> 00:00:23 jaxp >> 00:00:33 jaxws >> 00:04:43 jdk >> 00:01:59 jdk-images >> 00:00:39 langtools >> 00:13:38 TOTAL >> ------------------------- >> >> A repeated 'gmake images" with no changes took 31 seconds: >> >> -- Build times ---------- >> Target >> Start 2012-09-12 11:13:30 >> End 2012-09-12 11:14:01 >> 00:00:02 corba >> 00:00:07 hotspot >> 00:00:02 jaxp >> 00:00:04 jaxws >> 00:00:08 jdk >> 00:00:07 jdk-images >> 00:00:01 langtools >> 00:00:31 TOTAL >> ------------------------- >> >> I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) >> and it took 2 minutes (this will improve significantly with smartjavac): >> >> -- Build times ---------- >> Target >> Start 2012-09-12 11:17:34 >> End 2012-09-12 11:19:32 >> 00:00:00 corba >> 00:00:00 hotspot >> 00:00:00 jaxp >> 00:00:01 jaxws >> 00:01:56 jdk >> 00:00:01 langtools >> 00:01:58 TOTAL >> ------------------------- >> >> I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) >> and it took 37 seconds): >> >> -- Build times ---------- >> Target >> Start 2012-09-12 11:22:24 >> End 2012-09-12 11:23:01 >> 00:00:00 corba >> 00:00:00 hotspot >> 00:00:00 jaxp >> 00:00:01 jaxws >> 00:00:35 jdk >> 00:00:01 langtools >> 00:00:37 TOTAL >> ------------------------- >> >> So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. >> >> I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the >> new build-infra makefiles. >> >> The above builds are complete openjdk builds, with no import jdk needed, and no concerns about >> sync issues between jdk components (hotspot<->jdk). >> >> -kto >> >> >> On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: >> >>> Magnus, >>> >>> You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: >>> >>> $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) >>> $ make >>> >>> And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? >>> >>> Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >>>> On 2012-09-10 14:13, Alan Bateman wrote: >>>>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >>>> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >>>> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >>>> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >>>> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >>>> These two can of course be combined. >>>> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >>>> /Magnus > From fredrik.ohrstrom at oracle.com Wed Sep 12 21:00:05 2012 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 12 Sep 2012 23:00:05 +0200 Subject: The future of partial builds In-Reply-To: <5513BCC2-76C4-44A6-A6A9-936AB68499C6@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F51D5.2060605@oracle.com> <504F983B.9010303@oracle.com> <3EB4EB0E-455F-40AB-A786-AED6CF1D9174@oracle.com> <5050B022.3010509@oracle.com> <5513BCC2-76C4-44A6-A6A9-936AB68499C6@oracle.com> Message-ID: <8596B362-4B10-49E3-B265-6C79CC4FB117@oracle.com> Oookay, long story, this was when we used jdk6 to build jdk7, same kind of problem could occur when using jdk7 to build jdk8: jdk7javac used new features and classes in jdk7, for example: java/util/Objects.java java/util/ConcurrentModificationException.java java/io/File.java java/nio/file/* java/nio/channels/AsynchronousChannel.java java/nio/channels/AsynchronousFileChannel.java java/nio/channels/CompletionHandler.java java/nio/channels/SeekableByteChannel.java However first a bootstrapjdk7javac (that can be run using jdk6) was compiled, which was easy since it only needed to avoid com/sun/tools/javac/nio/.... Then we want to use bootstrapjdk7javac to compile a full jdk7javac, at this moment, the classes above had to be found by the bootstrapjdk7javac. To avoid the risk of recursing into far to many jdk classes, we use GenStubs to create stripped down source files for the above classes. Thus -sourcepath points to the generated stubs for the above classes. Now the GenStubs tool itself depends a bit on jdk7javac! Really? Yes, really. Thus to compile the GenStubs tool using jdk6javac you needed -sourcepath jdk7javacsource so that GenStubs could find the odd parts it needed. (And yes, those parts did of course not refer to the new jdk7 classes above. :-) ) In particular, one of those needed parts was RESOURCE_VARIABLE inside javax.lang.model.element.ElementKind which was new for jdk7. However javax.lang.model.element.ElementKind was already available to jdk6javac since it is part of the tools.jar that is used to run jdk6javac and depending on the timestamps inside the jdk6 rt.jar file, jdk6javac could pickup either the new ElementKind that had RESOURCE_VARIABLE from the source path, or the old ElementKind from jdk6 rt.jar that did not. Cleaning out the bootclasspath does not work here, since we need access to Object,String etc from jdk6 to be able to compile/run GenStubs using jdk6. So the only remaining option was to add -Xprefer:source. But this is the only place where -Xprefer:source is necessary. In fact, for the moment it is not necessary, since there is no real difference in dependencies between jdk7javac and jdk8javac, GenStubs is still exercised on a dummy class, because we expect it to be used in the future. With this in mind, I just committed fixes to the Makefiles that do not use -Xprefer:source anywhere, except for GenStubs. The main jdk build, already used "-bootclasspath outputdir/classes". Other than that, corba/jaxp/jaxws and hotspot, can safely link against the boot jdk rt.jar, since they must not (can't) use any new features. Thus no need for bootclasspath or -Xprefer:source here. Corba does however use classes inside the tools.jar from the boot jdk. We could get rid of the dependency on the boot jdk tools.jar, if we compiled Corba as part of the big jdk build, or after the jdk build. Same thing with jaxp/jaxws/corba and the boot rt.jar. //Fredrik Here is Jims original mail that solved the first problem. --8<------------------------------------------------------------------------------------------------ Well, this is the most fun I've had in a long time :-) At least partly because there is no regression in JDK 6u27 as we had feared. One of the errors I got doing your compile command was an undefined symbol - RESOURCE_VARIABLE. This was added to javac file javax/lang/model/element/ElementKind.java/ElementKind.java in JDK 7, so it is in the JDK 7 version of ElementKind but is not in the JDK 6 version. ElementKind.class is located in the rt.jar file of a JDK. It as if when the 6u26 javac is used, the jdk 7 version of ElementKind is used whereas when the 6u27 javac is used, the jdk 6 version of Element Kind is used. To resolve a ref to a type, javac searches (not counting extension dirs): - bootclasspath for .class - sourcepath for .java - classpath for either Then javac looks at the result of the search: > A successful type search may produce a class file, a source file, or both. Here is how javac handles each situation: > * Search produces a class file but no source file: javac uses the class file. > * Search produces a source file but no class file: javac compiles the source file and uses the resulting class file. > * Search produces both a source file and a class file: javac determines whether the class file is out of date. If the class file is out of date, javac recompiles the source file and uses the updated class file. Otherwise, javac just uses the class file. > > javac considers a class file out of date only if it is older than the source file. So, in this case, javac finds - jdk 6 ElementKind.class in the rt.jar of the jdk - jdk 7 ElementKind.java under the -sourcepath And, javac looks at the creation times of the two to decide which to use. You guessed it: jar tfv j:/re/jdk/6u26/latest/binaries/windows-i586/jre/lib/rt.jar | fgrep ElementKind.class 1984 Wed May 04 01:04:44 PDT 2011 javax/lang/model/element/ElementKind.class jar tfv j:/re/jdk/6u27/latest/binaries/windows-i586/jre/lib/rt.jar | fgrep ElementKind.class 1984 Tue Jul 19 01:19:08 PDT 2011 javax/lang/model/element/ElementKind.class find src -name ElementKind.java -ls 2 -rwxr-xr-x 1 jjh None 3691 May 12 16:52 src/share/classes/javax/lang/model/element/ElementKind.java So, javac compiles the jdk 7 version of ElementKind.java when javac from 6u26 is used, but not when 6u27 is used :-) The solution (thanks to Jon) is to add -Xprefer:source to your javac command line. I suppose you could touch all the files in your repo, or re-clone and reapply your patches, but that is ugly and would just leave the door open for this sort of shenanigan to re-occur. - jjh --8<------------------------------------------------------------------------------------------------ From david.katleman at oracle.com Wed Sep 12 23:10:10 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:10:10 +0000 Subject: hg: jdk8/build: Added tag jdk8-b55 for changeset b85b44cced24 Message-ID: <20120912231010.CB37E47A5B@hg.openjdk.java.net> Changeset: 76844579fa4b Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/76844579fa4b Added tag jdk8-b55 for changeset b85b44cced24 ! .hgtags From david.katleman at oracle.com Wed Sep 12 23:10:15 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:10:15 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b55 for changeset e8a0e84383d6 Message-ID: <20120912231016.DE3D347A5C@hg.openjdk.java.net> Changeset: bf1bb47414e1 Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/bf1bb47414e1 Added tag jdk8-b55 for changeset e8a0e84383d6 ! .hgtags From david.katleman at oracle.com Wed Sep 12 23:12:07 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:12:07 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b55 for changeset af0c8a080851 Message-ID: <20120912231212.E79F847A5D@hg.openjdk.java.net> Changeset: 6124ff421829 Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6124ff421829 Added tag jdk8-b55 for changeset af0c8a080851 ! .hgtags From david.katleman at oracle.com Wed Sep 12 23:13:30 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:13:30 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b55 for changeset 7c2363666890 Message-ID: <20120912231334.48F5047A5E@hg.openjdk.java.net> Changeset: f19d63b2119a Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/f19d63b2119a Added tag jdk8-b55 for changeset 7c2363666890 ! .hgtags From david.katleman at oracle.com Wed Sep 12 23:13:39 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:13:39 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b55 for changeset 109c9e1f2d85 Message-ID: <20120912231343.3EB9447A5F@hg.openjdk.java.net> Changeset: 7813455ccdb0 Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/7813455ccdb0 Added tag jdk8-b55 for changeset 109c9e1f2d85 ! .hgtags From david.katleman at oracle.com Wed Sep 12 23:15:25 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:15:25 +0000 Subject: hg: jdk8/build/jdk: 35 new changesets Message-ID: <20120912232302.6977247A60@hg.openjdk.java.net> Changeset: 1fb204840512 Author: katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1fb204840512 Added tag jdk8-b55 for changeset 1f3f4b333341 ! .hgtags Changeset: b4f7ef73dfe8 Author: skovatch Date: 2012-09-05 09:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b4f7ef73dfe8 7187834: [macosx] Usage of private API in macosx 2D implementation causes Apple Store rejection Reviewed-by: prr, igor ! src/macosx/native/sun/awt/ImageSurfaceData.h ! src/macosx/native/sun/awt/ImageSurfaceData.m ! src/macosx/native/sun/awt/QuartzRenderer.m ! src/macosx/native/sun/awt/QuartzSurfaceData.m Changeset: 2f0385880af9 Author: lana Date: 2012-09-05 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2f0385880af9 Merge - make/sun/beans/Makefile - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/java/lang/invoke/MaxTest.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java Changeset: e23311e924b1 Author: alexsch Date: 2012-08-29 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e23311e924b1 7171045: [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 9201b1df64e6 Author: leonidr Date: 2012-08-29 19:53 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9201b1df64e6 7124375: [macosx] Focus isn't transfered as expected between components Reviewed-by: art, ant, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/sun/awt/HToolkit.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 63d52eb20ce2 Author: denis Date: 2012-08-30 01:17 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/63d52eb20ce2 7192887: java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) Reviewed-by: ant, serb ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 973693566c46 Author: malenkov Date: 2012-08-31 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/973693566c46 7192955: Introspector overide PropertyDescriptor for generic type field defined in super class Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7192955.java Changeset: b291b6d220c7 Author: malenkov Date: 2012-08-31 14:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b291b6d220c7 7186794: Setter not found. PropertyDescriptor(PropertyDescriptor,PropertyDescriptor) Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7186794.java ! test/java/beans/Introspector/Test7189112.java Changeset: 0e007aa6f9db Author: ant Date: 2012-08-31 16:31 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0e007aa6f9db 6981400: Tabbing between textfield do not work properly when ALT+TAB 7157015: [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing. 7121442: Regression : Reopen CR 6458497 still reproducible using JDK 7. Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/awt/TimedWindowEvent.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/native/sun/windows/awt_Window.cpp + test/java/awt/Focus/6981400/Test1.java + test/java/awt/Focus/6981400/Test2.java + test/java/awt/Focus/6981400/Test3.java Changeset: 2e21ec4be419 Author: malenkov Date: 2012-09-04 13:12 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2e21ec4be419 7169395: Exception throws due to the changes in JDK 7 object tranversal and break backward compatibility Reviewed-by: art ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test7169395.java Changeset: 8cd13c3a78e6 Author: malenkov Date: 2012-09-04 20:50 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8cd13c3a78e6 7195106: REGRESSION : There is no way to get Icon inf, once Softreference is released Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java + test/java/beans/Introspector/Test7195106.java Changeset: 8ce89b1bc0a1 Author: serb Date: 2012-09-05 21:40 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8ce89b1bc0a1 7124523: [macosx] b216: Mising part of applet UI Reviewed-by: denis, alexsch ! src/share/demo/applets/CardTest/example1.html ! src/share/demo/applets/DitherTest/example1.html Changeset: 7cbbaf670b57 Author: lana Date: 2012-09-05 17:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7cbbaf670b57 Merge - make/sun/beans/Makefile ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java - src/share/classes/java/lang/annotation/ContainerAnnotation.java - src/share/classes/java/text/BreakDictionary.java - src/share/classes/java/text/CollationRules.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java - src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java - src/share/classes/sun/text/resources/thai_dict - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - test/java/lang/invoke/MaxTest.java Changeset: 640e8e1eb0d8 Author: lana Date: 2012-09-05 20:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/640e8e1eb0d8 Merge Changeset: c4c69b4d9ace Author: weijun Date: 2012-08-29 11:03 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c4c69b4d9ace 7184815: [macosx] Need to read Kerberos config in files Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: cf492d1199dc Author: dxu Date: 2012-08-30 12:55 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cf492d1199dc 7193710: ByteArrayOutputStream Javadoc contains unclosed element Reviewed-by: dholmes, alanb, ulfzibis ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/InputStreamReader.java Changeset: 11bfec75d333 Author: lancea Date: 2012-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/11bfec75d333 7193683: DriverManager Iterator Warning cleanup Reviewed-by: lancea Contributed-by: Dan Xu ! src/share/classes/java/sql/DriverManager.java Changeset: 0a2565113920 Author: mullan Date: 2012-08-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0a2565113920 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory Reviewed-by: mullan, vinnie Contributed-by: stephen.flores at oracle.com ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 47f8ba39265c Author: mullan Date: 2012-08-30 14:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/47f8ba39265c Merge Changeset: 334b6f0c547f Author: lana Date: 2012-08-30 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/334b6f0c547f Merge Changeset: f9b11772c4b2 Author: smarks Date: 2012-08-30 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f9b11772c4b2 7195099: update problem list with RMI test failures Reviewed-by: alanb ! test/ProblemList.txt Changeset: bdfcc13ddeb4 Author: jfranck Date: 2012-08-31 10:52 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bdfcc13ddeb4 7151010: Add compiler support for repeating annotations Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainerFor.java Changeset: da1436b21bc2 Author: coffeys Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/da1436b21bc2 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Reviewed-by: chegar ! test/com/sun/corba/cachedSocket/7056731.sh Changeset: 33f8ca2b4ba3 Author: alanb Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/33f8ca2b4ba3 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Reviewed-by: chegar ! test/java/nio/file/Files/CopyAndMove.java Changeset: 3338019fda8a Author: sla Date: 2009-06-19 16:50 +0300 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3338019fda8a 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value Reviewed-by: alanb, dholmes, sla Contributed-by: Dmytro Sheyko ! src/windows/native/com/sun/management/OperatingSystem_md.c + test/com/sun/management/OperatingSystemMXBean/MemoryStatusOverflow.java Changeset: b7b33a3c9df0 Author: xuelei Date: 2012-09-04 02:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b7b33a3c9df0 7195733: TEST_BUG: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java failing Reviewed-by: chegar, alanb, xuelei Contributed-by: Eric Wang ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 7dda50fe8e1c Author: jjg Date: 2012-09-04 12:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7dda50fe8e1c 7195519: OutOfMemoryError in docs build after 7151010 Reviewed-by: darcy ! make/docs/Makefile Changeset: 5ca450af2a9e Author: sla Date: 2012-09-05 14:42 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5ca450af2a9e 6963102: Testcase failures sun/tools/jstatd/jstatdExternalRegistry.sh and sun/tools/jstatd/jstatdDefaults.sh Summary: Make tests more resilient by allowing for more error messages from jps Reviewed-by: alanb, rbackman, dsamersoff ! test/sun/tools/jstatd/jpsOutput1.awk Changeset: e129833555f6 Author: valeriep Date: 2012-09-04 18:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e129833555f6 7044060: Need to support NSA Suite B Cryptography algorithms Summary: Add support for DSA parameter generation and OIDs for NSA Suite B algorithms. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java + src/share/classes/java/security/spec/DSAGenParameterSpec.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/com/sun/crypto/provider/KeyAgreement/TestExponentSize.java + test/sun/security/pkcs11/ec/TestECDH2.java + test/sun/security/pkcs11/ec/TestECDSA2.java + test/sun/security/provider/DSA/TestAlgParameterGenerator.java + test/sun/security/provider/DSA/TestDSA2.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java Changeset: cc5a6c4d600e Author: valeriep Date: 2012-09-05 10:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cc5a6c4d600e Merge Changeset: c39370c75d63 Author: lana Date: 2012-09-05 11:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c39370c75d63 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java Changeset: f1838d040cc7 Author: ksrini Date: 2012-09-05 11:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f1838d040cc7 7194005: (launcher) needs to be enhanced for 64-bit jar file handling Reviewed-by: darcy, sherman ! src/share/bin/jli_util.h ! src/share/bin/manifest_info.h ! src/share/bin/parse_manifest.c ! src/solaris/bin/jexec.c + test/tools/launcher/BigJar.java ! test/tools/launcher/TestHelper.java Changeset: 6b7d23a2ba72 Author: lana Date: 2012-09-05 20:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6b7d23a2ba72 Merge Changeset: 06094fdc1f4d Author: lana Date: 2012-09-10 17:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/06094fdc1f4d Merge Changeset: 2e9eeef2909b Author: katleman Date: 2012-09-12 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2e9eeef2909b Merge From david.katleman at oracle.com Wed Sep 12 23:24:52 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 12 Sep 2012 23:24:52 +0000 Subject: hg: jdk8/build/langtools: 5 new changesets Message-ID: <20120912232504.907E447A61@hg.openjdk.java.net> Changeset: 0f8cf3d89a7c Author: katleman Date: 2012-09-06 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/0f8cf3d89a7c Added tag jdk8-b55 for changeset e48e7e1f026b ! .hgtags Changeset: 873ddd9f4900 Author: jfranck Date: 2012-08-31 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/873ddd9f4900 7151010: Add compiler support for repeating annotations Reviewed-by: jjg, mcimadamore + src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java + test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java + test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java + test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java + test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java + test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java + test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java + test/tools/javac/diags/examples/ContainedByInheritedMismatch.java + test/tools/javac/diags/examples/ContainedByNoValue.java + test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/ContainedByRetentionMismatch.java + test/tools/javac/diags/examples/ContainedByTargetMismatch.java + test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationJava8.java + test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java + test/tools/javac/diags/examples/WrongContainedBy.java + test/tools/javac/diags/examples/WrongContainerFor.java Changeset: 3673c811be1c Author: jjh Date: 2012-09-05 08:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3673c811be1c 7185778: javah error "Not a valid class name" on class names with dollar signs Reviewed-by: jjg ! src/share/classes/com/sun/tools/javah/JavahTask.java + test/tools/javah/T7185778.java Changeset: 3f36e22c8c39 Author: lana Date: 2012-09-05 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3f36e22c8c39 Merge Changeset: 363e9198b9de Author: lana Date: 2012-09-10 17:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/363e9198b9de Merge From weijun.wang at oracle.com Wed Sep 12 23:51:24 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 13 Sep 2012 07:51:24 +0800 Subject: The future of partial builds In-Reply-To: <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> <5050D9ED.7040904@oracle.com> <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> Message-ID: <50511FFC.7010007@oracle.com> Windows X64 in VM can build within 25mins? That's quite impressive. Can you share what VM/OS/CPU/mem you are using? I only have VirtualBox running on Linux X64 now, but will consider moving to some other platforms if it helps a lot. Thanks Max On 09/13/2012 04:32 AM, Kelly O'Hair wrote: > Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the machine used (hardware vs. VM), > how many CPUs etc. But it's a bit erratic, depends on lots of things. We are still working around some CYGWIN issues. > The incremental builds should be similar. I don't have any numbers right now. > > We hope we can get MinGW/MSYS working which might reduce the overall time by 20% or more (a big guess) > (Remember MKS will not work with the new build-infra Makefiles). > > Windows XP 32bit builds take a bit longer maybe 35mins?, but the XP systems have limited RAM and cpu capacity. > Solaris, Linux, and Mac builds are pretty consistent, but Windows is another story. :^( > > What we have noticed is that a beefy PC running Windows XP can easily do 20min builds, but building in > an area that is immune from On-Access AntiVirus scanning or turning On-Access scanning off. > > -kto > > On Sep 12, 2012, at 11:52 AM, Igor Nekrestyanov wrote: > >> What about windows? >> >> -igor >> >> On 9/12/12 11:49 AM, Kelly O'Hair wrote: >>> Some stats on incremental builds. Not partial builds.. >>> >>> This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch >>> for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 10:56:17 >>> End 2012-09-12 11:09:55 >>> 00:00:30 corba >>> 00:04:51 hotspot >>> 00:00:23 jaxp >>> 00:00:33 jaxws >>> 00:04:43 jdk >>> 00:01:59 jdk-images >>> 00:00:39 langtools >>> 00:13:38 TOTAL >>> ------------------------- >>> >>> A repeated 'gmake images" with no changes took 31 seconds: >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:13:30 >>> End 2012-09-12 11:14:01 >>> 00:00:02 corba >>> 00:00:07 hotspot >>> 00:00:02 jaxp >>> 00:00:04 jaxws >>> 00:00:08 jdk >>> 00:00:07 jdk-images >>> 00:00:01 langtools >>> 00:00:31 TOTAL >>> ------------------------- >>> >>> I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) >>> and it took 2 minutes (this will improve significantly with smartjavac): >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:17:34 >>> End 2012-09-12 11:19:32 >>> 00:00:00 corba >>> 00:00:00 hotspot >>> 00:00:00 jaxp >>> 00:00:01 jaxws >>> 00:01:56 jdk >>> 00:00:01 langtools >>> 00:01:58 TOTAL >>> ------------------------- >>> >>> I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) >>> and it took 37 seconds): >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:22:24 >>> End 2012-09-12 11:23:01 >>> 00:00:00 corba >>> 00:00:00 hotspot >>> 00:00:00 jaxp >>> 00:00:01 jaxws >>> 00:00:35 jdk >>> 00:00:01 langtools >>> 00:00:37 TOTAL >>> ------------------------- >>> >>> So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. >>> >>> I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the >>> new build-infra makefiles. >>> >>> The above builds are complete openjdk builds, with no import jdk needed, and no concerns about >>> sync issues between jdk components (hotspot<->jdk). >>> >>> -kto >>> >>> >>> On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: >>> >>>> Magnus, >>>> >>>> You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: >>>> >>>> $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) >>>> $ make >>>> >>>> And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? >>>> >>>> Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >>>>> On 2012-09-10 14:13, Alan Bateman wrote: >>>>>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >>>>> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >>>>> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >>>>> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >>>>> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >>>>> These two can of course be combined. >>>>> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >>>>> /Magnus >> > From Alan.Bateman at oracle.com Thu Sep 13 11:12:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Sep 2012 12:12:48 +0100 Subject: The future of partial builds In-Reply-To: <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> Message-ID: <5051BFB0.9090805@oracle.com> On 12/09/2012 19:49, Kelly O'Hair wrote: > Some stats on incremental builds. Not partial builds.. > > This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch > for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: > > -- Build times ---------- > Target > Start 2012-09-12 10:56:17 > End 2012-09-12 11:09:55 > 00:00:30 corba > 00:04:51 hotspot > 00:00:23 jaxp > 00:00:33 jaxws > 00:04:43 jdk > 00:01:59 jdk-images > 00:00:39 langtools > 00:13:38 TOTAL > ------------------------- and on more modern sparc machines it's better again, here's what I see on a T4 with --with-num-cores=32 -- Build times ---------- Target Start 2012-09-13 11:41:22 End 2012-09-13 11:50:03 00:00:27 corba 00:02:42 hotspot 00:00:25 jaxp 00:00:31 jaxws 00:03:11 jdk 00:00:50 jdk-images 00:00:35 langtools 00:08:41 TOTAL ------------------------- It might not be identical to your build as I needed to --disable-debug-symbols and specify ENABLE_FULL_DEBUG_SYMBOLS=0 to workaround a gobjcopy bug on Solaris 11. -Alan. From anthony.petrov at oracle.com Thu Sep 13 13:11:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 13 Sep 2012 17:11:55 +0400 Subject: The future of partial builds In-Reply-To: <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> <5050D9ED.7040904@oracle.com> <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> Message-ID: <5051DB9B.4050302@oracle.com> The build times for incremental builds look awesome. Now I'm really looking forward to the new build system! Thanks! Regarding partial builds: as long as the other components don't add dependencies that we didn't use to have before (when working on the jdk repo only), I guess it's all right, too. -- best regards, Anthony On 09/13/12 00:32, Kelly O'Hair wrote: > Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the machine used (hardware vs. VM), > how many CPUs etc. But it's a bit erratic, depends on lots of things. We are still working around some CYGWIN issues. > The incremental builds should be similar. I don't have any numbers right now. > > We hope we can get MinGW/MSYS working which might reduce the overall time by 20% or more (a big guess) > (Remember MKS will not work with the new build-infra Makefiles). > > Windows XP 32bit builds take a bit longer maybe 35mins?, but the XP systems have limited RAM and cpu capacity. > Solaris, Linux, and Mac builds are pretty consistent, but Windows is another story. :^( > > What we have noticed is that a beefy PC running Windows XP can easily do 20min builds, but building in > an area that is immune from On-Access AntiVirus scanning or turning On-Access scanning off. > > -kto > > On Sep 12, 2012, at 11:52 AM, Igor Nekrestyanov wrote: > >> What about windows? >> >> -igor >> >> On 9/12/12 11:49 AM, Kelly O'Hair wrote: >>> Some stats on incremental builds. Not partial builds.. >>> >>> This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch >>> for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 10:56:17 >>> End 2012-09-12 11:09:55 >>> 00:00:30 corba >>> 00:04:51 hotspot >>> 00:00:23 jaxp >>> 00:00:33 jaxws >>> 00:04:43 jdk >>> 00:01:59 jdk-images >>> 00:00:39 langtools >>> 00:13:38 TOTAL >>> ------------------------- >>> >>> A repeated 'gmake images" with no changes took 31 seconds: >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:13:30 >>> End 2012-09-12 11:14:01 >>> 00:00:02 corba >>> 00:00:07 hotspot >>> 00:00:02 jaxp >>> 00:00:04 jaxws >>> 00:00:08 jdk >>> 00:00:07 jdk-images >>> 00:00:01 langtools >>> 00:00:31 TOTAL >>> ------------------------- >>> >>> I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) >>> and it took 2 minutes (this will improve significantly with smartjavac): >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:17:34 >>> End 2012-09-12 11:19:32 >>> 00:00:00 corba >>> 00:00:00 hotspot >>> 00:00:00 jaxp >>> 00:00:01 jaxws >>> 00:01:56 jdk >>> 00:00:01 langtools >>> 00:01:58 TOTAL >>> ------------------------- >>> >>> I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) >>> and it took 37 seconds): >>> >>> -- Build times ---------- >>> Target >>> Start 2012-09-12 11:22:24 >>> End 2012-09-12 11:23:01 >>> 00:00:00 corba >>> 00:00:00 hotspot >>> 00:00:00 jaxp >>> 00:00:01 jaxws >>> 00:00:35 jdk >>> 00:00:01 langtools >>> 00:00:37 TOTAL >>> ------------------------- >>> >>> So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. >>> >>> I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the >>> new build-infra makefiles. >>> >>> The above builds are complete openjdk builds, with no import jdk needed, and no concerns about >>> sync issues between jdk components (hotspot<->jdk). >>> >>> -kto >>> >>> >>> On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: >>> >>>> Magnus, >>>> >>>> You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: >>>> >>>> $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) >>>> $ make >>>> >>>> And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? >>>> >>>> Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >>>>> On 2012-09-10 14:13, Alan Bateman wrote: >>>>>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >>>>> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >>>>> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >>>>> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >>>>> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >>>>> These two can of course be combined. >>>>> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >>>>> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Sep 14 13:39:02 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Sep 2012 15:39:02 +0200 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <4FB10306.3090206@oracle.com> References: <4FB10306.3090206@oracle.com> Message-ID: <50533376.3000809@oracle.com> I'd like to make a new try at integrating this fix. :-) I posted two a webrev back in May. After some feedback, I posted a second one at http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. This second webrev was reviewed and accepted by David Holmes, Dmitry Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair expressed concern that it would not work on Windows due to changes in make/defs.make being problematic for Windows nmake. Also, in private conversation with me, Kelly found build problems on MacOSX. I didn't have time at the moment to address those issues, so I dropped it for the time being. However, I now checked more carefully. I'm not using any syntax in defs.make that is not already there, so I shouldn't introduce something Windows can't handle. The patch did have a problem though -- the TEST_IN_BUILD argument was not properly propagated. So I have made a new patch (third time's a charm!), and the webrev is here: http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ The only difference to the previous one is that I add TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to be done three times, once for each duplicated platform file...) I am currently running a series of tests on all platforms, both using the old build system and the new. Not all tests have finished running, but it's looking good so far and I believe there should be no more problems. (I'll let you know otherwise! :)) It feels like what should be a simple fix has grown somewhat out of proportion. I'm hoping I can get some final reviews on this, and some advice as to wether this fix should be integrated through the hotspot or the build forest. (On one hand, it's hotspot only, but on the other hand, it's just affecting build.) /Magnus On 2012-05-14 15:05, Magnus Ihse Bursie wrote: > As part of the new build system created in the build-infra project, we > want to make it a configurable option wether or not to run the Queens > test as part of the build. > > Here is a patch that introduces a new make variable, TEST_IN_BUILD, > which controls wether to run the Queens test (test_gamma.sh) or not. > If the variable is not explicitely set, it will default to true, > mening that the default behaviour will be as before, that is, to run > the Queens test. However, if you (or configure) explicitely set it to > false, the Queens test will be skipped. > > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 > > /Magnus > From david.holmes at oracle.com Fri Sep 14 13:54:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2012 23:54:23 +1000 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <50533376.3000809@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> Message-ID: <5053370F.2060109@oracle.com> Magnus, This still looks okay to me. My main annoyance is the proliferation of the condition check and the duplication. I know this has taken far too much time already but it seems to me that we should be able to factor: + ifeq ($(TEST_IN_BUILD),true) cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && ./test_gamma + endif into a function so that we do: $(eval $(call do-test-gamma, dir) where we pass in the target specific directory. And of course the function does nothing if TEST_IN_BUILD is not set. Just a thought. David On 14/09/2012 11:39 PM, Magnus Ihse Bursie wrote: > I'd like to make a new try at integrating this fix. :-) > > I posted two a webrev back in May. After some feedback, I posted a > second one at > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. > This second webrev was reviewed and accepted by David Holmes, Dmitry > Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair > expressed concern that it would not work on Windows due to changes in > make/defs.make being problematic for Windows nmake. Also, in private > conversation with me, Kelly found build problems on MacOSX. > > I didn't have time at the moment to address those issues, so I dropped > it for the time being. > > However, I now checked more carefully. I'm not using any syntax in > defs.make that is not already there, so I shouldn't introduce something > Windows can't handle. > > The patch did have a problem though -- the TEST_IN_BUILD argument was > not properly propagated. So I have made a new patch (third time's a > charm!), and the webrev is here: > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ > > The only difference to the previous one is that I add > TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to > be done three times, once for each duplicated platform file...) > > I am currently running a series of tests on all platforms, both using > the old build system and the new. Not all tests have finished running, > but it's looking good so far and I believe there should be no more > problems. (I'll let you know otherwise! :)) > > It feels like what should be a simple fix has grown somewhat out of > proportion. I'm hoping I can get some final reviews on this, and some > advice as to wether this fix should be integrated through the hotspot or > the build forest. (On one hand, it's hotspot only, but on the other > hand, it's just affecting build.) > > /Magnus > > > On 2012-05-14 15:05, Magnus Ihse Bursie wrote: >> As part of the new build system created in the build-infra project, we >> want to make it a configurable option wether or not to run the Queens >> test as part of the build. >> >> Here is a patch that introduces a new make variable, TEST_IN_BUILD, >> which controls wether to run the Queens test (test_gamma.sh) or not. >> If the variable is not explicitely set, it will default to true, >> mening that the default behaviour will be as before, that is, to run >> the Queens test. However, if you (or configure) explicitely set it to >> false, the Queens test will be skipped. >> >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 >> >> /Magnus >> > > From magnus.ihse.bursie at oracle.com Fri Sep 14 13:59:30 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Sep 2012 15:59:30 +0200 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <5053370F.2060109@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> <5053370F.2060109@oracle.com> Message-ID: <50533842.7040406@oracle.com> On 2012-09-14 15:54, David Holmes wrote: > Magnus, > > This still looks okay to me. My main annoyance is the proliferation of > the condition check and the duplication. I know this has taken far too > much time already but it seems to me that we should be able to factor: > > + ifeq ($(TEST_IN_BUILD),true) > cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && ./test_gamma > + endif > > into a function so that we do: > > $(eval $(call do-test-gamma, dir) > > where we pass in the target specific directory. And of course the > function does nothing if TEST_IN_BUILD is not set. > > Just a thought. I'd rather not do that. The problem with duplication starts on an even higher level -- we have three files that do basically the same thing, and then in each of these, we have six stanzas that do basically the same thing. Trying to remove the duplication in these stanzas, but keeping the duplicate stanzas and the duplicate files is like the proverbial porcine makeup. But it adds more risk to the fix, and I'll have to re-run all testing. /Magnus From kelly.ohair at oracle.com Fri Sep 14 22:44:04 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 14 Sep 2012 15:44:04 -0700 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <50533376.3000809@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> Message-ID: <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> It should get integrated through the hotspot-rt forest. Let me know if you need me to do that. http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/bsd/makefiles/buildtree.make.sdiff.html http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/linux/makefiles/buildtree.make.sdiff.html http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/solaris/makefiles/buildtree.make.sdiff.html Has some cross compiling changes removed? Otherwise looks fine. I agree that the duplication is ugly, but I also agree with you that these hotspot Makefiles are riddles with duplication at a high level -kto On Sep 14, 2012, at 6:39 AM, Magnus Ihse Bursie wrote: > I'd like to make a new try at integrating this fix. :-) > > I posted two a webrev back in May. After some feedback, I posted a second one at http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. This second webrev was reviewed and accepted by David Holmes, Dmitry Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair expressed concern that it would not work on Windows due to changes in make/defs.make being problematic for Windows nmake. Also, in private conversation with me, Kelly found build problems on MacOSX. > > I didn't have time at the moment to address those issues, so I dropped it for the time being. > > However, I now checked more carefully. I'm not using any syntax in defs.make that is not already there, so I shouldn't introduce something Windows can't handle. > > The patch did have a problem though -- the TEST_IN_BUILD argument was not properly propagated. So I have made a new patch (third time's a charm!), and the webrev is here: > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ > > The only difference to the previous one is that I add TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to be done three times, once for each duplicated platform file...) > > I am currently running a series of tests on all platforms, both using the old build system and the new. Not all tests have finished running, but it's looking good so far and I believe there should be no more problems. (I'll let you know otherwise! :)) > > It feels like what should be a simple fix has grown somewhat out of proportion. I'm hoping I can get some final reviews on this, and some advice as to wether this fix should be integrated through the hotspot or the build forest. (On one hand, it's hotspot only, but on the other hand, it's just affecting build.) > > /Magnus > > > On 2012-05-14 15:05, Magnus Ihse Bursie wrote: >> As part of the new build system created in the build-infra project, we want to make it a configurable option wether or not to run the Queens test as part of the build. >> >> Here is a patch that introduces a new make variable, TEST_IN_BUILD, which controls wether to run the Queens test (test_gamma.sh) or not. If the variable is not explicitely set, it will default to true, mening that the default behaviour will be as before, that is, to run the Queens test. However, if you (or configure) explicitely set it to false, the Queens test will be skipped. >> >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 >> >> /Magnus >> > > From kelly.ohair at oracle.com Sat Sep 15 00:26:29 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 14 Sep 2012 17:26:29 -0700 Subject: The future of partial builds In-Reply-To: <50511FFC.7010007@oracle.com> References: <504DCE52.5080804@oracle.com> <504DD95D.5060600@oracle.com> <504DF280.9010505@oracle.com> <504F3EB2.4090706@oracle.com> <8B44CA14-4AF1-4F35-ACA9-82CCC74CA919@oracle.com> <5050D9ED.7040904@oracle.com> <25CFCF8D-8D19-43CD-84B5-CEDBC3D62AA6@oracle.com> <50511FFC.7010007@oracle.com> Message-ID: <3F1EB0C1-9F21-4C01-86A6-EC2AB9C7B276@oracle.com> The best times I have gotten have been with the VMs in Stockholm, VMware base, 4 vcpus, lots of RAM. I don't have any newer raw hardware, just VMs. However, as I stated, it's erratic. We have some issues somewhere. I think Erik has gotten even faster times with his beefy desktop, not sure what the configuration was. We suspect issues with older versions of cygwin, I'd recommend 1.7.16+. And we are also looking into MinGW/MSYS use, which might be (cross your fingers) 20% faster. Windows has been very frustrating in terms of predictability as we push the parallelism hard in the builds. So with Windows, we are looking for the right formula that gets us really reliable predictable builds, and that could take a little time. -kto On Sep 12, 2012, at 4:51 PM, Weijun Wang wrote: > Windows X64 in VM can build within 25mins? That's quite impressive. Can you share what VM/OS/CPU/mem you are using? I only have VirtualBox running on Linux X64 now, but will consider moving to some other platforms if it helps a lot. > > Thanks > Max > > On 09/13/2012 04:32 AM, Kelly O'Hair wrote: >> Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the machine used (hardware vs. VM), >> how many CPUs etc. But it's a bit erratic, depends on lots of things. We are still working around some CYGWIN issues. >> The incremental builds should be similar. I don't have any numbers right now. >> >> We hope we can get MinGW/MSYS working which might reduce the overall time by 20% or more (a big guess) >> (Remember MKS will not work with the new build-infra Makefiles). >> >> Windows XP 32bit builds take a bit longer maybe 35mins?, but the XP systems have limited RAM and cpu capacity. >> Solaris, Linux, and Mac builds are pretty consistent, but Windows is another story. :^( >> >> What we have noticed is that a beefy PC running Windows XP can easily do 20min builds, but building in >> an area that is immune from On-Access AntiVirus scanning or turning On-Access scanning off. >> >> -kto >> >> On Sep 12, 2012, at 11:52 AM, Igor Nekrestyanov wrote: >> >>> What about windows? >>> >>> -igor >>> >>> On 9/12/12 11:49 AM, Kelly O'Hair wrote: >>>> Some stats on incremental builds. Not partial builds.. >>>> >>>> This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch >>>> for 64bit including images took less than 14 minutes (parallel build setting was 8) and images took 2mins of this 14mins: >>>> >>>> -- Build times ---------- >>>> Target >>>> Start 2012-09-12 10:56:17 >>>> End 2012-09-12 11:09:55 >>>> 00:00:30 corba >>>> 00:04:51 hotspot >>>> 00:00:23 jaxp >>>> 00:00:33 jaxws >>>> 00:04:43 jdk >>>> 00:01:59 jdk-images >>>> 00:00:39 langtools >>>> 00:13:38 TOTAL >>>> ------------------------- >>>> >>>> A repeated 'gmake images" with no changes took 31 seconds: >>>> >>>> -- Build times ---------- >>>> Target >>>> Start 2012-09-12 11:13:30 >>>> End 2012-09-12 11:14:01 >>>> 00:00:02 corba >>>> 00:00:07 hotspot >>>> 00:00:02 jaxp >>>> 00:00:04 jaxws >>>> 00:00:08 jdk >>>> 00:00:07 jdk-images >>>> 00:00:01 langtools >>>> 00:00:31 TOTAL >>>> ------------------------- >>>> >>>> I touched a few awt java sources (touch jdk/src/share/classes/java/awt/*.java) and did just a 'gmake all' (no images) >>>> and it took 2 minutes (this will improve significantly with smartjavac): >>>> >>>> -- Build times ---------- >>>> Target >>>> Start 2012-09-12 11:17:34 >>>> End 2012-09-12 11:19:32 >>>> 00:00:00 corba >>>> 00:00:00 hotspot >>>> 00:00:00 jaxp >>>> 00:00:01 jaxws >>>> 00:01:56 jdk >>>> 00:00:01 langtools >>>> 00:01:58 TOTAL >>>> ------------------------- >>>> >>>> I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) and did the 'gmake all' (no images) >>>> and it took 37 seconds): >>>> >>>> -- Build times ---------- >>>> Target >>>> Start 2012-09-12 11:22:24 >>>> End 2012-09-12 11:23:01 >>>> 00:00:00 corba >>>> 00:00:00 hotspot >>>> 00:00:00 jaxp >>>> 00:00:01 jaxws >>>> 00:00:35 jdk >>>> 00:00:01 langtools >>>> 00:00:37 TOTAL >>>> ------------------------- >>>> >>>> So as far as incremental builds go, I think this is a vast improvement. And the incremental build should be accurate. >>>> >>>> I'm not taking a position on partial builds here, just providing some hard data on full openjdk builds with the >>>> new build-infra makefiles. >>>> >>>> The above builds are complete openjdk builds, with no import jdk needed, and no concerns about >>>> sync issues between jdk components (hotspot<->jdk). >>>> >>>> -kto >>>> >>>> >>>> On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote: >>>> >>>>> Magnus, >>>>> >>>>> You've only explained how incremental builds could work for Java classes in the new build-infra. What about incremental builds of native code? E.g. in AWT we often do the following: >>>>> >>>>> $ cd make/sun/awt (or make/java/awt, or make/sun/lwawt) >>>>> $ make >>>>> >>>>> And this re-builds both AWT classes and AWT native code (and some 2D stuff too, btw). What has build-infra got to offer for incremental builds of native code? >>>>> >>>>> Also, how fast are those incremental solutions (both the temporary, and the expected final one) in build-infra? Performing the above commands with the current build system takes literally just a few seconds on any platform (given you've built the JDK repo once before, and it might took like 10-30 minutes for the first build). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote: >>>>>> On 2012-09-10 14:13, Alan Bateman wrote: >>>>>>> When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man increment builds" as I call it. I think the majority of people working in the jdk repository, at least in Oracle, do this because they know the area and know which make files that re-build the files that they have changed. Incremental builds are generally not very reliable but seem to be "good enough" for most people needs, at least those that aren't doing significant refactoring. The main motive of course is to be able to re-build in a few seconds and the #1 goal of any new build system has to be fast incremental builds. >>>>>> In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hope that it will turn out to be good enough to be used as default, but I don't want to trust hope alone. >>>>>> As an interim solution, I have just created the following two shortcuts. Both of these bypass the proper dependency detection. This means that make will cut to the chase and recompile faster, but it also means that you need to take over the responsibility of making sure dependencies are correct. This is very similar to the "*-only" (e.g. hotspot-only) targets that are current available in the new build system. >>>>>> First shortcut is to skip parts of the JDK makefile. By typing e.g. "make jdk JDK_TARGET=classes", the JDK build will stop after building the "classes" target (which compiles the majority of the JDK java files). An even faster, but less safe, version is "make jdk-only JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, and only execute the "classes" target. In this way, absolutely no time is spent before starting to compile Java classes. >>>>>> Second shortcut is to limit the classes that are recompiled by the JDK "classes" target. Currently, *all* (more or less) Java classes in the JDK is recompiled at once. While this speeds up things considerably at a first time compilation, it makes all subsequent builds take the same time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio package will get compiled. This is, I think, similar (but not strictly not identical) to the effect of "sub-directory builds". It is possible to use an even more fine-grained filter, separated by comma, e.g. JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of Java files your filter includes, the faster the build will go (more or less). >>>>>> These two can of course be combined. >>>>>> I would like to point out that this is hopefully a temporary solution -- if proper dependency checking and incremental builds get fast enough, this kind of trickery should not be needed. If this happens, we will remove the support for these shortcuts since they do carry a risk of improper builds. >>>>>> /Magnus >>> >> From david.holmes at oracle.com Sat Sep 15 11:03:19 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 15 Sep 2012 21:03:19 +1000 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> Message-ID: <50546077.3010704@oracle.com> On 15/09/2012 8:44 AM, Kelly O'Hair wrote: > > It should get integrated through the hotspot-rt forest. Let me know if you need me to do that. > > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/bsd/makefiles/buildtree.make.sdiff.html > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/linux/makefiles/buildtree.make.sdiff.html > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/solaris/makefiles/buildtree.make.sdiff.html > > Has some cross compiling changes removed? Yes that is handled in the make/defs.make file now: + ifeq ($(TEST_IN_BUILD),) + # By default, run Queens test after building unless cross-compiling + ifneq ($(CROSS_COMPILE_ARCH),) + TEST_IN_BUILD = false + else + TEST_IN_BUILD = true + endif + endif David ----- > Otherwise looks fine. > > I agree that the duplication is ugly, but I also agree with you that these hotspot Makefiles are riddles with duplication > at a high level > > -kto > > > > On Sep 14, 2012, at 6:39 AM, Magnus Ihse Bursie wrote: > >> I'd like to make a new try at integrating this fix. :-) >> >> I posted two a webrev back in May. After some feedback, I posted a second one at http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. This second webrev was reviewed and accepted by David Holmes, Dmitry Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair expressed concern that it would not work on Windows due to changes in make/defs.make being problematic for Windows nmake. Also, in private conversation with me, Kelly found build problems on MacOSX. >> >> I didn't have time at the moment to address those issues, so I dropped it for the time being. >> >> However, I now checked more carefully. I'm not using any syntax in defs.make that is not already there, so I shouldn't introduce something Windows can't handle. >> >> The patch did have a problem though -- the TEST_IN_BUILD argument was not properly propagated. So I have made a new patch (third time's a charm!), and the webrev is here: >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ >> >> The only difference to the previous one is that I add TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to be done three times, once for each duplicated platform file...) >> >> I am currently running a series of tests on all platforms, both using the old build system and the new. Not all tests have finished running, but it's looking good so far and I believe there should be no more problems. (I'll let you know otherwise! :)) >> >> It feels like what should be a simple fix has grown somewhat out of proportion. I'm hoping I can get some final reviews on this, and some advice as to wether this fix should be integrated through the hotspot or the build forest. (On one hand, it's hotspot only, but on the other hand, it's just affecting build.) >> >> /Magnus >> >> >> On 2012-05-14 15:05, Magnus Ihse Bursie wrote: >>> As part of the new build system created in the build-infra project, we want to make it a configurable option wether or not to run the Queens test as part of the build. >>> >>> Here is a patch that introduces a new make variable, TEST_IN_BUILD, which controls wether to run the Queens test (test_gamma.sh) or not. If the variable is not explicitely set, it will default to true, mening that the default behaviour will be as before, that is, to run the Queens test. However, if you (or configure) explicitely set it to false, the Queens test will be skipped. >>> >>> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 >>> >>> /Magnus >>> >> >> > From kelly.ohair at oracle.com Sat Sep 15 15:37:21 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sat, 15 Sep 2012 08:37:21 -0700 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <50546077.3010704@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> <50546077.3010704@oracle.com> Message-ID: OK. Then I'm fine with it. -kto On Sep 15, 2012, at 4:03 AM, David Holmes wrote: > On 15/09/2012 8:44 AM, Kelly O'Hair wrote: >> >> It should get integrated through the hotspot-rt forest. Let me know if you need me to do that. >> >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/bsd/makefiles/buildtree.make.sdiff.html >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/linux/makefiles/buildtree.make.sdiff.html >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/solaris/makefiles/buildtree.make.sdiff.html >> >> Has some cross compiling changes removed? > > Yes that is handled in the make/defs.make file now: > > + ifeq ($(TEST_IN_BUILD),) > + # By default, run Queens test after building unless cross-compiling > + ifneq ($(CROSS_COMPILE_ARCH),) > + TEST_IN_BUILD = false > + else > + TEST_IN_BUILD = true > + endif > + endif > > David > ----- > >> Otherwise looks fine. >> >> I agree that the duplication is ugly, but I also agree with you that these hotspot Makefiles are riddles with duplication >> at a high level >> >> -kto >> >> >> >> On Sep 14, 2012, at 6:39 AM, Magnus Ihse Bursie wrote: >> >>> I'd like to make a new try at integrating this fix. :-) >>> >>> I posted two a webrev back in May. After some feedback, I posted a second one at http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. This second webrev was reviewed and accepted by David Holmes, Dmitry Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair expressed concern that it would not work on Windows due to changes in make/defs.make being problematic for Windows nmake. Also, in private conversation with me, Kelly found build problems on MacOSX. >>> >>> I didn't have time at the moment to address those issues, so I dropped it for the time being. >>> >>> However, I now checked more carefully. I'm not using any syntax in defs.make that is not already there, so I shouldn't introduce something Windows can't handle. >>> >>> The patch did have a problem though -- the TEST_IN_BUILD argument was not properly propagated. So I have made a new patch (third time's a charm!), and the webrev is here: >>> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ >>> >>> The only difference to the previous one is that I add TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to be done three times, once for each duplicated platform file...) >>> >>> I am currently running a series of tests on all platforms, both using the old build system and the new. Not all tests have finished running, but it's looking good so far and I believe there should be no more problems. (I'll let you know otherwise! :)) >>> >>> It feels like what should be a simple fix has grown somewhat out of proportion. I'm hoping I can get some final reviews on this, and some advice as to wether this fix should be integrated through the hotspot or the build forest. (On one hand, it's hotspot only, but on the other hand, it's just affecting build.) >>> >>> /Magnus >>> >>> >>> On 2012-05-14 15:05, Magnus Ihse Bursie wrote: >>>> As part of the new build system created in the build-infra project, we want to make it a configurable option wether or not to run the Queens test as part of the build. >>>> >>>> Here is a patch that introduces a new make variable, TEST_IN_BUILD, which controls wether to run the Queens test (test_gamma.sh) or not. If the variable is not explicitely set, it will default to true, mening that the default behaviour will be as before, that is, to run the Queens test. However, if you (or configure) explicitely set it to false, the Queens test will be skipped. >>>> >>>> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 >>>> >>>> /Magnus >>>> >>> >>> >> From magnus.ihse.bursie at oracle.com Mon Sep 17 08:18:27 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Sep 2012 10:18:27 +0200 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> <5E559CB4-6EF7-4748-ACE2-B7AD4E77D828@oracle.com> Message-ID: <5056DCD3.4020408@oracle.com> On 2012-09-15 00:44, Kelly O'Hair wrote: > It should get integrated through the hotspot-rt forest. Let me know if you need me to do that. > > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/bsd/makefiles/buildtree.make.sdiff.html > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/linux/makefiles/buildtree.make.sdiff.html > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/make/solaris/makefiles/buildtree.make.sdiff.html > > Has some cross compiling changes removed? Yes, that was done as an addition to the original fix at the request of David Holmes. /Magnus From vladimir.kozlov at oracle.com Fri Sep 14 14:39:44 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Sep 2012 07:39:44 -0700 Subject: Request for Review: Make the Queens test ("test in build") an option that can be disabled In-Reply-To: <50533376.3000809@oracle.com> References: <4FB10306.3090206@oracle.com> <50533376.3000809@oracle.com> Message-ID: <505341B0.5050005@oracle.com> Looks good and it should be pushed into hotspot repo (using JPRT). And I am fine with duplication of checks. Vladimir Magnus Ihse Bursie wrote: > I'd like to make a new try at integrating this fix. :-) > > I posted two a webrev back in May. After some feedback, I posted a > second one at > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. > This second webrev was reviewed and accepted by David Holmes, Dmitry > Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair > expressed concern that it would not work on Windows due to changes in > make/defs.make being problematic for Windows nmake. Also, in private > conversation with me, Kelly found build problems on MacOSX. > > I didn't have time at the moment to address those issues, so I dropped > it for the time being. > > However, I now checked more carefully. I'm not using any syntax in > defs.make that is not already there, so I shouldn't introduce something > Windows can't handle. > > The patch did have a problem though -- the TEST_IN_BUILD argument was > not properly propagated. So I have made a new patch (third time's a > charm!), and the webrev is here: > http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.02/ > > The only difference to the previous one is that I add > TEST_IN_BUILD=$(TEST_IN_BUILD) to the BUILDTREE_VARS. (But it needs to > be done three times, once for each duplicated platform file...) > > I am currently running a series of tests on all platforms, both using > the old build system and the new. Not all tests have finished running, > but it's looking good so far and I believe there should be no more > problems. (I'll let you know otherwise! :)) > > It feels like what should be a simple fix has grown somewhat out of > proportion. I'm hoping I can get some final reviews on this, and some > advice as to wether this fix should be integrated through the hotspot or > the build forest. (On one hand, it's hotspot only, but on the other > hand, it's just affecting build.) > > /Magnus > > > On 2012-05-14 15:05, Magnus Ihse Bursie wrote: >> As part of the new build system created in the build-infra project, we >> want to make it a configurable option wether or not to run the Queens >> test as part of the build. >> >> Here is a patch that introduces a new make variable, TEST_IN_BUILD, >> which controls wether to run the Queens test (test_gamma.sh) or not. >> If the variable is not explicitely set, it will default to true, >> mening that the default behaviour will be as before, that is, to run >> the Queens test. However, if you (or configure) explicitely set it to >> false, the Queens test will be skipped. >> >> http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.00 >> >> /Magnus >> > > From ahughes at redhat.com Tue Sep 18 14:39:20 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 18 Sep 2012 10:39:20 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1233187763.1627890.1347978606880.JavaMail.root@redhat.com> Message-ID: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> This is an issue that has been with us for a while. See: https://bugs.openjdk.java.net/show_bug.cgi?id=100062 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 for some background. The original proposed patch goes to far in removing most of the infrastructure for restricting crypto levels and signing of crypto jars. The following simple webrev will achieve what I think is needed: http://cr.openjdk.java.net/~andrew/100062/webrev.01/ allowing OpenJDK to be built with the unlimited rather than limited crypto policy in place. The build is only altered if both an OpenJDK build is being performed and UNLIMITED_CRYPTO is defined. In this case, the install-unlimited rule is used to install policies. Without UNLIMITED_CRYPTO being set, OpenJDK builds still depend on install-limited as now. I believe this is a fairly unintrusive change which should allow GNU/Linux distros to ship without crypto restrictions while still using upstream OpenJDK rather than a variant with several classes removed. It's not clear to me why this approach wasn't taken before, so I hope I haven't missed something. If this looks ok, I'll push it as the resolution for bug 7188845. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kelly.ohair at oracle.com Tue Sep 18 18:31:03 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:03 +0000 Subject: hg: jdk8/build: 7197849: Update new build-infra makefiles Message-ID: <20120918183103.E5C2147B80@hg.openjdk.java.net> Changeset: 2ba6f4da4bf3 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/2ba6f4da4bf3 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! .hgignore ! Makefile + NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 + common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 + common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh + common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/spec.sh.in ! common/autoconf/toolchain.m4 + common/bin/boot_cycle.sh ! common/bin/compare-objects.sh + common/bin/test_builds.sh + common/bin/unicode2x.sed + common/makefiles/HotspotWrapper.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk + common/makefiles/javadoc/CORE_PKGS.gmk + common/makefiles/javadoc/Javadoc.gmk + common/makefiles/javadoc/NON_CORE_PKGS.gmk + common/makefiles/javadoc/Notes.html From kelly.ohair at oracle.com Tue Sep 18 18:31:05 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:05 +0000 Subject: hg: jdk8/build/corba: 7197849: Update new build-infra makefiles Message-ID: <20120918183110.A2AF747B81@hg.openjdk.java.net> Changeset: 5c4f045fbd5f Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/5c4f045fbd5f 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile From kelly.ohair at oracle.com Tue Sep 18 18:31:05 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:05 +0000 Subject: hg: jdk8/build/jaxws: 7197849: Update new build-infra makefiles Message-ID: <20120918183113.C703147B82@hg.openjdk.java.net> Changeset: bbcbebb9bc74 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/bbcbebb9bc74 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile From kelly.ohair at oracle.com Tue Sep 18 18:31:02 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:02 +0000 Subject: hg: jdk8/build/jaxp: 7197849: Update new build-infra makefiles Message-ID: <20120918183116.37C1647B83@hg.openjdk.java.net> Changeset: 2eafc339f7e1 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/2eafc339f7e1 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile From kelly.ohair at oracle.com Tue Sep 18 18:31:09 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:09 +0000 Subject: hg: jdk8/build/langtools: 7197849: Update new build-infra makefiles Message-ID: <20120918183117.1A8AA47B84@hg.openjdk.java.net> Changeset: 463fea75b618 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/463fea75b618 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/Makefile From kelly.ohair at oracle.com Tue Sep 18 18:31:06 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 18:31:06 +0000 Subject: hg: jdk8/build/jdk: 7197849: Update new build-infra makefiles Message-ID: <20120918183208.65FFD47B85@hg.openjdk.java.net> Changeset: 71ff959f9a34 Author: ohair Date: 2012-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/71ff959f9a34 7197849: Update new build-infra makefiles Reviewed-by: ihse, erikj, ohrstrom, tbell ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/Setup.gmk ! makefiles/Tools.gmk + makefiles/mapfiles/launchers/mapfile-x86 + makefiles/mapfiles/launchers/mapfile-x86_64 + makefiles/mapfiles/libawt_headless/reorder-x86 ! makefiles/mapfiles/libjava/mapfile-vers + makefiles/mapfiles/libjava/reorder-x86 ! makefiles/mapfiles/libjli/mapfile-vers + makefiles/mapfiles/libjpeg/reorder-x86 ! makefiles/mapfiles/libnio/mapfile-linux + makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris + makefiles/mapfiles/libnio/reorder-x86 + makefiles/mapfiles/libverify/reorder-x86 ! makefiles/mapfiles/libzip/mapfile-vers + makefiles/mapfiles/libzip/reorder-x86 From jonathan.gibbons at oracle.com Tue Sep 18 18:46:42 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 18 Sep 2012 11:46:42 -0700 Subject: hg: jdk8/build/langtools: 7197849: Update new build-infra makefiles In-Reply-To: <20120918183117.1A8AA47B84@hg.openjdk.java.net> References: <20120918183117.1A8AA47B84@hg.openjdk.java.net> Message-ID: <5058C192.5090301@oracle.com> On 09/18/2012 11:31 AM, kelly.ohair at oracle.com wrote: > Changeset: 463fea75b618 > Author: ohair > Date: 2012-09-18 11:29 -0700 > URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/463fea75b618 > > 7197849: Update new build-infra makefiles > Reviewed-by: ihse, erikj, ohrstrom, tbell > > ! makefiles/Makefile > In a build system focussed on speed, it is disappointing to see the use of -Xprefer:source. I know this has been discussed recently, but it would be good to find a better way to fix the underlying problem, and to regard the use of -Xprefer:source as an interim workaround. -- Jon From kelly.ohair at oracle.com Tue Sep 18 19:16:55 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 18 Sep 2012 19:16:55 +0000 Subject: hg: jdk8/build/jdk: 7198325: Fix more $(sort) issues on lnk commands in makefiles, making binaries more consistent; ... Message-ID: <20120918191721.3BFDD47B88@hg.openjdk.java.net> Changeset: dcbcecbe7b23 Author: ohair Date: 2012-09-18 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/dcbcecbe7b23 7198325: Fix more $(sort) issues on lnk commands in makefiles, making binaries more consistent 7130909: Add a more general mechanism for customizing the build logic Reviewed-by: dholmes, tbell, erikj, ihse, ohrstrom ! make/Makefile ! make/com/sun/java/pack/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk ! make/java/jli/Makefile From david.holmes at oracle.com Wed Sep 19 02:26:33 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2012 12:26:33 +1000 Subject: Trivial Review: 7199410 Remove files that were omitted from 7130909 changeset Message-ID: <50592D59.9070003@oracle.com> http://cr.openjdk.java.net/~dholmes/7199410/webrev/ Simply removes two files now unused. Thanks, David From kelly.ohair at oracle.com Wed Sep 19 03:57:54 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 18 Sep 2012 20:57:54 -0700 Subject: Trivial Review: 7199410 Remove files that were omitted from 7130909 changeset In-Reply-To: <50592D59.9070003@oracle.com> References: <50592D59.9070003@oracle.com> Message-ID: <7DB044E0-F324-4D69-B3A3-86FBB150E2F4@oracle.com> Looks fine, sorry I missed this. -kto On Sep 18, 2012, at 7:26 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7199410/webrev/ > > Simply removes two files now unused. > > Thanks, > David From david.holmes at oracle.com Wed Sep 19 03:59:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2012 13:59:55 +1000 Subject: Trivial Review: 7199410 Remove files that were omitted from 7130909 changeset In-Reply-To: <7DB044E0-F324-4D69-B3A3-86FBB150E2F4@oracle.com> References: <50592D59.9070003@oracle.com> <7DB044E0-F324-4D69-B3A3-86FBB150E2F4@oracle.com> Message-ID: <5059433B.4000107@oracle.com> On 19/09/2012 1:57 PM, Kelly O'Hair wrote: > Looks fine, sorry I missed this. No problem, there's been an awful lot to coordinate lately. I'm currently testing embedded builds using old and new build systems just in case anything else needs tweaking. Thanks, David > -kto > > On Sep 18, 2012, at 7:26 PM, David Holmes wrote: > >> http://cr.openjdk.java.net/~dholmes/7199410/webrev/ >> >> Simply removes two files now unused. >> >> Thanks, >> David > From david.holmes at oracle.com Wed Sep 19 08:28:43 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 19 Sep 2012 08:28:43 +0000 Subject: hg: jdk8/build/jdk: 7199410: Remove files that were omitted from 7130909 changeset Message-ID: <20120919082904.35C9A47BAF@hg.openjdk.java.net> Changeset: ab1523b7ca2a Author: dholmes Date: 2012-09-19 04:26 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ab1523b7ca2a 7199410: Remove files that were omitted from 7130909 changeset Reviewed-by: ohair - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk From sadhak001 at gmail.com Tue Sep 18 21:53:12 2012 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 18 Sep 2012 22:53:12 +0100 Subject: Building OpenJDK projects and JTReg in Eclipse Message-ID: Hi, I have recently posted a couple of blogs on How to Build OpenJDK projects and JTReg in Eclipse and have received good feedback on the content. But I would still like it to be reviewed by groups that work in this area regularly to give expert opinion and advise on it. Please have a look at the posts at and let me know if any of these are incorrect and should be approached differently: http://neomatrix369.wordpress.com/ They were written the Adopt OpenJDK wikipage in mind so you will also find them here: http://java.net/projects/adoptopenjdk/pages/AdoptOpenJDKBuildInstructions#Install_IDE_Support http://java.net/projects/adoptopenjdk/pages/InstallJtreg#How_to_build_JTReg_in_Eclipse_(for_Ubuntu_12.04_LTS) Your feedback will help enrich these sets of information. If you think I should pass on this email to other groups that work on other sub-sets of the OpenJDK projects please do let me know (their emails as well). Thanks. Mani From martijnverburg at gmail.com Wed Sep 19 16:25:44 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 19 Sep 2012 17:25:44 +0100 Subject: Building OpenJDK projects and JTReg in Eclipse In-Reply-To: References: Message-ID: Hi all, CCing in build-infra and Jon on behalf of code-tools who I think will be interested. In particular we're using build-infra now for the AdoptOpenJDK build instructions. Next step is to verify this early work and automate it with some Vagrant/Puppet magic. Cheers, Martijn On 18 September 2012 22:53, Mani Sarkar wrote: > Hi, > > I have recently posted a couple of blogs on How to Build OpenJDK projects > and JTReg in Eclipse and have received good feedback on the content. But I > would still like it to be reviewed by groups that work in this area > regularly to give expert opinion and advise on it. > > Please have a look at the posts at and let me know if any of these are > incorrect and should be approached differently: > http://neomatrix369.wordpress.com/ > > They were written the Adopt OpenJDK wikipage in mind so you will also find > them here: > > http://java.net/projects/adoptopenjdk/pages/AdoptOpenJDKBuildInstructions#Install_IDE_Support > > http://java.net/projects/adoptopenjdk/pages/InstallJtreg#How_to_build_JTReg_in_Eclipse_(for_Ubuntu_12.04_LTS) > > Your feedback will help enrich these sets of information. If you think I > should pass on this email to other groups that work on other sub-sets of > the OpenJDK projects please do let me know (their emails as well). > > Thanks. > Mani From david.katleman at oracle.com Wed Sep 19 23:24:20 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:24:20 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20120919232420.E421A47BC3@hg.openjdk.java.net> Changeset: 56264ff5e1d5 Author: katleman Date: 2012-09-13 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/56264ff5e1d5 Added tag jdk8-b56 for changeset 76844579fa4b ! .hgtags Changeset: 522dfac8ca4d Author: katleman Date: 2012-09-19 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/522dfac8ca4d Merge From david.katleman at oracle.com Wed Sep 19 23:24:25 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:24:25 +0000 Subject: hg: jdk8/build/corba: 2 new changesets Message-ID: <20120919232427.8D4D347BC4@hg.openjdk.java.net> Changeset: 1500fe4849e8 Author: katleman Date: 2012-09-13 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/1500fe4849e8 Added tag jdk8-b56 for changeset bf1bb47414e1 ! .hgtags Changeset: f3ab4163ae01 Author: katleman Date: 2012-09-19 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/f3ab4163ae01 Merge From david.katleman at oracle.com Wed Sep 19 23:27:25 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:27:25 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b56 for changeset 6124ff421829 Message-ID: <20120919232730.A66CB47BC5@hg.openjdk.java.net> Changeset: d70102c4cb73 Author: katleman Date: 2012-09-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d70102c4cb73 Added tag jdk8-b56 for changeset 6124ff421829 ! .hgtags From david.katleman at oracle.com Wed Sep 19 23:29:24 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:29:24 +0000 Subject: hg: jdk8/build/jaxp: 2 new changesets Message-ID: <20120919232932.D51C447BC6@hg.openjdk.java.net> Changeset: 40bbed6d2173 Author: katleman Date: 2012-09-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/40bbed6d2173 Added tag jdk8-b56 for changeset f19d63b2119a ! .hgtags Changeset: 7c9475c7618c Author: katleman Date: 2012-09-19 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/7c9475c7618c Merge From david.katleman at oracle.com Wed Sep 19 23:29:38 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:29:38 +0000 Subject: hg: jdk8/build/jaxws: 2 new changesets Message-ID: <20120919232944.3C71947BC7@hg.openjdk.java.net> Changeset: e099c1eea1ed Author: katleman Date: 2012-09-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/e099c1eea1ed Added tag jdk8-b56 for changeset 7813455ccdb0 ! .hgtags Changeset: b51b611209f1 Author: katleman Date: 2012-09-19 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/b51b611209f1 Merge From david.katleman at oracle.com Wed Sep 19 23:29:54 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:29:54 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20120919233044.775A947BC8@hg.openjdk.java.net> Changeset: 472145010fcc Author: katleman Date: 2012-09-13 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/472145010fcc Added tag jdk8-b56 for changeset 2e9eeef2909b ! .hgtags Changeset: 51594d095a4b Author: katleman Date: 2012-09-19 15:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/51594d095a4b Merge From david.katleman at oracle.com Wed Sep 19 23:32:12 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 19 Sep 2012 23:32:12 +0000 Subject: hg: jdk8/build/langtools: 2 new changesets Message-ID: <20120919233218.958EF47BC9@hg.openjdk.java.net> Changeset: 27ba086a9b60 Author: katleman Date: 2012-09-13 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/27ba086a9b60 Added tag jdk8-b56 for changeset 363e9198b9de ! .hgtags Changeset: 86d5740b9fdc Author: katleman Date: 2012-09-19 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/86d5740b9fdc Merge From kelly.ohair at oracle.com Thu Sep 20 01:19:50 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 19 Sep 2012 18:19:50 -0700 Subject: Need reviewer for fix to Mac jdk partial builds References: <389800D2-40DE-4A7C-921B-792D5E1547AF@oracle.com> Message-ID: <5EEE3350-28B5-4564-B33A-8F8CD4132D39@oracle.com> 7191703: jprt cannot build jdk on MacOSX. http://cr.openjdk.java.net/~ohair/openjdk8/jobjc-fix/webrev/ Fixes a partial build issue with the jdk repo on the Mac. If LANGTOOLS_DIST is defined, nothing changes and the ant script should find langtools/dist/classes.jar. Otherwise, by running ant with the import jdk, it should build ok. I very much dislike this logic but don't feel it is worth doing more than the minimum here. -kto From kelly.ohair at oracle.com Thu Sep 20 02:34:05 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 19 Sep 2012 19:34:05 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> References: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> Message-ID: <1086A2E1-615D-4F7A-8F50-C40A75601D73@oracle.com> It seems fine with me. But I think someone from the security team should chime in on this. -kto On Sep 18, 2012, at 7:39 AM, Andrew Hughes wrote: > This is an issue that has been with us for a while. See: > > https://bugs.openjdk.java.net/show_bug.cgi?id=100062 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 > > for some background. > > The original proposed patch goes to far in removing most of the > infrastructure for restricting crypto levels and signing of crypto > jars. > > The following simple webrev will achieve what I think is needed: > > http://cr.openjdk.java.net/~andrew/100062/webrev.01/ > > allowing OpenJDK to be built with the unlimited rather than limited > crypto policy in place. > > The build is only altered if both an OpenJDK build is being performed > and UNLIMITED_CRYPTO is defined. In this case, the install-unlimited > rule is used to install policies. Without UNLIMITED_CRYPTO being set, > OpenJDK builds still depend on install-limited as now. > > I believe this is a fairly unintrusive change which should allow GNU/Linux > distros to ship without crypto restrictions while still using upstream > OpenJDK rather than a variant with several classes removed. > > It's not clear to me why this approach wasn't taken before, so I hope I haven't > missed something. > > If this looks ok, I'll push it as the resolution for bug 7188845. > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From bradford.wetmore at oracle.com Thu Sep 20 03:21:02 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 19 Sep 2012 20:21:02 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1086A2E1-615D-4F7A-8F50-C40A75601D73@oracle.com> References: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> <1086A2E1-615D-4F7A-8F50-C40A75601D73@oracle.com> Message-ID: <505A8B9E.1070006@oracle.com> > But I think someone from the security team should chime in on this. I plan to look closer at this. On the surface, it looks acceptable to me, but I've been heads down in the SNI code: likely for one more day. Wanted to also run this by one of my other colleagues. One thought: I'm wondering if we might want to have this switch in both Open and Closed. As long as default is off, I don't immediately see a reason to not have it. Brad On 9/19/2012 7:34 PM, Kelly O'Hair wrote: > It seems fine with me. > But I think someone from the security team should chime in on this. > > -kto > > On Sep 18, 2012, at 7:39 AM, Andrew Hughes wrote: > >> This is an issue that has been with us for a while. See: >> >> https://bugs.openjdk.java.net/show_bug.cgi?id=100062 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 >> >> for some background. >> >> The original proposed patch goes to far in removing most of the >> infrastructure for restricting crypto levels and signing of crypto >> jars. >> >> The following simple webrev will achieve what I think is needed: >> >> http://cr.openjdk.java.net/~andrew/100062/webrev.01/ >> >> allowing OpenJDK to be built with the unlimited rather than limited >> crypto policy in place. >> >> The build is only altered if both an OpenJDK build is being performed >> and UNLIMITED_CRYPTO is defined. In this case, the install-unlimited >> rule is used to install policies. Without UNLIMITED_CRYPTO being set, >> OpenJDK builds still depend on install-limited as now. >> >> I believe this is a fairly unintrusive change which should allow GNU/Linux >> distros to ship without crypto restrictions while still using upstream >> OpenJDK rather than a variant with several classes removed. >> >> It's not clear to me why this approach wasn't taken before, so I hope I haven't >> missed something. >> >> If this looks ok, I'll push it as the resolution for bug 7188845. >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > From gnu.andrew at redhat.com Thu Sep 20 14:57:29 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Sep 2012 10:57:29 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <505A8B9E.1070006@oracle.com> Message-ID: <1791682770.3347144.1348153049006.JavaMail.root@redhat.com> ----- Original Message ----- > > But I think someone from the security team should chime in on this. > > I plan to look closer at this. On the surface, it looks acceptable > to > me, but I've been heads down in the SNI code: likely for one more > day. > Wanted to also run this by one of my other colleagues. > > One thought: I'm wondering if we might want to have this switch in > both > Open and Closed. As long as default is off, I don't immediately see > a > reason to not have it. > I've no problem with that. I just placed it within the OPENJDK ifdef so it won't interfere with the proprietary build at all, as obviously I can't test it ;-) But, either way, if it's not set, there's no change in behaviour. > Brad > > > > On 9/19/2012 7:34 PM, Kelly O'Hair wrote: > > It seems fine with me. > > But I think someone from the security team should chime in on this. > > > > -kto > > > > On Sep 18, 2012, at 7:39 AM, Andrew Hughes wrote: > > > >> This is an issue that has been with us for a while. See: > >> > >> https://bugs.openjdk.java.net/show_bug.cgi?id=100062 > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 > >> > >> for some background. > >> > >> The original proposed patch goes to far in removing most of the > >> infrastructure for restricting crypto levels and signing of crypto > >> jars. > >> > >> The following simple webrev will achieve what I think is needed: > >> > >> http://cr.openjdk.java.net/~andrew/100062/webrev.01/ > >> > >> allowing OpenJDK to be built with the unlimited rather than > >> limited > >> crypto policy in place. > >> > >> The build is only altered if both an OpenJDK build is being > >> performed > >> and UNLIMITED_CRYPTO is defined. In this case, the > >> install-unlimited > >> rule is used to install policies. Without UNLIMITED_CRYPTO being > >> set, > >> OpenJDK builds still depend on install-limited as now. > >> > >> I believe this is a fairly unintrusive change which should allow > >> GNU/Linux > >> distros to ship without crypto restrictions while still using > >> upstream > >> OpenJDK rather than a variant with several classes removed. > >> > >> It's not clear to me why this approach wasn't taken before, so I > >> hope I haven't > >> missed something. > >> > >> If this looks ok, I'll push it as the resolution for bug 7188845. > >> -- > >> Andrew :) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From anthony.petrov at oracle.com Fri Sep 21 11:38:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 21 Sep 2012 15:38:17 +0400 Subject: Need reviewer for fix to Mac jdk partial builds In-Reply-To: <5EEE3350-28B5-4564-B33A-8F8CD4132D39@oracle.com> References: <389800D2-40DE-4A7C-921B-792D5E1547AF@oracle.com> <5EEE3350-28B5-4564-B33A-8F8CD4132D39@oracle.com> Message-ID: <505C51A9.8070703@oracle.com> Hi Kelly, The JDK 8 partial repository (only the jdk itself) builds fine on my Mac with your changes. The fix looks good to me, although I don't have deep knowledge of the components being modified. Thanks for fixing this issue! -- best regards, Anthony On 9/20/2012 5:19 AM, Kelly O'Hair wrote: > 7191703: jprt cannot build jdk on MacOSX. > http://cr.openjdk.java.net/~ohair/openjdk8/jobjc-fix/webrev/ > > Fixes a partial build issue with the jdk repo on the Mac. > If LANGTOOLS_DIST is defined, nothing changes and the ant script should find langtools/dist/classes.jar. > Otherwise, by running ant with the import jdk, it should build ok. > > I very much dislike this logic but don't feel it is worth doing more than the minimum here. > > -kto > From kelly.ohair at oracle.com Fri Sep 21 19:23:13 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Fri, 21 Sep 2012 19:23:13 +0000 Subject: hg: jdk8/build/jdk: 7191703: jprt cannot build jdk on MacOSX. Message-ID: <20120921192403.C34BC47C34@hg.openjdk.java.net> Changeset: c9568c94c4e7 Author: ohair Date: 2012-09-21 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c9568c94c4e7 7191703: jprt cannot build jdk on MacOSX. Reviewed-by: anthony ! make/common/shared/Defs.gmk ! make/java/jobjc/Makefile From kelly.ohair at oracle.com Fri Sep 21 19:29:18 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 21 Sep 2012 12:29:18 -0700 Subject: Need reviewer for fix to Mac jdk partial builds In-Reply-To: <505C51A9.8070703@oracle.com> References: <389800D2-40DE-4A7C-921B-792D5E1547AF@oracle.com> <5EEE3350-28B5-4564-B33A-8F8CD4132D39@oracle.com> <505C51A9.8070703@oracle.com> Message-ID: <281B51EC-0A53-4250-9792-88A39B51F8DE@oracle.com> Should be integrated now in the jdk8/build/jdk repository. -kto On Sep 21, 2012, at 4:38 AM, Anthony Petrov wrote: > Hi Kelly, > > The JDK 8 partial repository (only the jdk itself) builds fine on my Mac with your changes. The fix looks good to me, although I don't have deep knowledge of the components being modified. > > Thanks for fixing this issue! > > -- > best regards, > Anthony > > On 9/20/2012 5:19 AM, Kelly O'Hair wrote: >> 7191703: jprt cannot build jdk on MacOSX. >> http://cr.openjdk.java.net/~ohair/openjdk8/jobjc-fix/webrev/ >> Fixes a partial build issue with the jdk repo on the Mac. >> If LANGTOOLS_DIST is defined, nothing changes and the ant script should find langtools/dist/classes.jar. >> Otherwise, by running ant with the import jdk, it should build ok. >> I very much dislike this logic but don't feel it is worth doing more than the minimum here. >> -kto From spoole at linux.vnet.ibm.com Mon Sep 24 09:35:02 2012 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 24 Sep 2012 10:35:02 +0100 Subject: javaw launcher Message-ID: <75A53256-28F7-462B-A5A9-B6734B374326@linux.vnet.ibm.com> hi all, this may seem a strange request but here goes.. IBM ships its runtimes with a javaw launcher on all platforms - not just Windows. We do this for consistency reasons so that applications using Java know that they can just call "javaw" on any platform and not have to worry about getting a console window show up. It makes life just a little simpler and easier for everyone. What I'd like to explore is either getting javaw added to all platforms in OpenJDK- or figure out if there is a moral equivalent that can be used instead. Your thoughts would be appreciated.. Cheers Steve From ahughes at redhat.com Mon Sep 24 13:46:40 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 24 Sep 2012 09:46:40 -0400 (EDT) Subject: javaw launcher In-Reply-To: <75A53256-28F7-462B-A5A9-B6734B374326@linux.vnet.ibm.com> Message-ID: <1639794755.573465.1348494400724.JavaMail.root@redhat.com> ----- Original Message ----- > hi all, > this may seem a strange request but here goes.. > > IBM ships its runtimes with a javaw launcher on all platforms - not > just Windows. > > We do this for consistency reasons so that applications using Java > know that they can just call "javaw" on any platform and not have > to worry about getting a console window show up. It makes life > just a little simpler and easier for everyone. > > What I'd like to explore is either getting javaw added to all > platforms in OpenJDK- or figure out if there is a moral equivalent > that can be used instead. > > Your thoughts would be appreciated.. > > Cheers > > Steve > > Couldn't javaw just be a symlink on some platforms? I don't see how it would be any different on, say, GNU/Linux platforms. Cheers, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kumar.x.srinivasan at oracle.COM Mon Sep 24 14:52:37 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 24 Sep 2012 07:52:37 -0700 Subject: javaw launcher In-Reply-To: <1639794755.573465.1348494400724.JavaMail.root@redhat.com> References: <1639794755.573465.1348494400724.JavaMail.root@redhat.com> Message-ID: <506073B5.3080306@oracle.COM> On 9/24/2012 6:46 AM, Andrew Hughes wrote: > ----- Original Message ----- >> hi all, >> this may seem a strange request but here goes.. >> >> IBM ships its runtimes with a javaw launcher on all platforms - not >> just Windows. >> >> We do this for consistency reasons so that applications using Java >> know that they can just call "javaw" on any platform and not have >> to worry about getting a console window show up. It makes life >> just a little simpler and easier for everyone. >> >> What I'd like to explore is either getting javaw added to all >> platforms in OpenJDK- or figure out if there is a moral equivalent >> that can be used instead. >> >> Your thoughts would be appreciated.. >> >> Cheers >> >> Steve >> >> > Couldn't javaw just be a symlink on some platforms? I don't see how it > would be any different on, say, GNU/Linux platforms. I agree, a symlink in the distro would be sufficient. Kumar > > Cheers, From james.holmlund at oracle.com Mon Sep 24 19:43:58 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 24 Sep 2012 12:43:58 -0700 Subject: [8] Review request for 7197401: Add a subset of the org.objectweb.asm packages to JDK 8 Message-ID: <5060B7FE.6010802@oracle.com> Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197401 Webrev: http://cr.openjdk.java.net/~jjh/7197401/ Thanks - jjh From mjw at redhat.com Tue Sep 25 12:31:51 2012 From: mjw at redhat.com (Mark Wielaard) Date: Tue, 25 Sep 2012 14:31:51 +0200 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> References: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> Message-ID: <1348576311.2976.21.camel@springer.wildebeest.org> On Tue, 2012-09-18 at 10:39 -0400, Andrew Hughes wrote: > This is an issue that has been with us for a while. See: > > https://bugs.openjdk.java.net/show_bug.cgi?id=100062 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 > > for some background. > [...] > It's not clear to me why this approach wasn't taken before, so I hope I haven't > missed something. The original reason is described in those two references you found and explained a bit more in: http://mail.openjdk.java.net/pipermail/security-dev/2009-June/000916.html The summary is that it was just easier to remove unused classes that made the code tricky to understand for no good reason except for some secret proprietary code. Of course that is an explanation from 3 years ago, and the original patch was made 4 years ago... Maybe the code base has been simplified since. In general it has just been impossible to get anybody to make time to review it :{ Cheers, Mark From Dmitry.Samersoff at oracle.com Tue Sep 25 14:57:49 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 25 Sep 2012 18:57:49 +0400 Subject: [8] Review request for 7197401: Add a subset of the org.objectweb.asm packages to JDK 8 In-Reply-To: <5060B7FE.6010802@oracle.com> References: <5060B7FE.6010802@oracle.com> Message-ID: <5061C66D.5090503@oracle.com> Jim, What is the reason of creating separate jdk.internal package tree - we already have sun. and com.sun. treated as internal. e.g. apache code is in com.sun.org.apache.* -Dmitry On 2012-09-24 23:43, Jim Holmlund wrote: > > Please review the fix for CR: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197401 > > Webrev: > > http://cr.openjdk.java.net/~jjh/7197401/ > > Thanks > - jjh > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From james.holmlund at oracle.com Tue Sep 25 15:04:38 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Tue, 25 Sep 2012 08:04:38 -0700 Subject: [8] Review request for 7197401: Add a subset of the org.objectweb.asm packages to JDK 8 In-Reply-To: <5061C66D.5090503@oracle.com> References: <5060B7FE.6010802@oracle.com> <5061C66D.5090503@oracle.com> Message-ID: <5061C806.5040808@oracle.com> On 9/25/2012 7:57 AM, Dmitry Samersoff wrote: > Jim, > > What is the reason of creating separate jdk.internal package tree - we > already have sun. and com.sun. treated as internal. Mark R said to put it in jdk.internal. - jjh > e.g. apache code is in com.sun.org.apache.* > > -Dmitry > > On 2012-09-24 23:43, Jim Holmlund wrote: >> Please review the fix for CR: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197401 >> >> Webrev: >> >> http://cr.openjdk.java.net/~jjh/7197401/ >> >> Thanks >> - jjh >> > From gnu.andrew at redhat.com Tue Sep 25 17:39:34 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 25 Sep 2012 13:39:34 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1348576311.2976.21.camel@springer.wildebeest.org> Message-ID: <812513879.1519581.1348594774796.JavaMail.root@redhat.com> ----- Original Message ----- > On Tue, 2012-09-18 at 10:39 -0400, Andrew Hughes wrote: > > This is an issue that has been with us for a while. See: > > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100062 > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845 > > > > for some background. > > [...] > > It's not clear to me why this approach wasn't taken before, so I > > hope I haven't > > missed something. > > The original reason is described in those two references you found > and > explained a bit more in: > http://mail.openjdk.java.net/pipermail/security-dev/2009-June/000916.html > The summary is that it was just easier to remove unused classes that > made the code tricky to understand for no good reason except for some > secret proprietary code. Of course that is an explanation from 3 > years > ago, and the original patch was made 4 years ago... Maybe the code > base > has been simplified since. In general it has just been impossible to > get > anybody to make time to review it :{ > Yes, I understand that much. But such a patch is never going to be upstreamable, so we have to make a compromise for Oracle's proprietary builds. I'm sure it would be easy enough to dump those classes if Oracle started producing OpenJDK binaries licensed under the GPL, rather than binaries from their proprietary fork. But I don't see that happening. > Cheers, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Wed Sep 26 02:30:43 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 25 Sep 2012 19:30:43 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> References: <1963621108.1658600.1347979160961.JavaMail.root@redhat.com> Message-ID: <506268D3.7000500@oracle.com> On 9/18/2012 7:39 AM, Andrew Hughes wrote: > The following simple webrev will achieve what I think is needed: > > http://cr.openjdk.java.net/~andrew/100062/webrev.01/ > > allowing OpenJDK to be built with the unlimited rather than limited > crypto policy in place. I got a chance to talk to Valerie, and what you've done looks good. I'm "wetmore" if you need a reviewer, and I think Kelly has looked at it too. > I just placed it within the OPENJDK ifdef so it > won't interfere with the proprietary build at all, as obviously I > can't test it Please leave your new code check within the "ifdef OPENJDK". Will you be putting this back yourself? If so let me know when you go in, and I can update the bug once you're in. Mark wrote: > The summary is that it was just easier to remove unused classes that > made the code tricky to understand for no good reason except for some > secret proprietary code. Unfortunately, Oracle and some of our commercial (non-OpenJDK) licensees still depend on that tricky code. :( I'd personally love to strip it all out, but we have to balance all of its consumers (Oracle SE and ME, commercial source/binary licensees, OpenJDK, etc.) Andrew wrote: > I'm sure it would be easy enough to dump those classes if Oracle > started producing OpenJDK binaries licensed under the GPL, rather > than binaries from their proprietary fork. Unfortunately, not likely in our current export/import climate. Brad From gnu.andrew at redhat.com Wed Sep 26 13:55:23 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Sep 2012 09:55:23 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <506268D3.7000500@oracle.com> Message-ID: <1525852294.2007489.1348667723264.JavaMail.root@redhat.com> ----- Original Message ----- > > > On 9/18/2012 7:39 AM, Andrew Hughes wrote: > > The following simple webrev will achieve what I think is needed: > > > > http://cr.openjdk.java.net/~andrew/100062/webrev.01/ > > > > allowing OpenJDK to be built with the unlimited rather than limited > > crypto policy in place. > > I got a chance to talk to Valerie, and what you've done looks good. > I'm > "wetmore" if you need a reviewer, and I think Kelly has looked at it > too. Thanks Brad. > > > I just placed it within the OPENJDK ifdef so it > > won't interfere with the proprietary build at all, as obviously I > > can't test it > > Please leave your new code check within the "ifdef OPENJDK". > > Will you be putting this back yourself? If so let me know when you > go > in, and I can update the bug once you're in. > I will, though I'll need a bug ID for it. I presume tl is ok as the forest to use? > Mark wrote: > > The summary is that it was just easier to remove unused classes > > that > > made the code tricky to understand for no good reason except for > > some > > secret proprietary code. > > Unfortunately, Oracle and some of our commercial (non-OpenJDK) > licensees > still depend on that tricky code. :( I'd personally love to strip > it > all out, but we have to balance all of its consumers (Oracle SE and > ME, > commercial source/binary licensees, OpenJDK, etc.) > > Andrew wrote: > > I'm sure it would be easy enough to dump those classes if Oracle > > started producing OpenJDK binaries licensed under the GPL, rather > > than binaries from their proprietary fork. > > Unfortunately, not likely in our current export/import climate. > Yes, this is what I thought. We just have to make sure to test well before shipping binaries. > Brad > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Wed Sep 26 16:16:21 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 26 Sep 2012 09:16:21 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1525852294.2007489.1348667723264.JavaMail.root@redhat.com> References: <1525852294.2007489.1348667723264.JavaMail.root@redhat.com> Message-ID: <50632A55.8040106@oracle.com> >> Will you be putting this back yourself? If so let me know when you >> go >> in, and I can update the bug once you're in. >> > > I will, though I'll need a bug ID for it. I presume tl is ok as the > forest to use? This going into 8? Then yes. 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK. Brad >> Mark wrote: >> > The summary is that it was just easier to remove unused classes >> > that >> > made the code tricky to understand for no good reason except for >> > some >> > secret proprietary code. >> >> Unfortunately, Oracle and some of our commercial (non-OpenJDK) >> licensees >> still depend on that tricky code. :( I'd personally love to strip >> it >> all out, but we have to balance all of its consumers (Oracle SE and >> ME, >> commercial source/binary licensees, OpenJDK, etc.) >> >> Andrew wrote: >> > I'm sure it would be easy enough to dump those classes if Oracle >> > started producing OpenJDK binaries licensed under the GPL, rather >> > than binaries from their proprietary fork. >> >> Unfortunately, not likely in our current export/import climate. >> > > Yes, this is what I thought. We just have to make sure to test well > before shipping binaries. > >> Brad >> >> > From david.katleman at oracle.com Thu Sep 27 05:47:58 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:47:58 +0000 Subject: hg: jdk8/build: Added tag jdk8-b57 for changeset 522dfac8ca4d Message-ID: <20120927054758.D1E53470B5@hg.openjdk.java.net> Changeset: 936702480487 Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/936702480487 Added tag jdk8-b57 for changeset 522dfac8ca4d ! .hgtags From david.katleman at oracle.com Thu Sep 27 05:48:02 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:48:02 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b57 for changeset f3ab4163ae01 Message-ID: <20120927054803.96638470B6@hg.openjdk.java.net> Changeset: 18462a19f7bd Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/18462a19f7bd Added tag jdk8-b57 for changeset f3ab4163ae01 ! .hgtags From david.katleman at oracle.com Thu Sep 27 05:49:47 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:49:47 +0000 Subject: hg: jdk8/build/hotspot: 38 new changesets Message-ID: <20120927055122.C6CB2470B7@hg.openjdk.java.net> Changeset: da0d652d0c2f Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/da0d652d0c2f Added tag jdk8-b57 for changeset d70102c4cb73 ! .hgtags Changeset: 36d1d483d5d6 Author: jcoomes Date: 2012-08-31 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/36d1d483d5d6 7195615: new hotspot build - hs25-b01 Reviewed-by: johnc ! make/hotspot_version Changeset: da91efe96a93 Author: coleenp Date: 2012-09-01 13:25 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/da91efe96a93 6964458: Reimplement class meta-data storage to use native memory Summary: Remove PermGen, allocate meta-data in metaspace linked to class loaders, rewrite GC walking, rewrite and rename metadata to be C++ classes Reviewed-by: jmasa, stefank, never, coleenp, kvn, brutisso, mgerdin, dholmes, jrose, twisti, roland Contributed-by: jmasa , stefank , mgerdin , never ! agent/doc/clhsdb.html ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java + agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/ParallelScavengeHeap.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Dictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Generation.java ! agent/src/share/classes/sun/jvm/hotspot/memory/GenerationFactory.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SharedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/AccessFlags.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BooleanField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ByteField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CIntField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CharField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CheckedExceptionElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolder.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheEntry.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java + agent/src/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/DefaultOopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/DoubleField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java + agent/src/share/classes/sun/jvm/hotspot/oops/FieldVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/FloatField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java + agent/src/share/classes/sun/jvm/hotspot/oops/InstanceClassLoaderKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/InstanceRefKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/IntField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/LocalVariableTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/LongField.java + agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java + agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java + agent/src/share/classes/sun/jvm/hotspot/oops/MetadataVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogramElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopPrinter.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ShortField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JNIid.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/CodeViewerPanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadAddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java + agent/src/share/classes/sun/jvm/hotspot/ui/tree/MetadataTreeNodeAdapter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GenericArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java + agent/src/share/classes/sun/jvm/hotspot/utilities/IntArray.java + agent/src/share/classes/sun/jvm/hotspot/utilities/KlassArray.java + agent/src/share/classes/sun/jvm/hotspot/utilities/MethodArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/U1Array.java + agent/src/share/classes/sun/jvm/hotspot/utilities/U2Array.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactory.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFrame.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaMethod.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaScriptEngine.java + agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/mapfile-vers-COMPILER1 ! make/solaris/makefiles/mapfile-vers-COMPILER2 ! make/solaris/makefiles/mapfile-vers-TIERED ! make/solaris/makefiles/product.make ! make/solaris/makefiles/profiled.make - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 ! make/solaris/makefiles/sparc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make - make/solaris/reorder.sh ! make/windows/create_obj_files.sh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/debug_sparc.cpp - src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp + src/cpu/sparc/vm/metaspaceShared_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp + src/cpu/x86/vm/metaspaceShared_x86_32.cpp + src/cpu/x86/vm/metaspaceShared_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/cpu/zero/vm/bytecodeInterpreter_zero.cpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp - src/cpu/zero/vm/dump_zero.cpp ! src/cpu/zero/vm/entry_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/interpreterFrame_zero.hpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/interpreter_zero.hpp + src/cpu/zero/vm/metaspaceShared_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/templateInterpreter_zero.cpp ! src/cpu/zero/vm/templateTable_zero.cpp ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp - src/share/vm/ci/ciArrayKlassKlass.hpp + src/share/vm/ci/ciBaseObject.cpp + src/share/vm/ci/ciBaseObject.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstantPoolCache.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp ! src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMetadata.cpp + src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciMethodHandle.cpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp + src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/classLoaderData.hpp + src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/exceptionHandlerTable.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/oopRecorder.cpp ! src/share/vm/code/oopRecorder.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmStructs_parallelgc.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/blockOffsetTable.inline.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp - src/share/vm/memory/dump.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/memRegion.hpp + src/share/vm/memory/metadataFactory.hpp + src/share/vm/memory/metaspace.cpp + src/share/vm/memory/metaspace.hpp + src/share/vm/memory/metaspaceCounters.cpp + src/share/vm/memory/metaspaceCounters.hpp + src/share/vm/memory/metaspaceShared.cpp + src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp + src/share/vm/oops/annotations.cpp + src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/arrayOop.hpp + src/share/vm/oops/compiledICHolder.cpp + src/share/vm/oops/compiledICHolder.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp + src/share/vm/oops/constMethod.cpp + src/share/vm/oops/constMethod.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp + src/share/vm/oops/constantPool.cpp + src/share/vm/oops/constantPool.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp + src/share/vm/oops/cpCache.cpp + src/share/vm/oops/cpCache.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp + src/share/vm/oops/instanceClassLoaderKlass.cpp + src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/markOop.inline.hpp + src/share/vm/oops/metadata.cpp + src/share/vm/oops/metadata.hpp + src/share/vm/oops/method.cpp + src/share/vm/oops/method.hpp + src/share/vm/oops/methodData.cpp + src/share/vm/oops/methodData.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnv.xsl ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiLib.xsl ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/privilegedStack.cpp ! src/share/vm/prims/privilegedStack.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/wbtestmethods/parserTests.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jfieldIDWorkaround.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/rframe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.inline.hpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/psMemoryPool.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/serviceUtil.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkRuntime.cpp ! src/share/vm/shark/sharkRuntime.hpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp ! test/compiler/6859338/Test6859338.java Changeset: 03049e0e8544 Author: coleenp Date: 2012-09-03 18:37 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/03049e0e8544 7195823: NPG: CMS reserved() doesn't match _rs.base(). Summary: If the commit fails, the size isn't set so the assert fails. Reviewed-by: kamg ! src/share/vm/memory/metaspace.cpp Changeset: 46c017102631 Author: stefank Date: 2012-09-04 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/46c017102631 7195968: NPG: oopDesc::list_ptr_from_klass is broken Summary: Remove incorrect cast Reviewed-by: brutisso, coleenp ! src/share/vm/oops/oop.inline.hpp Changeset: ca11db66f9de Author: roland Date: 2012-09-04 23:27 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ca11db66f9de 7184649: NPG: Implement another MetdataPtr case Summary: xmeet when both inputs are MetadataPtr. Reviewed-by: kvn ! src/share/vm/opto/type.cpp Changeset: d17383603741 Author: twisti Date: 2012-09-04 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d17383603741 7196120: NPG: JSR 2292 test fails because missing fix for 7188911 Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 5d2156bcb78b Author: jmasa Date: 2012-09-04 16:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5d2156bcb78b 7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong Reviewed-by: coleenp, jcoomes ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp Changeset: 044a77cd0c8b Author: stefank Date: 2012-09-05 10:39 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/044a77cd0c8b 7195935: NPG: Some issues with compressed oops Summary: Don't decompress the klass pointer in the G1 pre-barrier code when !UseCompressedKlassPointers Reviewed-by: coleenp, brutisso ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 78b56e53050e Author: kvn Date: 2012-09-05 10:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/78b56e53050e 7196167: NPG: mismerge in make/solaris/makefiles/fastdebug.make Summary: Remove the workaround of 7187454 problem which was restored incorrectly during NPG merge. Reviewed-by: coleenp, dholmes ! make/solaris/makefiles/fastdebug.make Changeset: fa6e618671d7 Author: coleenp Date: 2012-09-05 20:08 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fa6e618671d7 7195867: NPG: SAJDI tests fail with sun.jvm.hotspot.types.WrongTypeException: No suitable match for type Summary: Need to restore the vtable in metadata when we restore the type from the shared archive. Reviewed-by: acorn, jcoomes, jmasa, jrose ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/method.hpp Changeset: 942bb29b20b0 Author: jmasa Date: 2012-09-06 07:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/942bb29b20b0 7196298: Better fix for 7195789 Reviewed-by: jcoomes, brutisso ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp Changeset: aed758eda82a Author: coleenp Date: 2012-09-07 12:04 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aed758eda82a 7195833: NPG: Rename instanceClassLoaderKlass, instanceRefKlass and instanceMirrorKlass Summary: Simple renaming to be consistent with instanceKlass->InstanceKlass renaming Reviewed-by: stefank, jmasa ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceClassLoaderKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceRefKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 11fb740ce98f Author: coleenp Date: 2012-09-07 16:42 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/11fb740ce98f 7196103: NPG: Unable to allocate bit map for parallel garbage collection for the requested heap size Summary: Don't allocate huge class metaspace size by default on x64 Reviewed-by: stefank, jmasa, kvn ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4bfe8b33cf66 Author: twisti Date: 2012-09-10 16:37 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4bfe8b33cf66 7196242: vm/mlvm/indy/stress/java/loopsAndThreads crashed Reviewed-by: jrose, coleenp, jmasa, kvn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: ec98e58952b2 Author: stefank Date: 2012-09-11 14:59 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ec98e58952b2 7197350: NPG: jvmtiHeapReferenceCallback receives incorrect reference_kind for system class roots Summary: Fix the iteration over the system classes and report the correct reference kind. Reviewed-by: coleenp, rbackman ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 8a02ca5e5576 Author: roland Date: 2012-09-11 16:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8a02ca5e5576 7195816: NPG: Crash in c1_ValueType - ShouldNotReachHere Summary: C1 needs knowledge of T_METADATA at the LIR level. Reviewed-by: kvn, coleenp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/globalDefinitions.cpp Changeset: 75f33eecc1b3 Author: coleenp Date: 2012-09-11 20:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/75f33eecc1b3 7196681: NPG: Some JSR 292 tests crash in Windows exception handler Summary: There was a rogue os::breakpoint() call in log_dependency left over from the jsr292 merge. Also changed verify_oop() calls for metadata to verify_{method,klass}_ptr. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/code/dependencies.cpp Changeset: 33143ee07800 Author: zgu Date: 2012-09-11 20:53 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/33143ee07800 7181995: NMT ON: NMT assertion failure assert(cur_vm->is_uncommit_record() || cur_vm->is_deallocation_record Summary: Fixed virtual memory records merge and promotion logic, should be based on sequence number vs. base address order Reviewed-by: coleenp, acorn ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 3f18d439b402 Author: zgu Date: 2012-09-11 18:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3f18d439b402 Merge Changeset: 43d524adb671 Author: zgu Date: 2012-09-11 20:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/43d524adb671 Merge Changeset: 7edbe32b9802 Author: roland Date: 2012-09-13 22:09 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7edbe32b9802 7198074: NPG: assert(((Metadata*)obj)->is_valid()) failed: obj is valid Summary: missing test for T_METADATA leads to incorrect register allocation. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 6dfc6a541338 Author: zgu Date: 2012-09-14 12:55 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6dfc6a541338 7198529: NPG: assert with NMT code in Thread destructor Summary: Thread stack's base address can be NULL if it is not started or exited before recording the base Reviewed-by: kvn, fparain ! src/share/vm/runtime/thread.cpp Changeset: 9b076bc3ab67 Author: amurillo Date: 2012-09-14 21:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9b076bc3ab67 Merge - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp Changeset: 80e4129f0e28 Author: amurillo Date: 2012-09-14 21:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/80e4129f0e28 Added tag hs25-b01 for changeset 9b076bc3ab67 ! .hgtags Changeset: a6fe94b9759f Author: amurillo Date: 2012-09-14 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a6fe94b9759f 7198641: new hotspot build - hs25-b02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 859cd1a76f8a Author: brutisso Date: 2012-09-13 21:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/859cd1a76f8a 7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32 bit shifts Reviewed-by: brutisso, johnc, ysr Contributed-by: Hal Mo ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/blockOffsetTable.hpp Changeset: 2a48c84f1d04 Author: coleenp Date: 2012-09-17 10:46 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2a48c84f1d04 7197269: NPG: FollowReferences has no ClassLoader -> Class link to follow Summary: restore java/lang/ClassLoader.addClass() upcall Reviewed-by: sspitsyn, dcubed, jmasa ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 9646b7ff4d14 Author: brutisso Date: 2012-09-17 10:33 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9646b7ff4d14 7198130: G1: PrintReferenceGC output comes out of order Summary: Move the first part of the GC logging, including timestamp, to the start of the GC Reviewed-by: johnc, jwilhelm ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/runtime/timer.cpp Changeset: 8da5e203b993 Author: jmasa Date: 2012-09-18 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8da5e203b993 7197557: NPG: nsk/sysdict/vm/stress/chain/chain004 hangs intermittently Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 8fbf05030e24 Author: johnc Date: 2012-09-19 08:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8fbf05030e24 7016955: G1: remove the is_zeroed parameter from the HeapRegion constructor Summary: The is_zeroed parameter is no longer used and so can be removed. Reviewed-by: johnc, jmasa, brutisso Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: bc675e55b48c Author: johnc Date: 2012-09-19 15:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bc675e55b48c 7193946: Move warnings associated with UseMemSetInBOT flag Summary: The warnings associated with the UseMemSetInBOT flag are duplicated in CMS and G1. The separate warnings have been removed and single instance of the warning has been placed in a common location. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b2ef234911c9 Author: johnc Date: 2012-09-20 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b2ef234911c9 7190666: G1: assert(_unused == 0) failed: Inconsistency in PLAB stats Summary: Reset the fields in ParGCAllocBuffer, that are used for accumulating values for the ResizePLAB sensors in PLABStats, to zero after flushing the values to the PLABStats fields. Flush PLABStats values only when retiring the final allocation buffers prior to disposing of a G1ParScanThreadState object, rather than when retiring every allocation buffer. Reviewed-by: jwilhelm, jmasa, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: e861d44e0c9c Author: jmasa Date: 2012-09-20 12:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e861d44e0c9c 7199923: NPG: tools/javac/T7093325.java timeout Reviewed-by: stefank, coleenp, kvn ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 46b3b2dd84db Author: jmasa Date: 2012-09-20 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/46b3b2dd84db Merge Changeset: 145ffab733e7 Author: jcoomes Date: 2012-09-20 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/145ffab733e7 7199082: write warning messages to stderr Reviewed-by: ysr, dholmes, sla ! src/share/vm/utilities/debug.cpp Changeset: 5f54277c67f7 Author: amurillo Date: 2012-09-21 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5f54277c67f7 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp Changeset: 6bb378c50828 Author: amurillo Date: 2012-09-21 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6bb378c50828 Added tag hs25-b02 for changeset 5f54277c67f7 ! .hgtags From david.katleman at oracle.com Thu Sep 27 05:52:51 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:52:51 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b57 for changeset 7c9475c7618c Message-ID: <20120927055257.00363470B8@hg.openjdk.java.net> Changeset: 1cb19abb3f7b Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/1cb19abb3f7b Added tag jdk8-b57 for changeset 7c9475c7618c ! .hgtags From david.katleman at oracle.com Thu Sep 27 05:53:02 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:53:02 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b57 for changeset b51b611209f1 Message-ID: <20120927055305.F266C470B9@hg.openjdk.java.net> Changeset: cac4c3937063 Author: katleman Date: 2012-09-20 13:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/cac4c3937063 Added tag jdk8-b57 for changeset b51b611209f1 ! .hgtags From david.katleman at oracle.com Thu Sep 27 05:54:51 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 05:54:51 +0000 Subject: hg: jdk8/build/jdk: 65 new changesets Message-ID: <20120927061408.2BC80470BA@hg.openjdk.java.net> Changeset: 34202653829a Author: katleman Date: 2012-09-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/34202653829a Added tag jdk8-b57 for changeset 51594d095a4b ! .hgtags Changeset: 8a64eeca4450 Author: jgodinez Date: 2012-09-10 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a64eeca4450 7183516: [macosx]Can't print-out the defined fonts for PrintFont_2D and AntialiasTableTest. Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: db828a233f20 Author: bae Date: 2012-09-11 13:32 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/db828a233f20 7181199: [macosx] Startup is much slower in headless mode for apps using Fonts Reviewed-by: jgodinez, prr ! src/macosx/classes/sun/font/CFontManager.java Changeset: bce9611f1e8f Author: lana Date: 2012-09-14 13:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bce9611f1e8f Merge ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 0ecf1a700fca Author: bae Date: 2012-09-17 13:44 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0ecf1a700fca 7186799: Regression tests for ImageIO metadata fail on second run Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev ! test/javax/imageio/metadata/BooleanAttributes.java ! test/javax/imageio/metadata/DOML3Node.java + test/javax/imageio/metadata/GetChildNames.java + test/javax/imageio/metadata/GetObjectMinValue.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatThreadTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataTest.java + test/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh + test/javax/imageio/metadata/IIOMetadataFormatImplTest.java + test/javax/imageio/metadata/MetadataFormatPrinter.java + test/javax/imageio/metadata/ObjectArrayMaxLength.java + test/javax/imageio/metadata/RegisteredFormatsTest.java + test/javax/imageio/metadata/RemoveElement.java + test/javax/imageio/metadata/SetAttributeNode.java Changeset: 47442b1b01eb Author: kizune Date: 2012-09-06 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/47442b1b01eb 7175183: [macosx] Objective-C exception thrown when switching monitor configuration Reviewed-by: prr, serb ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java Changeset: d14dc0ae1c2c Author: bagiras Date: 2012-09-06 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d14dc0ae1c2c 7153339: InternalError when drawLine with Xor and Antialiasing Reviewed-by: prr, flar ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: b8a1ff892b33 Author: alexsch Date: 2012-09-07 13:08 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b8a1ff892b33 7194469: Pressing the Enter key results in an alert tone beep when focus is TextField Reviewed-by: bagiras, denis ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: 04292c0c943b Author: malenkov Date: 2012-09-11 10:58 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/04292c0c943b 7193977: REGRESSION:Java 7's JavaBeans persistence ignoring the "transient" flag on properties Reviewed-by: rupashka ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7193977.java Changeset: 3a2f5544dd00 Author: serb Date: 2012-09-12 21:16 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3a2f5544dd00 7124534: [macosx] Submenu title overlaps with Submenu indicator in JPopupMenu Reviewed-by: art + test/javax/swing/JMenuItem/6438430/bug6438430.java Changeset: aa35dc4d3f70 Author: bagiras Date: 2012-09-13 19:53 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/aa35dc4d3f70 7186109: Simplify lock machinery for PostEventQueue & EventQueue Reviewed-by: art, anthony, dholmes ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java Changeset: 5b7ad5bedbd7 Author: bagiras Date: 2012-09-13 21:23 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5b7ad5bedbd7 7198318: SunToolkitSubclass.java should be removed Reviewed-by: serb - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 5444be588d18 Author: alexsch Date: 2012-09-14 15:08 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5444be588d18 7197320: [macosx] Full Screen option missing when Window.documentModified Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 77fdcd3df205 Author: alexsch Date: 2012-09-14 15:30 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/77fdcd3df205 7196547: [macosx] Implement dead key detection for KeyEvent Reviewed-by: skovatch, kizune ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java Changeset: 1785f8335f4d Author: VKARNAUK Date: 2012-09-14 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1785f8335f4d 6994562: Swing classes (both JTextArea and JTextField) don't support caret width tuning Reviewed-by: rupashka, art ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.h Changeset: b6ad3339f3f4 Author: lana Date: 2012-09-14 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b6ad3339f3f4 Merge Changeset: 1ed7fec79bee Author: leonidr Date: 2012-09-17 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1ed7fec79bee 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb Contributed-by: Marco Dinacci ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/DnDUtilities.h ! src/macosx/native/sun/awt/DnDUtilities.m Changeset: 1d1254af05dd Author: kshefov Date: 2012-09-18 17:38 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1d1254af05dd 7190587: Open source and jtreg'ify JAWT regression test Reviewed-by: anthony, omajid + test/java/awt/JAWT/JAWT.sh + test/java/awt/JAWT/Makefile.cygwin + test/java/awt/JAWT/Makefile.unix + test/java/awt/JAWT/Makefile.win + test/java/awt/JAWT/MyCanvas.java + test/java/awt/JAWT/myfile.c + test/java/awt/JAWT/myfile.cpp Changeset: a96f5b1d03f9 Author: lana Date: 2012-09-19 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a96f5b1d03f9 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 076d0dafea5f Author: mgerdin Date: 2012-09-06 14:07 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/076d0dafea5f 7195557: NPG: Unexpected number of memory pools Summary: Update management tests to work with a VM without a permanent generation memory pool Reviewed-by: rbackman, brutisso, sla, dholmes ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java Changeset: 8c6895afe204 Author: lancea Date: 2012-09-06 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8c6895afe204 7192302: Remove JDBCRowSetImpl dependency on java.beans Reviewed-by: alanb, mchung ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java Changeset: 833f4630f3a1 Author: weijun Date: 2012-09-07 10:24 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/833f4630f3a1 7196677: diff compares same file to itself in PaddingTest regression test. Reviewed-by: xuelei ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java Changeset: d5d24c08f0dc Author: chegar Date: 2012-09-07 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d5d24c08f0dc 7032247: java/net/InetAddress/GetLocalHostWithSM.java fails if hostname resolves to loopback address Summary: TESTBUG Reviewed-by: chegar, alanb Contributed-by: Eric Wang ! test/java/net/InetAddress/GetLocalHostWithSM.java Changeset: 3857114d8255 Author: chegar Date: 2012-09-07 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3857114d8255 6354758: rename old test HttpServer classes Reviewed-by: chegar, michaelm, khazra Contributed-by: John Zavgren ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URLConnection/B5052093.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java - test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/httptest/HttpTransaction.java + test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java + test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 7f081e14364e Author: mullan Date: 2012-09-07 12:49 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7f081e14364e 4647343: IDENT variable in sun.security.x509 classes not used Reviewed-by: mullan Contributed-by: jason.uh at oracle.com - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java Changeset: fffbb33df102 Author: coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency.properties file Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Currency/currency.properties Changeset: a51f86e2dce9 Author: mullan Date: 2012-09-10 08:57 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a51f86e2dce9 7195301: XML Signature DOM implementation should not use instanceof to determine type of Node Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java Changeset: a14d41fd6f51 Author: mullan Date: 2012-09-10 09:00 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a14d41fd6f51 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 657f7cb0da7e Author: mullan Date: 2012-09-10 09:18 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/657f7cb0da7e Merge Changeset: 2598dad44449 Author: dsamersoff Date: 2012-09-11 19:58 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2598dad44449 7194597: Typeo in com.sun.management.VMOption.toString() Summary: VMOption.toString() returns "...(read-only)" if writable "...(read-write)" otherwise. Reviewed-by: alanb, mchung Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/management/VMOption.java Changeset: 1f7c783e4f13 Author: dxu Date: 2012-08-31 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1f7c783e4f13 7193406: Clean-up JDK Build Warnings in java.util, java.io Summary: Clean-up JDK Build Warnings in java.util, java.io Packages Reviewed-by: smarks, darcy, khazra, dholmes, forax, dl, andrew, aph, omajid, ulfzibis, christos, mduigou ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/sun/util/PreHashedMap.java Changeset: 7a16cd3bd2d9 Author: mullan Date: 2012-09-12 15:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7a16cd3bd2d9 7196593: java.security.debug=help doesn't list certpath option Reviewed-by: mullan, wetmore, valeriep Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/util/Debug.java Changeset: f8c1cf072ba6 Author: mullan Date: 2012-09-12 15:21 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f8c1cf072ba6 Merge Changeset: e095be3820ee Author: chegar Date: 2012-09-13 11:17 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e095be3820ee 7197203: sun/misc/URLClassPath/ClassnameCharTest.sh failed, compile error Reviewed-by: alanb ! test/sun/misc/URLClassPath/ClassnameCharTest.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: e8a3807de977 Author: alanb Date: 2012-09-13 15:04 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8a3807de977 7197637: (ch) sun.nio.ch.Default* cause providers for other platforms to be included in rt.jar Reviewed-by: mchung ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java Changeset: eae1384cff39 Author: mullan Date: 2012-09-14 10:13 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/eae1384cff39 7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status) Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java Changeset: 34bcbb110bb0 Author: mullan Date: 2012-09-14 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/34bcbb110bb0 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c11cec5a9306 Author: mullan Date: 2012-09-14 10:30 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c11cec5a9306 Merge - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: 22d7a9f73a59 Author: mchung Date: 2012-09-14 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/22d7a9f73a59 7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo Reviewed-by: alanb, sla, egahlin ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ThreadInfo.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java + src/share/classes/sun/management/LockInfoCompositeData.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Changeset: 356ff53c9b6d Author: lana Date: 2012-09-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/356ff53c9b6d Merge - test/java/lang/invoke/MaxTest.java Changeset: 92f3cda88d8e Author: mduigou Date: 2012-09-11 07:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/92f3cda88d8e 7189926: Reduce test size for default run. Add additional run enabling alternative hashing. Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 17881ebf811c Author: mullan Date: 2012-09-16 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/17881ebf811c 7195409: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest fails with NullPointerException Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 0c3b0a82c4fc Author: weijun Date: 2012-09-17 17:19 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0c3b0a82c4fc 7198205: CloseTest fails on mac Reviewed-by: alanb, chegar, michaelm ! test/ProblemList.txt ! test/java/net/URLClassLoader/closetest/CloseTest.java Changeset: 39e97f68fa8c Author: sla Date: 2012-09-17 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/39e97f68fa8c 7198846: Add javax/management/remote/mandatory/notif/DiffHBTest.java to ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt Changeset: f56f85040c58 Author: weijun Date: 2012-09-17 18:19 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f56f85040c58 7196855: autotest.sh fails on ubuntu because libsoftokn.so not found Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 8a454e92aaf1 Author: sla Date: 2012-09-17 12:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a454e92aaf1 7198849: Make javax/management/remote/mandatory/notif/ListenerScaleTest.java less timing sensitive Reviewed-by: alanb ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java Changeset: e20a2e6a92f7 Author: mduigou Date: 2012-09-17 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e20a2e6a92f7 7198988: re-order paramaters for Collision.java @run Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 53ca38f76eaa Author: weijun Date: 2012-09-18 17:38 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/53ca38f76eaa 7198871: cleanup security tests in problem lists with no CR attached Reviewed-by: alanb ! test/ProblemList.txt Changeset: 95a93f039e5c Author: vinnie Date: 2012-09-18 11:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/95a93f039e5c 7198901: correct the field size check when decoding a point on ECC curve Reviewed-by: xuelei ! src/share/classes/sun/security/ec/ECParameters.java Changeset: bc5e7ec12717 Author: dxu Date: 2012-09-18 13:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc5e7ec12717 7142919: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing intermittently [sol11] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 88a4f699d233 Author: xuelei Date: 2012-09-18 06:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/88a4f699d233 7199066: Typo in method name Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 0136fca60652 Author: naoto Date: 2012-09-18 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0136fca60652 7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/ProblemList.txt Changeset: e7add6d98729 Author: mduigou Date: 2012-09-18 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e7add6d98729 7199249: TEST_BUG : Add /othervm to Collisions.java @run main with -D definitions Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: db381a2c0083 Author: alanb Date: 2012-09-18 21:21 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/db381a2c0083 7190273: Deprecate com.sun.security.auth.callback.DialogCallbackHandler Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java Changeset: e143d8f8e477 Author: dxu Date: 2012-09-18 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e143d8f8e477 7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc page of Package java.util.zip Summary: Correct a java doc link in java.util.zip package page Reviewed-by: chegar, lancea, sherman Contributed-by: dan.xu at oracle.com ! src/share/classes/java/util/zip/package.html Changeset: 045a0962b430 Author: mchung Date: 2012-09-18 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/045a0962b430 7198070: Eliminate static dependency from JMX to java.beans.ConstructorProperties Reviewed-by: alanb ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java Changeset: 5d064862376d Author: jgish Date: 2012-09-19 08:52 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5d064862376d 4722265: (spec str) StringBuffer.ensureCapacity() should mention that capacity is mutable Summary: add usage note to AbstractStringBuilder ensureCapacity() Reviewed-by: mduigou, dholmes, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 27182d84a244 Author: chegar Date: 2012-09-19 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/27182d84a244 7199500: Minor typo in AbstractStringBuilder.java header Reviewed-by: coffeys ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 002717a1418f Author: lana Date: 2012-09-19 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/002717a1418f Merge - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3f876919cd58 Author: lana Date: 2012-09-24 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3f876919cd58 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 1e827cc26cf6 Author: jcoomes Date: 2012-09-14 15:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1e827cc26cf6 7198162: exclude test MemoryMXBean/LowMemoryTest2.sh Reviewed-by: alanb, dsamersoff, sspitsyn ! test/ProblemList.txt Changeset: 058d66fa372b Author: jcoomes Date: 2012-09-14 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/058d66fa372b 7198676: NPG: exclude MemoryMXBean tests which assume a perm gen Reviewed-by: dcubed ! test/ProblemList.txt Changeset: 1dde94130b0c Author: jcoomes Date: 2012-09-21 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1dde94130b0c Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk Changeset: 4015dec20965 Author: amurillo Date: 2012-09-26 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4015dec20965 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! test/ProblemList.txt - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: d94613ac03d8 Author: katleman Date: 2012-09-26 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d94613ac03d8 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java From david.katleman at oracle.com Thu Sep 27 06:17:16 2012 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 27 Sep 2012 06:17:16 +0000 Subject: hg: jdk8/build/langtools: 11 new changesets Message-ID: <20120927061742.218A0470BB@hg.openjdk.java.net> Changeset: bc42f20bfe48 Author: katleman Date: 2012-09-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bc42f20bfe48 Added tag jdk8-b57 for changeset 86d5740b9fdc ! .hgtags Changeset: 489905e5018e Author: jjg Date: 2012-09-07 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/489905e5018e 7186925: JavapTask passes null to java.io.Writer Reviewed-by: jjh ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T7186925.java Changeset: 324b98626f58 Author: jjg Date: 2012-09-07 11:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/324b98626f58 7196774: javac cannot be built with JDK 6 after 7151010 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java Changeset: 1a7c11b22192 Author: jjg Date: 2012-09-07 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1a7c11b22192 7196760: tree end positions incorrect after anno processing Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/api/EndPositions.java Changeset: fa85af323d97 Author: bpatel Date: 2012-09-08 22:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/fa85af323d97 7180906: Javadoc tool does not apply parameter -nosince Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + test/com/sun/javadoc/testSinceTag/TestSinceTag.java + test/com/sun/javadoc/testSinceTag/pkg1/C1.java Changeset: b2064a216117 Author: bpatel Date: 2012-09-08 22:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/b2064a216117 Merge Changeset: 30c36e23f154 Author: jjg Date: 2012-09-13 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/30c36e23f154 7177970: fix issues in langtools doc comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/javadoc/Doc.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/tools/JavaCompiler.java Changeset: fabfd2710057 Author: ksrini Date: 2012-09-14 09:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/fabfd2710057 7192073: (javac) minor refactoring of tree maker to help IDEs Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java Changeset: 8c3c714eb7de Author: lana Date: 2012-09-14 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8c3c714eb7de Merge Changeset: a433bd8f3ba9 Author: lana Date: 2012-09-14 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a433bd8f3ba9 Merge Changeset: 804a3fbc86e2 Author: lana Date: 2012-09-24 21:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/804a3fbc86e2 Merge From james.holmlund at oracle.com Thu Sep 27 16:41:09 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Thu, 27 Sep 2012 09:41:09 -0700 Subject: warnings from configure on solaris sparc Message-ID: <506481A5.6060602@oracle.com> : checking for IceConnectionNumber in -lICE... yes checking X11/extensions/shape.h usability... no checking X11/extensions/shape.h presence... yes configure: WARNING: X11/extensions/shape.h: present but cannot be compiled configure: WARNING: X11/extensions/shape.h: check for missing prerequisite headers? configure: WARNING: X11/extensions/shape.h: see the Autoconf documentation configure: WARNING: X11/extensions/shape.h: section "Present But Cannot Be Compiled" configure: WARNING: X11/extensions/shape.h: proceeding with the compiler's result configure: WARNING: ## ----------------------------------------- ## configure: WARNING: ## Report this to build-dev at openjdk.java.net ## configure: WARNING: ## ----------------------------------------- ## The machine is SunOS mmm 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-2500 - jjh From gnu.andrew at redhat.com Thu Sep 27 16:50:26 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Sep 2012 12:50:26 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <50632A55.8040106@oracle.com> Message-ID: <1682174572.3031768.1348764626958.JavaMail.root@redhat.com> ----- Original Message ----- > > >> Will you be putting this back yourself? If so let me know when > >> you > >> go > >> in, and I can update the bug once you're in. > >> > > > > I will, though I'll need a bug ID for it. I presume tl is ok as > > the > > forest to use? > > This going into 8? Then yes. > At first, yes. Do you have any objections to me proposing it for 7u too, in due course? > 7201205: Add Makefile configuration option to build with unlimited > crypto in OpenJDK. > Great, thanks! I'll push it. > Brad > > > > >> Mark wrote: > >> > The summary is that it was just easier to remove unused > >> > classes > >> > that > >> > made the code tricky to understand for no good reason except > >> > for > >> > some > >> > secret proprietary code. > >> > >> Unfortunately, Oracle and some of our commercial (non-OpenJDK) > >> licensees > >> still depend on that tricky code. :( I'd personally love to > >> strip > >> it > >> all out, but we have to balance all of its consumers (Oracle SE > >> and > >> ME, > >> commercial source/binary licensees, OpenJDK, etc.) > >> > >> Andrew wrote: > >> > I'm sure it would be easy enough to dump those classes if > >> > Oracle > >> > started producing OpenJDK binaries licensed under the GPL, > >> > rather > >> > than binaries from their proprietary fork. > >> > >> Unfortunately, not likely in our current export/import climate. > >> > > > > Yes, this is what I thought. We just have to make sure to test > > well > > before shipping binaries. > > > >> Brad > >> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Sep 27 16:58:11 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Sep 2012 12:58:11 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1682174572.3031768.1348764626958.JavaMail.root@redhat.com> Message-ID: <1057179810.3034228.1348765091452.JavaMail.root@redhat.com> ----- Original Message ----- > ----- Original Message ----- > > > > >> Will you be putting this back yourself? If so let me know when > > >> you > > >> go > > >> in, and I can update the bug once you're in. > > >> > > > > > > I will, though I'll need a bug ID for it. I presume tl is ok as > > > the > > > forest to use? > > > > This going into 8? Then yes. > > > > At first, yes. Do you have any objections to me proposing it for 7u > too, in due course? > > > 7201205: Add Makefile configuration option to build with unlimited > > crypto in OpenJDK. > > > > Great, thanks! I'll push it. > All done: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e879c0288c2 > > Brad > > > > > > > > >> Mark wrote: > > >> > The summary is that it was just easier to remove unused > > >> > classes > > >> > that > > >> > made the code tricky to understand for no good reason except > > >> > for > > >> > some > > >> > secret proprietary code. > > >> > > >> Unfortunately, Oracle and some of our commercial (non-OpenJDK) > > >> licensees > > >> still depend on that tricky code. :( I'd personally love to > > >> strip > > >> it > > >> all out, but we have to balance all of its consumers (Oracle SE > > >> and > > >> ME, > > >> commercial source/binary licensees, OpenJDK, etc.) > > >> > > >> Andrew wrote: > > >> > I'm sure it would be easy enough to dump those classes if > > >> > Oracle > > >> > started producing OpenJDK binaries licensed under the GPL, > > >> > rather > > >> > than binaries from their proprietary fork. > > >> > > >> Unfortunately, not likely in our current export/import climate. > > >> > > > > > > Yes, this is what I thought. We just have to make sure to test > > > well > > > before shipping binaries. > > > > > >> Brad > > >> > > >> > > > > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Thu Sep 27 18:42:45 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 27 Sep 2012 11:42:45 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1682174572.3031768.1348764626958.JavaMail.root@redhat.com> References: <1682174572.3031768.1348764626958.JavaMail.root@redhat.com> Message-ID: <50649E25.8000209@oracle.com> On 9/27/2012 9:50 AM, Andrew Hughes wrote: > ----- Original Message ----- >> >>>> Will you be putting this back yourself? If so let me know when >>>> you >>>> go >>>> in, and I can update the bug once you're in. >>>> >>> >>> I will, though I'll need a bug ID for it. I presume tl is ok as >>> the >>> forest to use? >> >> This going into 8? Then yes. >> > > At first, yes. Do you have any objections to me proposing it for 7u too, in due course? None here, other than needing a separate code review. Brad >> 7201205: Add Makefile configuration option to build with unlimited >> crypto in OpenJDK. >> > > Great, thanks! I'll push it. >> Brad >> >> >> >>>> Mark wrote: >>>> > The summary is that it was just easier to remove unused >>>> > classes >>>> > that >>>> > made the code tricky to understand for no good reason except >>>> > for >>>> > some >>>> > secret proprietary code. >>>> >>>> Unfortunately, Oracle and some of our commercial (non-OpenJDK) >>>> licensees >>>> still depend on that tricky code. :( I'd personally love to >>>> strip >>>> it >>>> all out, but we have to balance all of its consumers (Oracle SE >>>> and >>>> ME, >>>> commercial source/binary licensees, OpenJDK, etc.) >>>> >>>> Andrew wrote: >>>> > I'm sure it would be easy enough to dump those classes if >>>> > Oracle >>>> > started producing OpenJDK binaries licensed under the GPL, >>>> > rather >>>> > than binaries from their proprietary fork. >>>> >>>> Unfortunately, not likely in our current export/import climate. >>>> >>> >>> Yes, this is what I thought. We just have to make sure to test >>> well >>> before shipping binaries. >>> >>>> Brad >>>> >>>> >>> >> > From bradford.wetmore at oracle.com Thu Sep 27 18:45:44 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 27 Sep 2012 11:45:44 -0700 Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <1057179810.3034228.1348765091452.JavaMail.root@redhat.com> References: <1057179810.3034228.1348765091452.JavaMail.root@redhat.com> Message-ID: <50649ED8.5030108@oracle.com> It's now marked as resolved. Thanks, Brad On 9/27/2012 9:58 AM, Andrew Hughes wrote: > > > ----- Original Message ----- >> ----- Original Message ----- >>> >>>>> Will you be putting this back yourself? If so let me know when >>>>> you >>>>> go >>>>> in, and I can update the bug once you're in. >>>>> >>>> >>>> I will, though I'll need a bug ID for it. I presume tl is ok as >>>> the >>>> forest to use? >>> >>> This going into 8? Then yes. >>> >> >> At first, yes. Do you have any objections to me proposing it for 7u >> too, in due course? >> >>> 7201205: Add Makefile configuration option to build with unlimited >>> crypto in OpenJDK. >>> >> >> Great, thanks! I'll push it. >> > > All done: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e879c0288c2 > >>> Brad >>> >>> >>> >>>>> Mark wrote: >>>>> > The summary is that it was just easier to remove unused >>>>> > classes >>>>> > that >>>>> > made the code tricky to understand for no good reason except >>>>> > for >>>>> > some >>>>> > secret proprietary code. >>>>> >>>>> Unfortunately, Oracle and some of our commercial (non-OpenJDK) >>>>> licensees >>>>> still depend on that tricky code. :( I'd personally love to >>>>> strip >>>>> it >>>>> all out, but we have to balance all of its consumers (Oracle SE >>>>> and >>>>> ME, >>>>> commercial source/binary licensees, OpenJDK, etc.) >>>>> >>>>> Andrew wrote: >>>>> > I'm sure it would be easy enough to dump those classes if >>>>> > Oracle >>>>> > started producing OpenJDK binaries licensed under the GPL, >>>>> > rather >>>>> > than binaries from their proprietary fork. >>>>> >>>>> Unfortunately, not likely in our current export/import climate. >>>>> >>>> >>>> Yes, this is what I thought. We just have to make sure to test >>>> well >>>> before shipping binaries. >>>> >>>>> Brad >>>>> >>>>> >>>> >>> >> >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> >> > From magnus.ihse.bursie at oracle.com Thu Sep 27 21:25:46 2012 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Sep 2012 23:25:46 +0200 Subject: warnings from configure on solaris sparc In-Reply-To: <506481A5.6060602@oracle.com> References: <506481A5.6060602@oracle.com> Message-ID: Thank you for your bug report. This is a known issue, and will be fixed before build-infra replaces the current build system. /Magnus 27 sep 2012 kl. 18:41 skrev Jim Holmlund : > : > checking for IceConnectionNumber in -lICE... yes > checking X11/extensions/shape.h usability... no > checking X11/extensions/shape.h presence... yes > configure: WARNING: X11/extensions/shape.h: present but cannot be compiled > configure: WARNING: X11/extensions/shape.h: check for missing prerequisite headers? > configure: WARNING: X11/extensions/shape.h: see the Autoconf documentation > configure: WARNING: X11/extensions/shape.h: section "Present But Cannot Be Compiled" > configure: WARNING: X11/extensions/shape.h: proceeding with the compiler's result > configure: WARNING: ## ----------------------------------------- ## > configure: WARNING: ## Report this to build-dev at openjdk.java.net ## > configure: WARNING: ## ----------------------------------------- ## > > > The machine is > SunOS mmm 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-2500 > > - jjh > From gnu.andrew at redhat.com Fri Sep 28 04:09:31 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Sep 2012 00:09:31 -0400 (EDT) Subject: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy In-Reply-To: <50649ED8.5030108@oracle.com> Message-ID: <311531829.3174029.1348805371131.JavaMail.root@redhat.com> ----- Original Message ----- > It's now marked as resolved. > > Thanks, > > Brad > Great. Thanks! Glad to get this finally resolved. I'll let it promote through to 8, then suggest it for 7u. > > On 9/27/2012 9:58 AM, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >> ----- Original Message ----- > >>> > >>>>> Will you be putting this back yourself? If so let me know when > >>>>> you > >>>>> go > >>>>> in, and I can update the bug once you're in. > >>>>> > >>>> > >>>> I will, though I'll need a bug ID for it. I presume tl is ok as > >>>> the > >>>> forest to use? > >>> > >>> This going into 8? Then yes. > >>> > >> > >> At first, yes. Do you have any objections to me proposing it for > >> 7u > >> too, in due course? > >> > >>> 7201205: Add Makefile configuration option to build with > >>> unlimited > >>> crypto in OpenJDK. > >>> > >> > >> Great, thanks! I'll push it. > >> > > > > All done: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e879c0288c2 > > > >>> Brad > >>> > >>> > >>> > >>>>> Mark wrote: > >>>>> > The summary is that it was just easier to remove unused > >>>>> > classes > >>>>> > that > >>>>> > made the code tricky to understand for no good reason > >>>>> > except > >>>>> > for > >>>>> > some > >>>>> > secret proprietary code. > >>>>> > >>>>> Unfortunately, Oracle and some of our commercial (non-OpenJDK) > >>>>> licensees > >>>>> still depend on that tricky code. :( I'd personally love to > >>>>> strip > >>>>> it > >>>>> all out, but we have to balance all of its consumers (Oracle SE > >>>>> and > >>>>> ME, > >>>>> commercial source/binary licensees, OpenJDK, etc.) > >>>>> > >>>>> Andrew wrote: > >>>>> > I'm sure it would be easy enough to dump those classes if > >>>>> > Oracle > >>>>> > started producing OpenJDK binaries licensed under the GPL, > >>>>> > rather > >>>>> > than binaries from their proprietary fork. > >>>>> > >>>>> Unfortunately, not likely in our current export/import climate. > >>>>> > >>>> > >>>> Yes, this is what I thought. We just have to make sure to test > >>>> well > >>>> before shipping binaries. > >>>> > >>>>> Brad > >>>>> > >>>>> > >>>> > >>> > >> > >> -- > >> Andrew :) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07