From nicholas+openjdk at nicholaswilliams.net Sun Dec 1 18:29:17 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Dec 2013 12:29:17 -0600 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> Message-ID: <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: https://bugs.openjdk.java.net/browse/JDK-8016742 https://bugs.openjdk.java.net/browse/JDK-8016743 I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date & Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date & Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team. >:-[ 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date & time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. N On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: > > On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: > >> On 17 June 2013 12:40, Alan Bateman wrote: >>> On 17/06/2013 11:05, Nick Williams wrote: >>>> >>>> Thanks. I have filed two different bugs for these two different problems. >>> >>> Here they are: >>> >>> 8016743: java.text.MessageFormat does not support java.time.* types >>> 8016742: JAXB does not support java.time.* types >>> >>> Note that JAXB is maintained in an upstream project (they periodically do >>> source drops into OpenJDK). I don't know if support for java.time requires >>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>> and I think they the requirement to be able to drop-in into jdk7 builds. >> >> That could be a problem, but its really a process one. It shouldn't be >> users that suffer as a result of issues like that (but there isn't >> anything I can do about it other than wave my hands...) >> Stephen > > ^^ What Stephen said. :-) From xueming.shen at oracle.com Sun Dec 1 18:52:32 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 01 Dec 2013 10:52:32 -0800 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> Message-ID: <529B8570.5020303@oracle.com> On 12/1/13 10:29 AM, Nick Williams wrote: > I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: > > https://bugs.openjdk.java.net/browse/JDK-8016742 > https://bugs.openjdk.java.net/browse/JDK-8016743 > > I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... > > I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date & Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date & Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team. >:-[ java.time has its own formatting/parsing mechanism/support via java.time.format package, in which it does have l10n/i18n support for print/parsing the new java.time date/time types for various locales. Any particular reason you must use j.text.MessageFormat to print/parse the java.time date/time types? -Sherman > > 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. > > Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? > > If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date & time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. > > N > > On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: > >> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >> >>> On 17 June 2013 12:40, Alan Bateman wrote: >>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>> Thanks. I have filed two different bugs for these two different problems. >>>> Here they are: >>>> >>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>> 8016742: JAXB does not support java.time.* types >>>> >>>> Note that JAXB is maintained in an upstream project (they periodically do >>>> source drops into OpenJDK). I don't know if support for java.time requires >>>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>> That could be a problem, but its really a process one. It shouldn't be >>> users that suffer as a result of issues like that (but there isn't >>> anything I can do about it other than wave my hands...) >>> Stephen >> ^^ What Stephen said. :-) From Alan.Bateman at oracle.com Sun Dec 1 21:11:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Dec 2013 21:11:40 +0000 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> Message-ID: <529BA60C.1020802@oracle.com> On 01/12/2013 18:29, Nick Williams wrote: > I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: > > https://bugs.openjdk.java.net/browse/JDK-8016742 > https://bugs.openjdk.java.net/browse/JDK-8016743 > > I filed the bugs, though they say someone else did. "Webbug Group" is just a placeholder for incidents that are submitted via the legacy bugs.sun.com site and forwarded to JDK JIRA. > : > > 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. As I said in June, JAXB is maintained in an upstream project. I believe it is tied to a standalone JSR and that updates are more likely to align with EE updates rather than JDK releases. I assume one of the mailing lists listed on the jaxb.java.net project is the place to follow on this request (Martin or Miroslav can point to the right place if there is somewhere else). -Alan. From nicholas+openjdk at nicholaswilliams.net Sun Dec 1 21:13:04 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Dec 2013 15:13:04 -0600 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <529B8570.5020303@oracle.com> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> Message-ID: <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: > On 12/1/13 10:29 AM, Nick Williams wrote: >> I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: >> >> https://bugs.openjdk.java.net/browse/JDK-8016742 >> https://bugs.openjdk.java.net/browse/JDK-8016743 >> >> I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... >> >> I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date & Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date & Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team. >:-[ > > java.time has its own formatting/parsing mechanism/support via java.time.format package, in which > it does have l10n/i18n support for print/parsing the new java.time date/time types for various locales. > Any particular reason you must use j.text.MessageFormat to print/parse the java.time date/time types? Yes: So that you can use message formats in ResourceBundles with java.time types. For example: [resource bundle file contents] some.message.key=You last logged in on {1,date,long} at {2,time,long}. [/resource bundle file contents] And then, in a JSP (just one example use case): Resource bundle messages _must_ follow the MessageFormat conventions. MessageFormat only supports java.text.DateFormat. DateFormat only supports java.util.Date. MessageSource needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages. Nick > > -Sherman > >> >> 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. >> >> Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? >> >> If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date & time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. >> >> N >> >> On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: >> >>> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >>> >>>> On 17 June 2013 12:40, Alan Bateman wrote: >>>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>>> Thanks. I have filed two different bugs for these two different problems. >>>>> Here they are: >>>>> >>>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>>> 8016742: JAXB does not support java.time.* types >>>>> >>>>> Note that JAXB is maintained in an upstream project (they periodically do >>>>> source drops into OpenJDK). I don't know if support for java.time requires >>>>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>>> That could be a problem, but its really a process one. It shouldn't be >>>> users that suffer as a result of issues like that (but there isn't >>>> anything I can do about it other than wave my hands...) >>>> Stephen >>> ^^ What Stephen said. :-) > From nicholas+openjdk at nicholaswilliams.net Sun Dec 1 21:24:48 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Dec 2013 15:24:48 -0600 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> Message-ID: On Dec 1, 2013, at 3:13 PM, Nick Williams wrote: > > On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: > >> On 12/1/13 10:29 AM, Nick Williams wrote: >>> I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8016742 >>> https://bugs.openjdk.java.net/browse/JDK-8016743 >>> >>> I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... >>> >>> I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date & Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date & Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team. >:-[ >> >> java.time has its own formatting/parsing mechanism/support via java.time.format package, in which >> it does have l10n/i18n support for print/parsing the new java.time date/time types for various locales. >> Any particular reason you must use j.text.MessageFormat to print/parse the java.time date/time types? > > Yes: So that you can use message formats in ResourceBundles with java.time types. For example: > > [resource bundle file contents] > some.message.key=You last logged in on {1,date,long} at {2,time,long}. > [/resource bundle file contents] > > And then, in a JSP (just one example use case): > > > > > > > Resource bundle messages _must_ follow the MessageFormat conventions. MessageFormat only supports java.text.DateFormat. DateFormat only supports java.util.Date. MessageSource needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages. Sorry, I meant to say "MessageFormat needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages...". N > > Nick > >> >> -Sherman >> >>> >>> 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. >>> >>> Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? >>> >>> If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date & time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. >>> >>> N >>> >>> On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: >>> >>>> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >>>> >>>>> On 17 June 2013 12:40, Alan Bateman wrote: >>>>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>>>> Thanks. I have filed two different bugs for these two different problems. >>>>>> Here they are: >>>>>> >>>>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>>>> 8016742: JAXB does not support java.time.* types >>>>>> >>>>>> Note that JAXB is maintained in an upstream project (they periodically do >>>>>> source drops into OpenJDK). I don't know if support for java.time requires >>>>>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>>>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>>>> That could be a problem, but its really a process one. It shouldn't be >>>>> users that suffer as a result of issues like that (but there isn't >>>>> anything I can do about it other than wave my hands...) >>>>> Stephen >>>> ^^ What Stephen said. :-) >> > From Alan.Bateman at oracle.com Sun Dec 1 21:34:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Dec 2013 21:34:53 +0000 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <5298F3CE.6000003@oracle.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> <5298F3CE.6000003@oracle.com> Message-ID: <529BAB7D.8010101@oracle.com> On 29/11/2013 20:06, Ivan Gerasimov wrote: > > I modified the patch in the way you suggest. > http://cr.openjdk.java.net/~igerasim/6968459/1/webrev/ > > The timeOut variable now holds the remaining time. > If the system time had changed back, we start counting from the > beginning. > If it had changed forward, we have no way to catch it and the timeout > gets elapsed earlier. This looks okay to me although one thing that isn't clear to me is whether removeRequest needs to be called on no-timeout or InterruptedNamingException cases (Vinnie or Xuelei might have the background in the code to say for sure). > > >> I see the patch doesn't come with a test. Is there any test >> infrastructure for testing LDAP without require a complete server? >> > I didn't find anything like that, that's why I set 'noreg-hard' label. Okay although I think we should consider (via a different bug of course) putting a simple LDAP server into the test tree so that tests for the LDAP provider can be added in the future. -Alan From joe.darcy at oracle.com Mon Dec 2 07:34:09 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 01 Dec 2013 23:34:09 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <17B18871-F198-433C-920B-1475D11D4753@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> <528D0F80.5010905@oracle.com> <529053DB.2010705@oracle.com> <17B18871-F198-433C-920B-1475D11D4753@oracle.com> Message-ID: <529C37F1.7000109@oracle.com> Hello, I've heard back from my numerical reviewer. Given the signs of the terms, he recommend when two partial sums are combined, the leading word be added in first. I've reflected this change in the revision I'm about to push: http://cr.openjdk.java.net/~darcy/8006572.5 He had some suggestions for further numerical improvements, which I've captured in JDK-8029372 Improve combination of partial sums/averages in streams API https://bugs.openjdk.java.net/browse/JDK-8029372 Thanks, -Joe On 11/25/2013 09:57 AM, Mike Duigou wrote: > Looks good > > Mike > > On Nov 22 2013, at 23:06 , Joe Darcy wrote: > >> Hello Mike and Paul, >> >> Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at >> >> http://cr.openjdk.java.net/~darcy/8006572.4/ >> >> Two numerical aspects of the change are different in this iteration: >> >> * when two running compensated sums and combined, the compensation portion of the second is now added in first. Since it should have smaller magnitude, this is favorable in terms of error analysis >> >> * the final sum returned (or used to compute the average) is (sum + sumCompensation). I checked one of my references, "Accuracy and Stability of Numerical Algorithms" from Nicholas Higham, and that tweak gave a better error bound >> >> The test code has been updated as you've suggested (other than porting to TestNG ;-) and I also added a test case for a bug Paul spotted on an earlier review. >> >> All the streams tests pass with the new code. >> >> Thanks, >> >> -Joe >> >> On 11/20/2013 11:37 AM, Joe Darcy wrote: >>> Hi Mike, >>> >>> On 11/20/2013 10:31 AM, Mike Duigou wrote: >>>> - Collectors averagingDouble could use the same @implNote as in DoublePipeline. >>>> >>>> - DoublePipeline implementation could document the usage of the double array indices. >>>> >>>> - @summary in test. >>> I'll reflect these in the next iteration. >>> >>>> - I agree with Paul that refactoring as a testNG test would be nice. >>> While learning about testNG would be useful, I don't want to take that on right at the moment ;-) >>> >>>> - I wondered at the mechanism for combining compensation values. Do you have a reference which explains the correctness? I thought perhaps directly adding the compensations together before doing compensated addition of the two sums might be better. >>> One of the inquiries I have out to my numerical reviewer is how to best combine two compensations. >>> >>> In the code as written, from the perspective of one compensation, the two doubles in the other other compensation are just two more double values. So I think this is correct, if not ideal. >>> >>> The compensation portion of one running sum could be of vastly different magnitude than the compensation portion (or the high-order sum bits) of the other sum. Therefore, I believe a direct combination of either (sum1 + sum2) or (comp1 + comp2) would lose the numerical properties of interest here. >>> >>> Thanks for the feedback, >>> >>> -Joe >>> >>>> Mike >>>> >>>> >>>> On Nov 20 2013, at 00:21 , Joe Darcy wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> On 11/18/2013 07:38 AM, Paul Sandoz wrote: >>>>>> Hi Joe, >>>>>> >>>>>> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >>>>>> >>>>>> public final OptionalDouble average() { >>>>>> double[] avg = collect(() -> new double[2], >>>>>> (ll, i) -> { >>>>>> ll[0]++; >>>>>> ll[1] += i; >>>>>> }, >>>>>> (ll, rr) -> { >>>>>> ll[0] += rr[0]; >>>>>> ll[1] += rr[1]; >>>>>> }); >>>>>> return avg[0] > 0 >>>>>> ? OptionalDouble.of(avg[1] / avg[0]) >>>>>> : OptionalDouble.empty(); >>>>>> } >>>>>> >>>>>> That would be the most expedient way. >>>>> Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8006572.3/ From joe.darcy at oracle.com Mon Dec 2 07:35:52 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 02 Dec 2013 07:35:52 +0000 Subject: hg: jdk8/tl/jdk: 8006572: DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors Message-ID: <20131202073604.856816296D@hg.openjdk.java.net> Changeset: ca911e383e26 Author: darcy Date: 2013-12-01 23:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca911e383e26 8006572: DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors Reviewed-by: psandoz, mduigou ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java + test/java/util/stream/TestDoubleSumAverage.java From mark.sheppard at oracle.com Mon Dec 2 12:35:14 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 02 Dec 2013 12:35:14 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298CC28.7090506@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298BE89.5090205@oracle.com> <5298C3CB.2060801@oracle.com> <5298CC28.7090506@oracle.com> Message-ID: <529C7E82.4000102@oracle.com> Hi based on feedback the changes for issue: https://bugs.openjdk.java.net/browse/JDK-8025211 have been amended to the following: http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/ please oblige and review regards Mark On 29/11/2013 17:17, Mark Sheppard wrote: > > Alan, Daniel, > thanks for the replies. > > yes, 'tis a possibility, and it appears to work ok as a test, as it > avoids the sender's Thread.sleep creating a race condition, such that > the send doesn't happen prior to the timeout of the client receive. > > The context of the test appears to be creating conditions > such that an ICMP PortUnreachable event is generated, > which caused a close a particular version of windows. > The test is for socket closed scenario, afaik > > tested on the errant test machine with consistent success. > > regards > Mark > > On 29/11/2013 16:41, Daniel Fuchs wrote: >> On 11/29/13 5:19 PM, Alan Bateman wrote: >>> On 29/11/2013 14:21, Mark Sheppard wrote: >>>> Hi >>>> please oblige and review the following changes >>>> >>>> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >>>> which address the issue raised in the bug >>>> https://bugs.openjdk.java.net/browse/JDK-8025211 >>>> >>>> an intermittent failure occurs on some windows test machines. >>>> >>>> this replaces a Thread.sleep(5000) with explicit synchronization >>>> between sender >>>> and receiver via a CountDownLatch >>> (cc'ing net-dev) >>> >>> Would an alternative here be to just get rid of the server thread (do >>> both the send + receive on the main thread)? >> >> Hmm... The message sent by the server is short enough so that it >> should be stored in the client's socket buffer and received later >> by the client, even though the client is not yet blocked waiting >> in clientSock.receive() when the message is sent. >> >> That might work. >> >> Unless multi-threading was relevant to the configuration being >> tested? >> >> >> -- daniel >> >>> >>> -Alan >> > From daniel.fuchs at oracle.com Mon Dec 2 13:30:54 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 02 Dec 2013 14:30:54 +0100 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <529C7E82.4000102@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298BE89.5090205@oracle.com> <5298C3CB.2060801@oracle.com> <5298CC28.7090506@oracle.com> <529C7E82.4000102@oracle.com> Message-ID: <529C8B8E.5040406@oracle.com> Hi Mark, This is much simpler indeed. Thumbs up from me :-) best regards, -- daniel On 12/2/13 1:35 PM, Mark Sheppard wrote: > Hi > based on feedback the changes for issue: > https://bugs.openjdk.java.net/browse/JDK-8025211 > > have been amended to the following: > http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/ > > please oblige and review > > regards > Mark > > On 29/11/2013 17:17, Mark Sheppard wrote: >> >> Alan, Daniel, >> thanks for the replies. >> >> yes, 'tis a possibility, and it appears to work ok as a test, as it >> avoids the sender's Thread.sleep creating a race condition, such that >> the send doesn't happen prior to the timeout of the client receive. >> >> The context of the test appears to be creating conditions >> such that an ICMP PortUnreachable event is generated, >> which caused a close a particular version of windows. >> The test is for socket closed scenario, afaik >> >> tested on the errant test machine with consistent success. >> >> regards >> Mark >> >> On 29/11/2013 16:41, Daniel Fuchs wrote: >>> On 11/29/13 5:19 PM, Alan Bateman wrote: >>>> On 29/11/2013 14:21, Mark Sheppard wrote: >>>>> Hi >>>>> please oblige and review the following changes >>>>> >>>>> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >>>>> which address the issue raised in the bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8025211 >>>>> >>>>> an intermittent failure occurs on some windows test machines. >>>>> >>>>> this replaces a Thread.sleep(5000) with explicit synchronization >>>>> between sender >>>>> and receiver via a CountDownLatch >>>> (cc'ing net-dev) >>>> >>>> Would an alternative here be to just get rid of the server thread (do >>>> both the send + receive on the main thread)? >>> >>> Hmm... The message sent by the server is short enough so that it >>> should be stored in the client's socket buffer and received later >>> by the client, even though the client is not yet blocked waiting >>> in clientSock.receive() when the message is sent. >>> >>> That might work. >>> >>> Unless multi-threading was relevant to the configuration being >>> tested? >>> >>> >>> -- daniel >>> >>>> >>>> -Alan >>> >> > From chris.hegarty at oracle.com Mon Dec 2 13:45:11 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Dec 2013 13:45:11 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <529C7E82.4000102@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298BE89.5090205@oracle.com> <5298C3CB.2060801@oracle.com> <5298CC28.7090506@oracle.com> <529C7E82.4000102@oracle.com> Message-ID: <529C8EE7.2050502@oracle.com> Looks good to me Mark. -Chris. On 02/12/13 12:35, Mark Sheppard wrote: > Hi > based on feedback the changes for issue: > https://bugs.openjdk.java.net/browse/JDK-8025211 > > have been amended to the following: > http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/ > > please oblige and review > > regards > Mark > > On 29/11/2013 17:17, Mark Sheppard wrote: >> >> Alan, Daniel, >> thanks for the replies. >> >> yes, 'tis a possibility, and it appears to work ok as a test, as it >> avoids the sender's Thread.sleep creating a race condition, such that >> the send doesn't happen prior to the timeout of the client receive. >> >> The context of the test appears to be creating conditions >> such that an ICMP PortUnreachable event is generated, >> which caused a close a particular version of windows. >> The test is for socket closed scenario, afaik >> >> tested on the errant test machine with consistent success. >> >> regards >> Mark >> >> On 29/11/2013 16:41, Daniel Fuchs wrote: >>> On 11/29/13 5:19 PM, Alan Bateman wrote: >>>> On 29/11/2013 14:21, Mark Sheppard wrote: >>>>> Hi >>>>> please oblige and review the following changes >>>>> >>>>> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >>>>> which address the issue raised in the bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8025211 >>>>> >>>>> an intermittent failure occurs on some windows test machines. >>>>> >>>>> this replaces a Thread.sleep(5000) with explicit synchronization >>>>> between sender >>>>> and receiver via a CountDownLatch >>>> (cc'ing net-dev) >>>> >>>> Would an alternative here be to just get rid of the server thread (do >>>> both the send + receive on the main thread)? >>> >>> Hmm... The message sent by the server is short enough so that it >>> should be stored in the client's socket buffer and received later >>> by the client, even though the client is not yet blocked waiting >>> in clientSock.receive() when the message is sent. >>> >>> That might work. >>> >>> Unless multi-threading was relevant to the configuration being >>> tested? >>> >>> >>> -- daniel >>> >>>> >>>> -Alan >>> >> > From vincent.x.ryan at oracle.com Mon Dec 2 14:21:07 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 02 Dec 2013 14:21:07 +0000 Subject: hg: jdk8/tl/jdk: 8029369: Shell tests in sun/security/pkcs11/ do not compile PKCS11Test Message-ID: <20131202142122.6EF626297E@hg.openjdk.java.net> Changeset: 4ca1027a130a Author: vinnie Date: 2013-12-02 14:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ca1027a130a 8029369: Shell tests in sun/security/pkcs11/ do not compile PKCS11Test Reviewed-by: mullan ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh From mark.sheppard at oracle.com Mon Dec 2 14:08:05 2013 From: mark.sheppard at oracle.com (mark.sheppard at oracle.com) Date: Mon, 02 Dec 2013 14:08:05 +0000 Subject: hg: jdk8/tl/jdk: 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Message-ID: <20131202140831.CCAB36297C@hg.openjdk.java.net> Changeset: 39b3b0e77af5 Author: msheppar Date: 2013-12-02 14:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b3b0e77af5 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Summary: modified test to execute in a single thread to eliminate potential race condition Reviewed-by: alanb, chegar, dfuchs ! test/java/net/DatagramSocket/PortUnreachable.java From paul.sandoz at oracle.com Mon Dec 2 16:29:04 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Dec 2013 17:29:04 +0100 Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map Message-ID: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com> Hi, http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/ This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap: 1) A problem with concurrent resizes; and 2) The skipping of elements when traversing through bins that are trees of entries. Both of these issues can result in elements "disappearing" from the map, either because an update operation such as put failed, or because a contains operation failed to find the entry in the map. Issue 1) was causing stream tests to fail intermittently on systems with many cores (24 to 32) (furthermore the CHM-based JDK test ToArray was also intermittently failing with less frequency). After some investigation the cause was distilled down to the use of ConcurrentHashMap in the F/J task used by Stream.forEachOrdered. Issue 2) was serendipitously reported on concurrentcy-interest just yesterday :-) Both issues have test cases associated with them that have been tuned to reproduce on systems with low cores i.e. my MacBook! Paul. From mike.duigou at oracle.com Mon Dec 2 17:47:27 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 2 Dec 2013 09:47:27 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <529C37F1.7000109@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> <528D0F80.5010905@oracle.com> <529053DB.2010705@oracle.com> <17B18871-F198-433C-920B-1475D11D4753@oracle.com> <529C37F1.7000109@oracle.com> Message-ID: <9E38563E-0FB8-4559-AD97-76C92DA372A5@oracle.com> On Dec 1 2013, at 23:34 , Joe Darcy wrote: > Hello, > > I've heard back from my numerical reviewer. Given the signs of the terms, he recommend when two partial sums are combined, the leading word be added in first. I've reflected this change in the revision I'm about to push: > > http://cr.openjdk.java.net/~darcy/8006572.5 > > He had some suggestions for further numerical improvements, which I've captured in > > JDK-8029372 Improve combination of partial sums/averages in streams API > https://bugs.openjdk.java.net/browse/JDK-8029372 Any description of what the improvements would be? The bug doesn't currently capture what will be changed/improved. > > Thanks, > > -Joe > > On 11/25/2013 09:57 AM, Mike Duigou wrote: >> Looks good >> >> Mike >> >> On Nov 22 2013, at 23:06 , Joe Darcy wrote: >> >>> Hello Mike and Paul, >>> >>> Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at >>> >>> http://cr.openjdk.java.net/~darcy/8006572.4/ >>> >>> Two numerical aspects of the change are different in this iteration: >>> >>> * when two running compensated sums and combined, the compensation portion of the second is now added in first. Since it should have smaller magnitude, this is favorable in terms of error analysis >>> >>> * the final sum returned (or used to compute the average) is (sum + sumCompensation). I checked one of my references, "Accuracy and Stability of Numerical Algorithms" from Nicholas Higham, and that tweak gave a better error bound >>> >>> The test code has been updated as you've suggested (other than porting to TestNG ;-) and I also added a test case for a bug Paul spotted on an earlier review. >>> >>> All the streams tests pass with the new code. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 11/20/2013 11:37 AM, Joe Darcy wrote: >>>> Hi Mike, >>>> >>>> On 11/20/2013 10:31 AM, Mike Duigou wrote: >>>>> - Collectors averagingDouble could use the same @implNote as in DoublePipeline. >>>>> >>>>> - DoublePipeline implementation could document the usage of the double array indices. >>>>> >>>>> - @summary in test. >>>> I'll reflect these in the next iteration. >>>> >>>>> - I agree with Paul that refactoring as a testNG test would be nice. >>>> While learning about testNG would be useful, I don't want to take that on right at the moment ;-) >>>> >>>>> - I wondered at the mechanism for combining compensation values. Do you have a reference which explains the correctness? I thought perhaps directly adding the compensations together before doing compensated addition of the two sums might be better. >>>> One of the inquiries I have out to my numerical reviewer is how to best combine two compensations. >>>> >>>> In the code as written, from the perspective of one compensation, the two doubles in the other other compensation are just two more double values. So I think this is correct, if not ideal. >>>> >>>> The compensation portion of one running sum could be of vastly different magnitude than the compensation portion (or the high-order sum bits) of the other sum. Therefore, I believe a direct combination of either (sum1 + sum2) or (comp1 + comp2) would lose the numerical properties of interest here. >>>> >>>> Thanks for the feedback, >>>> >>>> -Joe >>>> >>>>> Mike >>>>> >>>>> >>>>> On Nov 20 2013, at 00:21 , Joe Darcy wrote: >>>>> >>>>>> Hi Paul, >>>>>> >>>>>> On 11/18/2013 07:38 AM, Paul Sandoz wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >>>>>>> >>>>>>> public final OptionalDouble average() { >>>>>>> double[] avg = collect(() -> new double[2], >>>>>>> (ll, i) -> { >>>>>>> ll[0]++; >>>>>>> ll[1] += i; >>>>>>> }, >>>>>>> (ll, rr) -> { >>>>>>> ll[0] += rr[0]; >>>>>>> ll[1] += rr[1]; >>>>>>> }); >>>>>>> return avg[0] > 0 >>>>>>> ? OptionalDouble.of(avg[1] / avg[0]) >>>>>>> : OptionalDouble.empty(); >>>>>>> } >>>>>>> >>>>>>> That would be the most expedient way. >>>>>> Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/8006572.3/ > From naoto.sato at oracle.com Mon Dec 2 19:30:27 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 02 Dec 2013 19:30:27 +0000 Subject: hg: jdk8/tl/jdk: 8028368: There is no description whether or not java.util.ResourceBundle is thread-safe Message-ID: <20131202193045.2E76962992@hg.openjdk.java.net> Changeset: 5b5ee2288306 Author: naoto Date: 2013-12-02 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b5ee2288306 8028368: There is no description whether or not java.util.ResourceBundle is thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/ResourceBundle.java From lance.andersen at oracle.com Mon Dec 2 19:33:58 2013 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 2 Dec 2013 14:33:58 -0500 Subject: Review request 8029417: Minor javadoc cleanup for JDBC 4.2 Message-ID: <6BBF8990-3E01-49B0-A323-F5611D5BDFB4@oracle.com> Hi all This is a review request for some minor javadoc clarifications for JDBC 4.2 based on some feedback that I received. The webrev can be found http://cr.openjdk.java.net/~lancea/8029417/webrev.00 Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Mon Dec 2 19:25:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 02 Dec 2013 11:25:08 -0800 Subject: RFR JDK-8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf) In-Reply-To: <528539CF.1010200@oracle.com> References: <528539CF.1010200@oracle.com> Message-ID: <529CDE94.1070605@oracle.com> Hi, Based on the feedback so far here is the latest webrev, and the link to the bug. http://cr.openjdk.java.net/~sherman/8028397/webrev https://bugs.openjdk.java.net/browse/JDK-8028397 During the discussion it became clearthat methods decode/encode(ByteBuffer, ByteBuffer) are insufficient to support the continuous de/encoding operation request ("underflow" handling, in charset coder's term). Given the assumed usage for these methods is for de/encoding the bytes from io channels, I have been convinced it might be more useful/desired to provide a pair of wrap methods instead for readable/writableByteChannel, same as the pair we have now for in/output stream (the wrap methods are under development, but will probably be for future releases). For jdk8 the proposal is to remove the pair of de/encode(Buffer, ByteBuffer), as showed in the webrev. Thanks! -Sherman On 11/14/2013 12:59 PM, Xueming Shen wrote: > Hi, > > The consensus/conclusion from the discussion [1] regarding the changes we > made earlier for JDK-8025003 [2] is to back out the existing "half-lenient" change > to leave the door open for a clean "lenient" support for future releases. > > Here is the webrev for the undo (keep the mime encoder(...) rename change) > > http://cr.openjdk.java.net/~sherman/8028397/webrev > > Thanks! > -Sherman > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023048.html > [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e7bdb2fcc7bc > > > From xueming.shen at oracle.com Mon Dec 2 19:47:48 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 02 Dec 2013 11:47:48 -0800 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> Message-ID: <529CE3E4.2040508@oracle.com> On 12/01/2013 01:13 PM, Nick Williams wrote: > On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: > >> On 12/1/13 10:29 AM, Nick Williams wrote: >>> I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8016742 >>> https://bugs.openjdk.java.net/browse/JDK-8016743 >>> >>> I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... >>> >>> I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date& Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date& Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team.>:-[ >> java.time has its own formatting/parsing mechanism/support via java.time.format package, in which >> it does have l10n/i18n support for print/parsing the new java.time date/time types for various locales. >> Any particular reason you must use j.text.MessageFormat to print/parse the java.time date/time types? > Yes: So that you can use message formats in ResourceBundles with java.time types. For example: The idea here is to encourage the use of java.time.format for java.time date/time types, not the Message/DateFormat for the new JSR310 date/time. You should be able to use DateTimeFormatterBuilder + ResourceBundles to obtain a DateTimeFormatter for particular locale with customized localized message, for your JSR310 data/time. Yes, I guess the tag should support the java.time.format.DTF, if the argument is a JSR310 date/time types. That said, it might be desired to add the support of the JSR310 date/time for the DateFormat, but it will not make jdk8. -Sherman > [resource bundle file contents] > some.message.key=You last logged in on {1,date,long} at {2,time,long}. > [/resource bundle file contents] > > And then, in a JSP (just one example use case): > > > > > > > Resource bundle messages _must_ follow the MessageFormat conventions. MessageFormat only supports java.text.DateFormat. DateFormat only supports java.util.Date. MessageSource needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages. > > Nick > >> -Sherman >> >>> 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. >>> >>> Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? >>> >>> If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date& time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. >>> >>> N >>> >>> On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: >>> >>>> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >>>> >>>>> On 17 June 2013 12:40, Alan Bateman wrote: >>>>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>>>> Thanks. I have filed two different bugs for these two different problems. >>>>>> Here they are: >>>>>> >>>>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>>>> 8016742: JAXB does not support java.time.* types >>>>>> >>>>>> Note that JAXB is maintained in an upstream project (they periodically do >>>>>> source drops into OpenJDK). I don't know if support for java.time requires >>>>>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>>>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>>>> That could be a problem, but its really a process one. It shouldn't be >>>>> users that suffer as a result of issues like that (but there isn't >>>>> anything I can do about it other than wave my hands...) >>>>> Stephen >>>> ^^ What Stephen said. :-) From srikalyan.chandrashekar at oracle.com Mon Dec 2 19:21:51 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Mon, 02 Dec 2013 11:21:51 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528D716C.3030502@oracle.com> References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> <528D12F4.2070300@oracle.com> <528D716C.3030502@oracle.com> Message-ID: <529CDDCF.6070807@oracle.com> Hi David, Thanks for the review, the new webrev is hosted at http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ . Please see inline text. On 11/20/13, 6:35 PM, David Holmes wrote: > On 21/11/2013 10:28 AM, Martin Buchholz wrote: >> I again tried and failed to reproduce a failure. Even if I go whole hog >> and multiply TIMEOUT by 100 and divide ITERS by 100, the test >> continues to >> PASS. Is it just me?! > > I think you are going the wrong way Martin - you want the timeout to > be smaller than the time it takes to execute ITERS. > >> I don't think there's any reason to make result long. It's not even >> used >> except to inhibit hotspot optimizations. >> >> + private volatile long result = 17;//Can get int overflow,so >> using long > > Further the subsequent use of += is incorrect as it is not an atomic > operation. Even if we don't care about the value, it looks bad. Made the necessary changes for atomic update. > > I'm not sure result must be updated if we get a BrokenBarrierException > either. Probably harmless, but necessary? I retained it in the fix for completeness in updating the numbers, please let me know if you still think otherwise. > >> need to fix spelling and spacing below. >> >> + barrier.await();//If a BrokeBarrierException happens >> here(due to > > There are a number of style issues with spacing around comments. Fixed the spelling error and styling issues. > > And I don't think this change is sufficient to claim co-author status > with Doug either ;-) Removed the claim :) > > The additional tracing may be useful but seems stylistically different > from the rest of the code. Retained the tracking to understand if it is again the timing issue which is the cause in an event of a failure, however i can remove it if you think it is not necessary (OR) include an alternate solution as you may want to suggest. > > Overall I'm suspicious that the changed timeout actually fixes > anything - normally we need to add longer timeouts not shorter ones. > Does this fail on a range of machines or only specific ones? Have we > verified that the clocks/timers are behaving properly on those systems? Here the time out is not about waiting for threads to complete something but to "be interrupted" before being considered done, so we decreased the timeout. However we now chose to increase the number of iterations to 5000000 from 1000000(thanks to tristan for the suggestion) instead of decreasing the timeout as done earlier because the increasing iterations ensures the threads are busy for long time curtailing the need to touch the timeout. > > Thanks, > David -- Thanks kalyan Ph: (408)-585-8040 > >> >> >> >> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan < >> srikalyan.chandrashekar at oracle.com> wrote: >> >>> Hi Martin , apologies for the delay , was trying to get help for >>> hosting >>> my webrev. . Please see inline text. >>> >>> >>> On 11/19/13, 10:35 PM, Martin Buchholz wrote: >>> >>> Hi Kalyan, >>> >>> None of us can review your changes yet because you haven't given us a >>> URL of your webrev. >>> >>> It is located here >>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ >>> >>> >>> >>> I've tried to make the jsr166 copy of CancelledLockLoops fail by >>> adjusting ITERS and TIMEOUT radically up and down, but the test just >>> keeps >>> on passing for me. Hints appreciated. >>> >>> Bump up the timeout to 500ms and you will see a failure (i can see it >>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8 >>> latest any promoted build). >>> >>> >>> >>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < >>> srikalyan.chandrashekar at oracle.com> wrote: >>> >>>> Suggested Fix: >>>>> a) Decrease the timeout from 100 to 50ms which will ensure that >>>>> the test >>>>> will pass even on faster machines >>>>> >>>> >>> This doesn't look like a permanent fix - it just makes the failing >>> case >>> rarer. >>> >>> Thats true , the other way is to make the main thread wait on TIMEOUT >>> after firing the interrupts instead of other way round, but that >>> would be >>> over-optimization which probably is not desirable as well. The 50 >>> ms was >>> arrived at empirically after running several 100 times on multiple >>> configurations and did not cause failures. >>> >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> >>> From nicholas+openjdk at nicholaswilliams.net Mon Dec 2 20:29:18 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Mon, 2 Dec 2013 14:29:18 -0600 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <529CE3E4.2040508@oracle.com> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> <529CE3E4.2040508@oracle.com> Message-ID: <5C54B08A-CA4D-4446-9AEC-CB68AE2CBA7B@nicholaswilliams.net> On Dec 2, 2013, at 1:47 PM, Xueming Shen wrote: > On 12/01/2013 01:13 PM, Nick Williams wrote: >> On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote: >> >>> On 12/1/13 10:29 AM, Nick Williams wrote: >>>> I filed these bugs back in June. I noticed today that they were migrated to the JIRA instance: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8016742 >>>> https://bugs.openjdk.java.net/browse/JDK-8016743 >>>> >>>> I filed the bugs, though they say someone else did. It's frustrating that suddenly I can't even comment on bugs I created, but that's beside the point of this email... >>>> >>>> I'm dismayed to see that 8016743 has been scheduled for being fixed in JAVA 9! What the heck!? If I can't use the new Java 8 Date& Time types in Java's localization support, then what good are they!? I have to just stick with java.util.Date for yet another two years because I can't localize Java 8 Date& Time types in my i18n message formats. That's not the quality that I normally expect out of the Java team.>:-[ >>> java.time has its own formatting/parsing mechanism/support via java.time.format package, in which >>> it does have l10n/i18n support for print/parsing the new java.time date/time types for various locales. >>> Any particular reason you must use j.text.MessageFormat to print/parse the java.time date/time types? >> Yes: So that you can use message formats in ResourceBundles with java.time types. For example: > > The idea here is to encourage the use of java.time.format for java.time date/time > types, not the Message/DateFormat for the new JSR310 date/time. You should be > able to use DateTimeFormatterBuilder + ResourceBundles to obtain a DateTimeFormatter > for particular locale with customized localized message, for your JSR310 data/time. Nope. MessageFormat is a universal i18n formatting class for messages that contain number, currency, percentage, date, and time parameters. If I have a message like this: You last logged in on {0,date,long} at {0,time,long}. You have logged in {1,number} times. I should be able to pass this message to a single method/class, supply parameters/arguments, and have the message formatted correctly. With MessageFormat, I can. The problem is that Java 8 now offers more date and time types, and MessageFormat was not updated to support those new types. That would be like adding a new primitive to Java (let's call it "extralong") and not updating MessageFormat to support that primitive. I shouldn't have to parse the message myself, pull out the date and time parameters, pass those to a java.time.format.DateTimeFormatter to format those parameters, replace them in the message, then pass the rest of the message to the MessageFormat to handle other parameters. > Yes, I guess the tag should support the java.time.format.DTF, if > the argument is a JSR310 date/time types. This isn't just about that tag. That tag doesn't support OR not support java.text.DateFormat or java.time.format.DTF. It supports MessageFormats. That's it. MessageFormat is part of the SE's core i18n support. If java.time can't work with MessageFormats, it's going to be a problem. The solution is for MessageFormat to support java.time.DTF. > That said, it might be desired to add the support of the JSR310 date/time > for the DateFormat, but it will not make jdk8. > > -Sherman > >> [resource bundle file contents] >> some.message.key=You last logged in on {1,date,long} at {2,time,long}. >> [/resource bundle file contents] >> >> And then, in a JSP (just one example use case): >> >> >> >> >> >> >> Resource bundle messages _must_ follow the MessageFormat conventions. MessageFormat only supports java.text.DateFormat. DateFormat only supports java.util.Date. MessageSource needs to also support java.time.format.DateTimeFormatter, otherwise you can't use java.time types with resource bundle messages. >> >> Nick >> >>> -Sherman >>> >>>> 8016742 is a slightly different story. It's higher priority than 8016743, and although there is absolutely no update about it, it appears that MAYBE it's scheduled for being fixed in Java 8? I have no idea what "tbd_major" means. Note that a fix for 8016743 could potentially help fix 8016742. >>>> >>>> Is there anyone here that can shed some light on 8016742's status and why the heck 8016743 isn't getting fixed until Java 9? >>>> >>>> If not, can someone point me to a more appropriate list that I can escalate my frustrations on? These awesome new date& time types are useless if they aren't supported in Java's i18n/L10n and JAXB components. >>>> >>>> N >>>> >>>> On Jun 17, 2013, at 8:17 AM, Nick Williams wrote: >>>> >>>>> On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote: >>>>> >>>>>> On 17 June 2013 12:40, Alan Bateman wrote: >>>>>>> On 17/06/2013 11:05, Nick Williams wrote: >>>>>>>> Thanks. I have filed two different bugs for these two different problems. >>>>>>> Here they are: >>>>>>> >>>>>>> 8016743: java.text.MessageFormat does not support java.time.* types >>>>>>> 8016742: JAXB does not support java.time.* types >>>>>>> >>>>>>> Note that JAXB is maintained in an upstream project (they periodically do >>>>>>> source drops into OpenJDK). I don't know if support for java.time requires >>>>>>> API changes or not but just to mention that JAXB is tied to a standalone JSR >>>>>>> and I think they the requirement to be able to drop-in into jdk7 builds. >>>>>> That could be a problem, but its really a process one. It shouldn't be >>>>>> users that suffer as a result of issues like that (but there isn't >>>>>> anything I can do about it other than wave my hands...) >>>>>> Stephen >>>>> ^^ What Stephen said. :-) > From mike.duigou at oracle.com Mon Dec 2 20:29:30 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 2 Dec 2013 12:29:30 -0800 Subject: RFR 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task In-Reply-To: <2DDDB8DD-1794-4166-8603-3921CB070C79@oracle.com> References: <2DDDB8DD-1794-4166-8603-3921CB070C79@oracle.com> Message-ID: <758E7658-AE37-4051-819C-A8FB122FCC40@oracle.com> Looks fine to me. Mike On Nov 27 2013, at 03:02 , Paul Sandoz wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8029164 > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/ > > This fixes an issue with CompletableFuture.thenCompose. > > If the composing future is already completed before the call to thenCompose (or completes during some part of the call to thenCompose) and the composing function returns a future that is not yet completed then there is race to set the result, usually won by thenCompose which incorrectly sets the result to null, due to an errant conditional statement. > > Doug has reviewed and committed the fix to the 166 repo and we have double checked there are no similar errors lurking in other areas of CompletableFuture code. > > Paul. From scolebourne at joda.org Mon Dec 2 20:46:12 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 2 Dec 2013 20:46:12 +0000 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: <529CE3E4.2040508@oracle.com> References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> <529CE3E4.2040508@oracle.com> Message-ID: On 2 December 2013 19:47, Xueming Shen wrote: > That said, it might be desired to add the support of the JSR310 date/time > for the DateFormat, but it will not make jdk8. FWIW, I think this should have been fixed in jdk 8. https://bugs.openjdk.java.net/browse/JDK-8016743 Does the spec allow it to be fixed in a jdk 8 update release? Stephen From brian.burkhalter at oracle.com Mon Dec 2 20:54:34 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 2 Dec 2013 12:54:34 -0800 Subject: JDK 8 RFR 8022181: Tune algorithm crossover thresholds in BigInteger Message-ID: Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8022181 Webrev: http://cr.openjdk.java.net/~bpb/8022181/webrev/ Based on numerous micro-benchmark test runs on various operating systems and architectures I would like to propose changing the BigInteger algorithm crossover thresholds as indicated in the webrev from which I excerpt here for convenience: - private static final int KARATSUBA_THRESHOLD = 50; + private static final int KARATSUBA_THRESHOLD = 80; - private static final int TOOM_COOK_THRESHOLD = 75; + private static final int TOOM_COOK_THRESHOLD = 240; - private static final int KARATSUBA_SQUARE_THRESHOLD = 90; + private static final int KARATSUBA_SQUARE_THRESHOLD = 128; - private static final int TOOM_COOK_SQUARE_THRESHOLD = 140; + private static final int TOOM_COOK_SQUARE_THRESHOLD = 216; - static final int BURNIKEL_ZIEGLER_THRESHOLD = 50; + static final int BURNIKEL_ZIEGLER_THRESHOLD = 80; - private static final int SCHOENHAGE_BASE_CONVERSION_THRESHOLD = 8; + private static final int SCHOENHAGE_BASE_CONVERSION_THRESHOLD = 20; Each threshold is approximately the smallest value for which no statistically significant performance regression was observed with respect to the baseline. For the Toom-Cook algorithms, the baselines are the respective Karatsuba algorithms; for the other algorithms, the baselines are the respective algorithms previously implemented in BigInteger. Also, these new suggested thresholds were benchmarked against a performance baseline defined by the previous values of the respective thresholds. With respect to the potential objection that the proposed thresholds are too high, please note that the values are subject to further refinement in the future. This issue https://bugs.openjdk.java.net/browse/JDK-8029425 has been filed as a reminder to continue to refine these values in the JDK 9 time frame although such fine tuning could as well occur in JDK 8 updates. Thanks, Brian From joe.darcy at oracle.com Mon Dec 2 21:02:46 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 02 Dec 2013 13:02:46 -0800 Subject: Review request 8029417: Minor javadoc cleanup for JDBC 4.2 In-Reply-To: <6BBF8990-3E01-49B0-A323-F5611D5BDFB4@oracle.com> References: <6BBF8990-3E01-49B0-A323-F5611D5BDFB4@oracle.com> Message-ID: <529CF576.8010705@oracle.com> Hi Lance, Looks fine; cheers, -Joe On 12/02/2013 11:33 AM, Lance Andersen - Oracle wrote: > Hi all > > This is a review request for some minor javadoc clarifications for JDBC 4.2 based on some feedback that I received. > > The webrev can be found http://cr.openjdk.java.net/~lancea/8029417/webrev.00 > > Best > Lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Alan.Bateman at oracle.com Mon Dec 2 21:03:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Dec 2013 21:03:25 +0000 Subject: RFR JDK-8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf) In-Reply-To: <529CDE94.1070605@oracle.com> References: <528539CF.1010200@oracle.com> <529CDE94.1070605@oracle.com> Message-ID: <529CF59D.8000509@oracle.com> On 02/12/2013 19:25, Xueming Shen wrote: > Hi, > > Based on the feedback so far here is the latest webrev, and the link > to the bug. > > http://cr.openjdk.java.net/~sherman/8028397/webrev > https://bugs.openjdk.java.net/browse/JDK-8028397 > > During the discussion it became clearthat methods > decode/encode(ByteBuffer, > ByteBuffer) are insufficient to support the continuous de/encoding > operation request ("underflow" handling, in charset coder's term). > Given the assumed usage for these methods is for de/encoding the bytes > from io channels, I have been convinced it might be more useful/desired > to provide a pair of wrap methods instead for > readable/writableByteChannel, > same as the pair we have now for in/output stream (the wrap methods > are under development, but will probably be for future releases). For > jdk8 the proposal is to remove the pair of de/encode(Buffer, ByteBuffer), > as showed in the webrev. > I think this is the right thing to do and the changes in the webrev look okay to me (and easy to review as it's just an undo of a recent change plus the removal of two methods). -Alan. From lance.andersen at oracle.com Mon Dec 2 21:06:22 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 02 Dec 2013 21:06:22 +0000 Subject: hg: jdk8/tl/jdk: 8029417: JDBC 4.2 javadoc updates Message-ID: <20131202210634.7D73162996@hg.openjdk.java.net> Changeset: bcf5fa5e9509 Author: lancea Date: 2013-12-02 16:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcf5fa5e9509 8029417: JDBC 4.2 javadoc updates Reviewed-by: darcy ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLPermission.java From joe.darcy at oracle.com Mon Dec 2 21:09:57 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 02 Dec 2013 13:09:57 -0800 Subject: JDK 8 RFR 8022181: Tune algorithm crossover thresholds in BigInteger In-Reply-To: References: Message-ID: <529CF725.5060603@oracle.com> Hi Brian, The new thresholds look reasonable, as is planned follow-up tuning in JDK 9. Thanks, -Joe On 12/2/2013 12:54 PM, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8022181 > Webrev: http://cr.openjdk.java.net/~bpb/8022181/webrev/ > > Based on numerous micro-benchmark test runs on various operating systems and architectures I would like to propose changing the BigInteger algorithm crossover thresholds as indicated in the webrev from which I excerpt here for convenience: > > - private static final int KARATSUBA_THRESHOLD = 50; > + private static final int KARATSUBA_THRESHOLD = 80; > > - private static final int TOOM_COOK_THRESHOLD = 75; > + private static final int TOOM_COOK_THRESHOLD = 240; > > - private static final int KARATSUBA_SQUARE_THRESHOLD = 90; > + private static final int KARATSUBA_SQUARE_THRESHOLD = 128; > > - private static final int TOOM_COOK_SQUARE_THRESHOLD = 140; > + private static final int TOOM_COOK_SQUARE_THRESHOLD = 216; > > - static final int BURNIKEL_ZIEGLER_THRESHOLD = 50; > + static final int BURNIKEL_ZIEGLER_THRESHOLD = 80; > > - private static final int SCHOENHAGE_BASE_CONVERSION_THRESHOLD = 8; > + private static final int SCHOENHAGE_BASE_CONVERSION_THRESHOLD = 20; > > Each threshold is approximately the smallest value for which no statistically significant performance regression was observed with respect to the baseline. For the Toom-Cook algorithms, the baselines are the respective Karatsuba algorithms; for the other algorithms, the baselines are the respective algorithms previously implemented in BigInteger. Also, these new suggested thresholds were benchmarked against a performance baseline defined by the previous values of the respective thresholds. > > With respect to the potential objection that the proposed thresholds are too high, please note that the values are subject to further refinement in the future. This issue https://bugs.openjdk.java.net/browse/JDK-8029425 has been filed as a reminder to continue to refine these values in the JDK 9 time frame although such fine tuning could as well occur in JDK 8 updates. > > Thanks, > > Brian From xueming.shen at oracle.com Mon Dec 2 21:11:55 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 02 Dec 2013 13:11:55 -0800 Subject: There needs to be support for java.time in java.text.MessageFormat In-Reply-To: References: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net> <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net> <51BEF5C6.9080304@oracle.com> <277D1843-89F8-4EFB-8059-DEEE9EB59FAA@nicholaswilliams.net> <529B8570.5020303@oracle.com> <229A148E-FEA9-4759-95C8-A1C809DB0BD8@nicholaswilliams.net> <529CE3E4.2040508@oracle.com> Message-ID: <529CF79B.6020808@oracle.com> On 12/02/2013 12:46 PM, Stephen Colebourne wrote: > On 2 December 2013 19:47, Xueming Shen wrote: >> That said, it might be desired to add the support of the JSR310 date/time >> for the DateFormat, but it will not make jdk8. > FWIW, I think this should have been fixed in jdk 8. > https://bugs.openjdk.java.net/browse/JDK-8016743 > > Does the spec allow it to be fixed in a jdk 8 update release? DateFormat.format(Object obj, ...) has the "obj" specified as "must be a Number or a Date". So it's going to be a spec change. Though it probably is not going to break any existing code except the tck. -Sherman > Stephen From sebastian.sickelmann at gmx.de Mon Dec 2 21:42:44 2013 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 02 Dec 2013 22:42:44 +0100 Subject: RFR: MethodHandles.Lookup. Wrong access verification Message-ID: <529CFED4.7040008@gmx.de> Hi, some days ago i had written[0] that i maybe found a bug in access verification in MethodHandles.Lookup. Now i produces webrev's for the two repos jdk and hotspot. In the jdk webrev [1] I implemented some additional tests. In the hotspot webrev [2] I tried to fix the wrong behavior. I am not sure if it is the right place to fix this. It is more an proof-of-concept--like--reverse-engineering*//* -fix that fixes the symptom, and i do not fully understand all the things in the patched source. In fact i think that we can move line 187 to 182 instead of chaning line 245 in methodHandles.cpp. But as i said i do not fully understand init_method_MemberName and all those CallInfo::vtable_call / CallInfo::itable_call / CallInfo::direct_call differences. Hope my works helps solving this issue. And i hope it is an issue. And i hope my fix isn't breaking anything else so that it was enough to test my fix against my new testcase in MethodHandlesTest.testFindPrivate Kind regards Sebastian [0] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010228.html [1] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_jdk/index.html [2] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_hotspot/index.html From mandy.chung at oracle.com Mon Dec 2 21:45:13 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 02 Dec 2013 13:45:13 -0800 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <5295DFBB.1070008@oracle.com> References: <529535C7.8090403@oracle.com> <5295DFBB.1070008@oracle.com> Message-ID: <529CFF69.1050709@oracle.com> On 11/27/13 4:04 AM, Alan Bateman wrote: > On 26/11/2013 23:59, Mandy Chung wrote: >> This is a simple patch that adds a new jdeps -jdkinternals option to >> make it easier for developers to find dependencies on the JDK >> internal APIs: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ > This looks good (and I can't think of a better name for the option). > Do you think this needs a test as otherwise this option will not be > exercised? Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.01/ I added the new test cases. This also updates -v to include the from class in the output and the verbose mode prints more information. Mandy From mandy.chung at oracle.com Mon Dec 2 21:49:50 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 02 Dec 2013 13:49:50 -0800 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <5295DFBB.1070008@oracle.com> References: <529535C7.8090403@oracle.com> <5295DFBB.1070008@oracle.com> Message-ID: <529D007E.80801@oracle.com> On 11/27/13 4:04 AM, Alan Bateman wrote: > On 26/11/2013 23:59, Mandy Chung wrote: >> This is a simple patch that adds a new jdeps -jdkinternals option to >> make it easier for developers to find dependencies on the JDK >> internal APIs: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ > This looks good (and I can't think of a better name for the option). > Do you think this needs a test as otherwise this option will not be > exercised? Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.01/ I added the new test cases. This also updates -v to include the from class in the o and the verbose mode prints more information. Mandy From john.r.rose at oracle.com Tue Dec 3 00:08:32 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 2 Dec 2013 16:08:32 -0800 Subject: RFR: MethodHandles.Lookup. Wrong access verification In-Reply-To: <529CFED4.7040008@gmx.de> References: <529CFED4.7040008@gmx.de> Message-ID: I appreciate the report and the proposed fixes. We are looking at this seriously. ? John P.S. The root issue may be an accidental inheritance of private methods. I have been thinking for a while that, in the name of compatibility, the JVMS allows an "invokevirtual" invocation to reach a private method, but that this is unfortunate, since "invokespecial" already supplies a more specific way to get to the method. Likewise, an "invokeinterface" instruction can reach a virtual method of Object, while "invokevirtual" gives a more specific way. There are a number of odd pathways through the linkResolver, to support these extra combinations, that I would like to regularize or remove. I think we should investigate tightening up the JVM linkage rules to avoid the extra corner cases. That will probably have the effect of removing surprise effects like this one, as we continue to extend the JVM linkage rules. On Dec 2, 2013, at 1:42 PM, Sebastian Sickelmann wrote: > Hi, > > some days ago i had written[0] that i maybe found a bug in access verification in MethodHandles.Lookup. > > Now i produces webrev's for the two repos jdk and hotspot. > > In the jdk webrev [1] I implemented some additional tests. > > In the hotspot webrev [2] I tried to fix the wrong behavior. I am not sure if it is the right place to fix this. > It is more an proof-of-concept--like--reverse-engineering-fix that fixes the symptom, and i do not fully > understand all the things in the patched source. In fact i think that we can move line 187 to 182 instead > of chaning line 245 in methodHandles.cpp. But as i said i do not fully understand init_method_MemberName > and all those CallInfo::vtable_call / CallInfo::itable_call / CallInfo::direct_call differences. > > Hope my works helps solving this issue. And i hope it is an issue. And i hope my fix isn't breaking anything else > so that it was enough to test my fix against my new testcase in MethodHandlesTest.testFindPrivate > > Kind regards > Sebastian > > [0] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010228.html > [1] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_jdk/index.html > [2] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_hotspot/index.html From mandy.chung at oracle.com Tue Dec 3 00:49:32 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 02 Dec 2013 16:49:32 -0800 Subject: 8029281: Synchronization issues in Logger and LogManager In-Reply-To: <52987D5D.6070800@oracle.com> References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com> <529752AB.2050101@oracle.com> <52987D5D.6070800@oracle.com> Message-ID: <529D2A9C.2020001@oracle.com> On 11/29/2013 3:41 AM, Daniel Fuchs wrote: > Hi, > > Here is a new revision that includes Peter's findings. > Thanks again for that Peter! > > > LogManager.java L156: make props volatile is good. I think the reason why LoggerWeakRef.node and parentRef don't need to be volatile because of the synchronized block to check and set disposed flag that ensures that only one thread will be doing the node and parentRef cleanup. I agree that the two lines should be done with synchronized on the LoggerContext. node.context.removeLogger(name); node.loggerRef = null; // clear LogNode's weak ref to us I don't see anything obvious wrong with this patch. Have you considered having the dispose() method simply synchronizes on node.context (probably need to get the LoggerContext when instantiating LoggerWeakRef and break dispose method into two - one for the node and the other for the parentRef)? I'm not proposing to do this in JDK 8 since we are ramping down and get a low risk fix in. It may be something to revisit for jdk 9 to a cleaner version. Logger.java The assert this.loggerBundle == NO_RESOURCE_BUNDLE; in the Logger constructors doesn't seem to be needed. Having an immutable LoggerBundle class is good to ensure the resourceBundleName and resourceBundle are consistent. L1930: is lb.userBundle and lb.resourceBundleName null when getting to this line? Might be better to rename setupResourceInfo to setResourceBundleName (that creates a LoggerBundle with a null RB). On the other hand, setResourceBundle will instantiate a LoggerBundle with non-null rbname and RB. It wasn't obvious to me what does what. 2137 final String rbName = getResourceBundleName(); 2138 if (!SYSTEM_LOGGER_RB_NAME.equals(rbName) 2139 && !SYSTEM_LOGGER_RB_NAME.equals(b.getBaseBundleName())) { 2140 return LoggerBundle.get(rbName, b); 2141 } else { 2142 return SYSTEM_BUNDLE; 2143 } To get to the above line, either lb.userBundle is null or getResourceBundle() isoverridden. L2126 already checks that this logger does not associate with the system rbname. It seems to me that the special case here is when the Logger subclass overrides getResourceBundleName() to returnSYSTEM_LOGGER_RB_NAME or override getResourceBundle to return the "sun.util.logging.resources.logging" RB. I tink that we might just simplify the above and just return LoggerBundle.get(rbName, b) and no need to worry about those overridden case which does no use to such a Logger subclass with unmatched rbname and RB. Same comment applied to L2157-2165. thanks Mandy From stuart.marks at oracle.com Tue Dec 3 01:11:18 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 02 Dec 2013 17:11:18 -0800 Subject: =?UTF-8?B?562U5aSNOiBSRlIgZm9yIEpESy03MTkwMTA2IFJNSSBiZW5jaG0=?= =?UTF-8?B?YXJrIGZhaWxzIGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGU=?= =?UTF-8?B?ZCBwb3J0?= In-Reply-To: <52942DBE.5050801@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> <528D2E57.1070001@oracle.com> <52940923.8000903@oracle.com> <52942DBE.5050801@oracle.com> Message-ID: <529D2FB6.9000705@oracle.com> Hi Tristan, Sorry (again^2) for the delay. Holiday weekend here in the U.S. The latest webrev looks fine. Did you need a sponsor for this? I can push it for you. I guess we also need an official Reviewer before I can push it. (One additional point for the future. If there is more than one round of review, it's useful to post the new webrev alongside the old one, instead of overwriting it, so that old links are still valid. It's not likely to happen in this case, but if someone were to read the email archives and follow the link to an earlier webrev, they'd have no idea what I was talking about.) s'marks On 11/25/13 9:12 PM, Tristan Yan wrote: > Hi Stuart > Thanks for your code review. I updated the webrev according your suggestion. > Could you review it again? > > http://cr.openjdk.java.net/~ewang/tristan/JDK-7190106/webrev.00/ > Tristan > > On 11/26/2013 10:36 AM, Stuart Marks wrote: >> Hi Tristan, >> >> Finally getting back to this. Again, sorry for the delay. >> >> The changes look much better now. I've listed a bunch of items below, but >> they're all comparatively minor, even nitpicky. But there are a few things >> that should be cleaned up before we integrate this. >> >> Items listed below. >> >> >> ** bench/serial/Main.java >> >> >> - The description should simply be "The Serialization benchmark test". This >> test has nothing to do with RMI, even though it's under the java/rmi hierarchy >> in the filesystem. >> >> - parseArgs() uses strings-in-switch! Good, but put "break" on its own line >> instead of following the close-brace of the catch clause. (rmi/Main.java >> doesn't have this issue.) >> >> >> ** bench/rmi/Main.java >> >> >> - Imports of java.util.logging.Level and Logger are unused? >> >> - Missing "-server" line from usage(). >> >> - Interesting use of enum. Note by convention an enum is like a class and >> names are in mixed case, thus use OutputFormat instead of OUTPUT_FORMAT. Also >> note that the enum doesn't buy much, at least in terms of lines of code, since >> the enum declaration and enum instance overrides add about as much code as the >> case statement that got removed from setupReporter(). It does buy a bit of >> type-safety, though, so might as well leave it in. >> >> - Enum instance HTML should be on a new line, like XML. >> >> - Reflection code can be chained instead of declaring several locals. This is >> mainly a matter of taste, but to my eye it's cleaner. The main advantage is >> avoiding the need to come up with names for intermediate locals. For example: >> >> port = (int) Class.forName("TestLibrary") >> .getMethod("getUnusedRandomPort") >> .invoke(null); >> >> - Catch clause at 389 can be of ReflectiveOperationException. This covers >> everything except IllegalArgumentException, which is unchecked, so you don't >> need to catch it. >> >> (Not sure why Method.invoke is declared to throw IllegalArgumentException, >> since generally only checked exceptions are declared in the throws clause.) >> >> - Line 416, no need to mention RMISecurityManager in a comment, just make the >> change to use SecurityManager. >> >> - It's kind of surprising that TEST_SRC_PATH appends the file separator to >> the test.src property. At line 241 test.src has to be fetched again to use it >> without the file separator. >> >> - Line 234, instead of the java.home property, use the test.jdk property. >> This will use the JDK under test instead of the JDK that's running jtreg. In >> practice it's unclear whether this makes any actual difference today, but it's >> good to try to keep this separation. Also, use file separators here instead of >> appending "/bin/java". >> >> (Hmmm. I observe that the RMI testlibrary invokes JVM subprocesses using >> java.home.) >> >> >> Thanks, >> >> >> s'marks >> >> >> On 11/20/13 1:49 PM, Stuart Marks wrote: >>> Hi, sorry about the delay, I'm still backlogged from traveling. I'll get to this >>> soon. >>> >>> s'marks >>> >>> On 11/19/13 6:27 PM, Tristan Yan wrote: >>>> Hi Stuart >>>> Did you get chance to review it again. >>>> Let me know if you have any new comments or suggestions. >>>> Thanks >>>> Tristan >>>> >>>> -----????----- >>>> ???: Tristan Yan >>>> ????: Thursday, November 14, 2013 11:09 PM >>>> ???: Stuart Marks >>>> ??: core-libs-dev at openjdk.java.net >>>> ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently because of >>>> use of fixed port >>>> >>>> Thank you Stuart >>>> It took me a little time to correct the code. sorry be late. This is new >>>> webrev for the code change. Please help to review it again. >>>> >>>> Description: >>>> 1. Convert shell script test to Java program test. >>>> 2. Using random server port by reusing Darryl Mocek's >>>> work(TestLibrary.getUnusedRandomPort) to replace fixed server port. >>>> 3. Because TestLibrary doesn't have package. Here is using reflection to call >>>> TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary >>>> moves to named package. >>>> 4. Using java Process class to start client process. Client and server are >>>> sharing IO. >>>> 5. Also convert other shell script test runSerialBench.sh to java program test >>>> also. >>>> 6. ProblemList has been changed to get back >>>> java/rmi/reliability/benchmark/runRmiBench.sh test. >>>> >>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>> >>>> Thank you so much >>>> Tristan >>>> >>>> >>>> -----????----- >>>> ???: Stuart Marks >>>> ????: Tuesday, November 12, 2013 11:38 PM >>>> ???: Tristan Yan >>>> ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline >>>> ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of >>>> use of fixed port >>>> >>>> Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI >>>> tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" >>>> port range that's used by some RMI tests that have to used fixed ports. >>>> >>>> s'marks >>>> >>>> On 11/11/13 2:39 PM, Tristan Yan wrote: >>>>> Hi Stuart >>>>> Also there is one more solution, which is there is one >>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same >>>>> function as >>>>> TestLibrary.getUnusedRandomPort() and it has named package. Do you >>>>> mind I use this one? >>>>> Since these two functions provide same functionality. Maybe we should >>>>> think about to merge them at the same time. >>>>> Thank you >>>>> Tristan >>>>> >>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>> Hi Stuart >>>>>> I tried your suggestion but unfortunately all the benchmarks have >>>>>> dependencies to Main class because they need get stub from server. I >>>>>> suggest we move the benchmark tests to unnamed package unless we do >>>>>> want to put TestLibrary into a named package right now. >>>>>> Please let me know if you have objection on this. >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>> Hi Tristan, >>>>>>> >>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>> unnamed package. Classes in a named package cannot import classes >>>>>>> from the unnamed package. We've run into problems with this before. >>>>>>> Eventually, we should move TestLibrary a named package. >>>>>>> >>>>>>> I think it's possible to work around this without too much >>>>>>> difficulty. Note that classes in the unnamed package can import classes >>>>>>> from named packages. >>>>>>> So, perhaps you can put the RmiBench main class in the unnamed >>>>>>> package so it has access to TestLibrary. Then have the benchmarks >>>>>>> themselves in the bench.rmi package. The config file already >>>>>>> references the benchmarks by fully qualified class name (e.g., >>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to >>>>>>> get this to work. >>>>>>> >>>>>>> s'marks >>>>>>> >>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>> Thank you, Stuart >>>>>>>> There is one review point I want to ask you opinion. Which is the >>>>>>>> reason that I moved from >>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>>>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>>>>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>>>>>> class, I couldn't find a way to let a class which has Package to access >>>>>>>> the class without package. Do you have suggestion on that? >>>>>>>> Thank you so much. >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>> Hi Everyone >>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>> >>>>>>>>>> Description: >>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>>>>> replace fixed server port. >>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>>>>>> program test also >>>>>>>>> >>>>>>>>> Hi Tristan, >>>>>>>>> >>>>>>>>> Several comments on this webrev. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The original arrangement within the >>>>>>>>> test/java/rmi/reliability/benchmark >>>>>>>>> directory had the main benchmark files (scripts) at the top, some >>>>>>>>> benchmark framework files in the "bench" subdirectory, and the >>>>>>>>> actual RMI and serialization benchmarks in bench/rmi and bench/serial >>>>>>>>> subdirectories. >>>>>>>>> >>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>>>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>>>>>> main serial benchmark test is now buried in the bench/serial >>>>>>>>> directory. The nice organization that was there before is now >>>>>>>>> spoiled. Is this rearrangement necessary in order to convert the scripts >>>>>>>>> to Java? I would prefer the original arrangement be left in place. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>>>>> >>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>>>>>> -c config >>>>>>>>> >>>>>>>>> There is a subtle but serious problem here: the -server option is >>>>>>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>> The main() method gets neither a -server nor a -client argument, >>>>>>>>> so its default "run mode" as defined by the benchmark itself is >>>>>>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>>>>>> different from the shell script, which ran separate client and server >>>>>>>>> JVMs. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The logic to process the -server argument still expects to take >>>>>>>>> a port, even though the port is assigned automatically. So the >>>>>>>>> obvious fix to the above, >>>>>>>>> >>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>>>>>> -c config >>>>>>>>> >>>>>>>>> doesn't work, since a port is missing. The logic to increment the >>>>>>>>> argument index to collect the port argument should be removed. >>>>>>>>> Also, the -server line should be restored to the usage message, but >>>>>>>>> without the port argument. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** After this is done, the client's command line is constructed >>>>>>>>> improperly. >>>>>>>>> The command line ends up looking something like this: >>>>>>>>> >>>>>>>>> java client -cp Main client localhost:58583 -c >>>>>>>>> config >>>>>>>>> >>>>>>>>> The word "client" appears twice, but what's really required is >>>>>>>>> "-client" to appear as an argument after Main. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The client is run using ProcessBuilder, which by default sends >>>>>>>>> stdout and stderr to pipes to be read by the parent. But the >>>>>>>>> parent never reads them, thus any messages from the client are >>>>>>>>> never seen. The client is the one that emits the benchmark report, >>>>>>>>> so its output needs to be seen. It might be sufficient to have the >>>>>>>>> client inherit the parent's stdout and stderr. This might intermix >>>>>>>>> the client's and server's output, but it's better than nothing. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The config file is checked with the following code: >>>>>>>>> >>>>>>>>> try { >>>>>>>>> confFile = args[i]; >>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>> } catch (IOException e) { >>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>> } >>>>>>>>> >>>>>>>>> This is potentially misleading, as the message doesn't print the >>>>>>>>> actual filename that was attempted to be opened. >>>>>>>>> >>>>>>>>> This is important, as the test.src property doesn't exist in the client >>>>>>>>> JVM. >>>>>>>>> >>>>>>>>> Note that the original shell script passed full pathnames for the >>>>>>>>> config file to both the client and the server. The new @run tag >>>>>>>>> merely says "-c config" which redefines the config filename to be >>>>>>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>>>>>> to the client, but it seems like there should be something better than >>>>>>>>> can be done. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The client needs to have its security policy set up. This is >>>>>>>>> missing from the construction of the client's command line. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** ProcessBuilder takes a List for its command; there is >>>>>>>>> no need to turn the list into an array. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>> >>>>>>>>> while (true) { >>>>>>>>> runBenchmarks(); >>>>>>>>> if (exitRequested) { >>>>>>>>> System.exit(); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> was replaced with >>>>>>>>> >>>>>>>>> while (!exitRequested) { >>>>>>>>> runBenchmarks(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> This is a subtle logic change, in that the former code always >>>>>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>>>>> possible that a timer could set exitRequested before loop entry, >>>>>>>>> resulting in the benchmark running zero times. I guess, if you >>>>>>>>> really want to clean this up (we do need to avoid System.exit in jtreg >>>>>>>>> tests), use a do-while loop instead. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>>>>>> ProblemList.txt. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> It would be good if you could fix up these issues and post another webrev. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thank you >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>> I am working on bug >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>>>>>> addressed by Stuart Marks in other RMI tests which are Java based. I >>>>>>>>>>>> would like to reuse his solution, however it does not work for shell >>>>>>>>>>>> based tests. >>>>>>>>>>> >>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>> >>>>>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>>>>>> there is one >>>>>>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has named >>>>>>>>>>> package. >>>>>>>>>>> Do you mind I use this one? >>>>>>>>>>> Since these two function provide same functionality. Maybe we >>>>>>>>>>> should think about to merge them. >>>>>>>>>>> Thank you >>>>>>>>>>> Tristan >>>>>>>>>>> >>>>>>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>>>>>> Hi Stuart >>>>>>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>>>>>> package unless we do want to put TestLibrary into a named package >>>>>>>>>>>> right now. >>>>>>>>>>>> Please let me know if you have objection on this. >>>>>>>>>>>> Thank you >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>>>>>> this before. Eventually, we should move TestLibrary a named package. >>>>>>>>>>>>> >>>>>>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>>>>>> qualified class name (e.g., >>>>>>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>>>>>> be able to get this to work. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>>>>>> Thank you, Stuart >>>>>>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>>>>>> the reason that I moved from >>>>>>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>>>>>> let a class which has Package to access the class without package. >>>>>>>>>>>>>> Do you have suggestion on that? >>>>>>>>>>>>>> Thank you so much. >>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>>>>>> Hi Everyone >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Description: >>>>>>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>>>>>> to java program test also >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and bench/serial >>>>>>>>>>>>>>> subdirectories. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>>>>>> but the main serial benchmark test is now buried in the >>>>>>>>>>>>>>> bench/serial directory. >>>>>>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>>>>>> scripts to Java? I would prefer the original arrangement be left in >>>>>>>>>>>>>>> place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>>>>>> form, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>>>>>>> Main -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the >>>>>>>>>>>>>>> main() method. >>>>>>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>>>>>> argument, so its default "run mode" as defined by the benchmark >>>>>>>>>>>>>>> itself is SAMEVM. >>>>>>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>>>>>> different from the shell script, which ran separate client and >>>>>>>>>>>>>>> server JVMs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>>>>>> -server -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>>>>>> constructed improperly. The command line ends up looking something >>>>>>>>>>>>>>> like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>>>>>> -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>>>>>> But the parent never reads them, thus any messages from the client >>>>>>>>>>>>>>> are never seen. >>>>>>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>>>>>> might intermix the client's and server's output, but it's better >>>>>>>>>>>>>>> than nothing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>> confFile = args[i]; >>>>>>>>>>>>>>> confstr = new >>>>>>>>>>>>>>> FileInputStream(System.getProperty("test.src") >>>>>>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>>>>>> the client JVM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> while (true) { >>>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>>> if (exitRequested) { >>>>>>>>>>>>>>> System.exit(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> was replaced with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while loop >>>>>>>>>>>>>>> instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>>>>>> another webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>>>>>> recipients. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> the message to >>>>>>>>>>> the recipients. >>>>>>>>>>> >>>>>>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>>>>>> solution by Stuart Marks to address the issue >>>>>>>>>>>> >>>>>>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>>>>>> In the >>>>>>>>>>>> past there have been sync issues between server/client which >>>>>>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>>>>>> allow for server and client to start up and also give us better >>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>> >>>>>>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>>>>>> difficult to make reliable shell tests, especially for >>>>>>>>>>> multi-process tests like this one. >>>>>>>>>>> There is the unique port issue, and there is also the issue of >>>>>>>>>>> how long for the client to wait until the server is ready. Error >>>>>>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>>>>>> this case. They might hang or erroneously report success. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to >>>>>>>>>>> it. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> > From tristan.yan at oracle.com Tue Dec 3 01:12:34 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 2 Dec 2013 17:12:34 -0800 (PST) Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IFJGUiBmb3IgSkRLLTcx?= =?utf-8?B?OTAxMDYgUk1JIGJlbmNobWFyayBmYWk=?= =?utf-8?B?bHMgaW50ZXJtaXR0ZW50bHkgYmVjYXU=?= =?utf-8?B?c2Ugb2YgdXNlIG9mIGZpeGVkIHBvcnQ=?= In-Reply-To: <529D2FB6.9000705@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> <528D2E57.1070001@oracle.com> <52940923.8000903@oracle.com> <52942DBE.5050801@oracle.com> <529D2FB6.9000705@oracle.com> Message-ID: Thank you Stuart, next time I will keep the last version. I'm appreciated that you can sponsor this for me. Thank you very much. Tristan. -----????----- ???: Stuart Marks ????: Tuesday, December 03, 2013 9:11 AM ???: Tristan Yan ??: core-libs-dev at openjdk.java.net ??: Re: ??: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Hi Tristan, Sorry (again^2) for the delay. Holiday weekend here in the U.S. The latest webrev looks fine. Did you need a sponsor for this? I can push it for you. I guess we also need an official Reviewer before I can push it. (One additional point for the future. If there is more than one round of review, it's useful to post the new webrev alongside the old one, instead of overwriting it, so that old links are still valid. It's not likely to happen in this case, but if someone were to read the email archives and follow the link to an earlier webrev, they'd have no idea what I was talking about.) s'marks On 11/25/13 9:12 PM, Tristan Yan wrote: > Hi Stuart > Thanks for your code review. I updated the webrev according your suggestion. > Could you review it again? > > http://cr.openjdk.java.net/~ewang/tristan/JDK-7190106/webrev.00/ > Tristan > > On 11/26/2013 10:36 AM, Stuart Marks wrote: >> Hi Tristan, >> >> Finally getting back to this. Again, sorry for the delay. >> >> The changes look much better now. I've listed a bunch of items below, >> but they're all comparatively minor, even nitpicky. But there are a >> few things that should be cleaned up before we integrate this. >> >> Items listed below. >> >> >> ** bench/serial/Main.java >> >> >> - The description should simply be "The Serialization benchmark >> test". This test has nothing to do with RMI, even though it's under >> the java/rmi hierarchy in the filesystem. >> >> - parseArgs() uses strings-in-switch! Good, but put "break" on its >> own line instead of following the close-brace of the catch clause. >> (rmi/Main.java doesn't have this issue.) >> >> >> ** bench/rmi/Main.java >> >> >> - Imports of java.util.logging.Level and Logger are unused? >> >> - Missing "-server" line from usage(). >> >> - Interesting use of enum. Note by convention an enum is like a >> class and names are in mixed case, thus use OutputFormat instead of >> OUTPUT_FORMAT. Also note that the enum doesn't buy much, at least in >> terms of lines of code, since the enum declaration and enum instance >> overrides add about as much code as the case statement that got >> removed from setupReporter(). It does buy a bit of type-safety, though, so might as well leave it in. >> >> - Enum instance HTML should be on a new line, like XML. >> >> - Reflection code can be chained instead of declaring several >> locals. This is mainly a matter of taste, but to my eye it's cleaner. >> The main advantage is avoiding the need to come up with names for intermediate locals. For example: >> >> port = (int) Class.forName("TestLibrary") >> .getMethod("getUnusedRandomPort") >> .invoke(null); >> >> - Catch clause at 389 can be of ReflectiveOperationException. This >> covers everything except IllegalArgumentException, which is >> unchecked, so you don't need to catch it. >> >> (Not sure why Method.invoke is declared to throw >> IllegalArgumentException, since generally only checked exceptions are >> declared in the throws clause.) >> >> - Line 416, no need to mention RMISecurityManager in a comment, just >> make the change to use SecurityManager. >> >> - It's kind of surprising that TEST_SRC_PATH appends the file >> separator to the test.src property. At line 241 test.src has to be >> fetched again to use it without the file separator. >> >> - Line 234, instead of the java.home property, use the test.jdk property. >> This will use the JDK under test instead of the JDK that's running >> jtreg. In practice it's unclear whether this makes any actual >> difference today, but it's good to try to keep this separation. Also, >> use file separators here instead of appending "/bin/java". >> >> (Hmmm. I observe that the RMI testlibrary invokes JVM subprocesses >> using >> java.home.) >> >> >> Thanks, >> >> >> s'marks >> >> >> On 11/20/13 1:49 PM, Stuart Marks wrote: >>> Hi, sorry about the delay, I'm still backlogged from traveling. I'll >>> get to this soon. >>> >>> s'marks >>> >>> On 11/19/13 6:27 PM, Tristan Yan wrote: >>>> Hi Stuart >>>> Did you get chance to review it again. >>>> Let me know if you have any new comments or suggestions. >>>> Thanks >>>> Tristan >>>> >>>> -----????----- >>>> ???: Tristan Yan >>>> ????: Thursday, November 14, 2013 11:09 PM >>>> ???: Stuart Marks >>>> ??: core-libs-dev at openjdk.java.net >>>> ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently >>>> because of use of fixed port >>>> >>>> Thank you Stuart >>>> It took me a little time to correct the code. sorry be late. This >>>> is new webrev for the code change. Please help to review it again. >>>> >>>> Description: >>>> 1. Convert shell script test to Java program test. >>>> 2. Using random server port by reusing Darryl Mocek's >>>> work(TestLibrary.getUnusedRandomPort) to replace fixed server port. >>>> 3. Because TestLibrary doesn't have package. Here is using >>>> reflection to call TestLibrary.getUnusedRandomPort. This is going >>>> to change when TestLibrary moves to named package. >>>> 4. Using java Process class to start client process. Client and >>>> server are sharing IO. >>>> 5. Also convert other shell script test runSerialBench.sh to java >>>> program test also. >>>> 6. ProblemList has been changed to get back >>>> java/rmi/reliability/benchmark/runRmiBench.sh test. >>>> >>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>> >>>> Thank you so much >>>> Tristan >>>> >>>> >>>> -----????----- >>>> ???: Stuart Marks >>>> ????: Tuesday, November 12, 2013 11:38 PM >>>> ???: Tristan Yan >>>> ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline >>>> ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently >>>> because of use of fixed port >>>> >>>> Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for >>>> the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" >>>> port range that's used by some RMI tests that have to used fixed ports. >>>> >>>> s'marks >>>> >>>> On 11/11/13 2:39 PM, Tristan Yan wrote: >>>>> Hi Stuart >>>>> Also there is one more solution, which is there is one >>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>> same function as >>>>> TestLibrary.getUnusedRandomPort() and it has named package. Do you >>>>> mind I use this one? >>>>> Since these two functions provide same functionality. Maybe we >>>>> should think about to merge them at the same time. >>>>> Thank you >>>>> Tristan >>>>> >>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>> Hi Stuart >>>>>> I tried your suggestion but unfortunately all the benchmarks have >>>>>> dependencies to Main class because they need get stub from >>>>>> server. I suggest we move the benchmark tests to unnamed package >>>>>> unless we do want to put TestLibrary into a named package right now. >>>>>> Please let me know if you have objection on this. >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>> Hi Tristan, >>>>>>> >>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>> unnamed package. Classes in a named package cannot import >>>>>>> classes from the unnamed package. We've run into problems with this before. >>>>>>> Eventually, we should move TestLibrary a named package. >>>>>>> >>>>>>> I think it's possible to work around this without too much >>>>>>> difficulty. Note that classes in the unnamed package can import >>>>>>> classes from named packages. >>>>>>> So, perhaps you can put the RmiBench main class in the unnamed >>>>>>> package so it has access to TestLibrary. Then have the >>>>>>> benchmarks themselves in the bench.rmi package. The config file >>>>>>> already references the benchmarks by fully qualified class name >>>>>>> (e.g., >>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>> be able to get this to work. >>>>>>> >>>>>>> s'marks >>>>>>> >>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>> Thank you, Stuart >>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>> the reason that I moved from >>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>>>>> test/java/rmi/reliability/benchmark is Main.java need access >>>>>>>> class TestLibrary for supporting random port. TestLibrary is a >>>>>>>> unpackage class, I couldn't find a way to let a class which has >>>>>>>> Package to access the class without package. Do you have suggestion on that? >>>>>>>> Thank you so much. >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>> Hi Everyone >>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>> >>>>>>>>>> Description: >>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>>>>> replace fixed server port. >>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh to >>>>>>>>>> java program test also >>>>>>>>> >>>>>>>>> Hi Tristan, >>>>>>>>> >>>>>>>>> Several comments on this webrev. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The original arrangement within the >>>>>>>>> test/java/rmi/reliability/benchmark >>>>>>>>> directory had the main benchmark files (scripts) at the top, >>>>>>>>> some benchmark framework files in the "bench" subdirectory, >>>>>>>>> and the actual RMI and serialization benchmarks in bench/rmi >>>>>>>>> and bench/serial subdirectories. >>>>>>>>> >>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>> but the main serial benchmark test is now buried in the >>>>>>>>> bench/serial directory. The nice organization that was there >>>>>>>>> before is now spoiled. Is this rearrangement necessary in >>>>>>>>> order to convert the scripts to Java? I would prefer the original arrangement be left in place. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>> form, >>>>>>>>> >>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>> Main -c config >>>>>>>>> >>>>>>>>> There is a subtle but serious problem here: the -server option >>>>>>>>> is passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>> argument, so its default "run mode" as defined by the >>>>>>>>> benchmark itself is SAMEVM. This runs the client and server in >>>>>>>>> the same JVM, which is different from the shell script, which >>>>>>>>> ran separate client and server JVMs. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The logic to process the -server argument still expects to >>>>>>>>> take a port, even though the port is assigned automatically. >>>>>>>>> So the obvious fix to the above, >>>>>>>>> >>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>> -server -c config >>>>>>>>> >>>>>>>>> doesn't work, since a port is missing. The logic to increment >>>>>>>>> the argument index to collect the port argument should be removed. >>>>>>>>> Also, the -server line should be restored to the usage >>>>>>>>> message, but without the port argument. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** After this is done, the client's command line is >>>>>>>>> constructed improperly. >>>>>>>>> The command line ends up looking something like this: >>>>>>>>> >>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>> -c config >>>>>>>>> >>>>>>>>> The word "client" appears twice, but what's really required is >>>>>>>>> "-client" to appear as an argument after Main. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>> sends stdout and stderr to pipes to be read by the parent. But >>>>>>>>> the parent never reads them, thus any messages from the client >>>>>>>>> are never seen. The client is the one that emits the benchmark >>>>>>>>> report, so its output needs to be seen. It might be sufficient >>>>>>>>> to have the client inherit the parent's stdout and stderr. >>>>>>>>> This might intermix the client's and server's output, but it's better than nothing. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The config file is checked with the following code: >>>>>>>>> >>>>>>>>> try { >>>>>>>>> confFile = args[i]; >>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>> } catch (IOException e) { >>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>> } >>>>>>>>> >>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>> >>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>> the client JVM. >>>>>>>>> >>>>>>>>> Note that the original shell script passed full pathnames for >>>>>>>>> the config file to both the client and the server. The new >>>>>>>>> @run tag merely says "-c config" which redefines the config >>>>>>>>> filename to be relative to the test.src directory. You could pass -Dtest.src=... >>>>>>>>> to the client, but it seems like there should be something >>>>>>>>> better than can be done. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** ProcessBuilder takes a List for its command; there >>>>>>>>> is no need to turn the list into an array. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>> >>>>>>>>> while (true) { >>>>>>>>> runBenchmarks(); >>>>>>>>> if (exitRequested) { >>>>>>>>> System.exit(); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> was replaced with >>>>>>>>> >>>>>>>>> while (!exitRequested) { >>>>>>>>> runBenchmarks(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> This is a subtle logic change, in that the former code always >>>>>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>>>>> possible that a timer could set exitRequested before loop >>>>>>>>> entry, resulting in the benchmark running zero times. I guess, >>>>>>>>> if you really want to clean this up (we do need to avoid >>>>>>>>> System.exit in jtreg tests), use a do-while loop instead. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>> from ProblemList.txt. >>>>>>>>> >>>>>>>>> >>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> It would be good if you could fix up these issues and post another webrev. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thank you >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>> I am working on bug >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on >>>>>>>>>>>> my research, it looks like the issue of fixed port was >>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests which >>>>>>>>>>>> are Java based. I would like to reuse his solution, however >>>>>>>>>>>> it does not work for shell based tests. >>>>>>>>>>> >>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>> >>>>>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>>>>> through. Most OpenJDK mailing lists strip off attachments >>>>>>>>>>> before forwarding Hi Stuart Also there is one more solution, >>>>>>>>>>> which is there is one >>>>>>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. >>>>>>>>>>> It's same function as TestLibrary.getUnusedRandomPort() and >>>>>>>>>>> it has named package. >>>>>>>>>>> Do you mind I use this one? >>>>>>>>>>> Since these two function provide same functionality. Maybe >>>>>>>>>>> we should think about to merge them. >>>>>>>>>>> Thank you >>>>>>>>>>> Tristan >>>>>>>>>>> >>>>>>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>>>>>> Hi Stuart >>>>>>>>>>>> I tried your suggestion but unfortunately all the >>>>>>>>>>>> benchmarks have dependencies to Main class because they >>>>>>>>>>>> need get stub from server. I suggest we move the benchmark >>>>>>>>>>>> tests to unnamed package unless we do want to put >>>>>>>>>>>> TestLibrary into a named package right now. >>>>>>>>>>>> Please let me know if you have objection on this. >>>>>>>>>>>> Thank you >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in >>>>>>>>>>>>> the unnamed package. Classes in a named package cannot >>>>>>>>>>>>> import classes from the unnamed package. We've run into >>>>>>>>>>>>> problems with this before. Eventually, we should move TestLibrary a named package. >>>>>>>>>>>>> >>>>>>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>>>>>> Note that classes in the unnamed package can import >>>>>>>>>>>>> classes from named packages. So, perhaps you can put the >>>>>>>>>>>>> RmiBench main class in the unnamed package so it has access to TestLibrary. >>>>>>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>>>>>> qualified class name (e.g., >>>>>>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you >>>>>>>>>>>>> ought to be able to get this to work. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>>>>>> Thank you, Stuart >>>>>>>>>>>>>> There is one review point I want to ask you opinion. >>>>>>>>>>>>>> Which is the reason that I moved from >>>>>>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way >>>>>>>>>>>>>> to let a class which has Package to access the class without package. >>>>>>>>>>>>>> Do you have suggestion on that? >>>>>>>>>>>>>> Thank you so much. >>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>>>>>> Hi Everyone >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webr >>>>>>>>>>>>>>>> ev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Description: >>>>>>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's >>>>>>>>>>>>>>>> work to replace fixed server port. >>>>>>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>>>>>> 4. Also convert other shell script test >>>>>>>>>>>>>>>> runSerialBench.sh to java program test also >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the >>>>>>>>>>>>>>> main benchmark files (scripts) at the top, some >>>>>>>>>>>>>>> benchmark framework files in the "bench" subdirectory, >>>>>>>>>>>>>>> and the actual RMI and serialization benchmarks in >>>>>>>>>>>>>>> bench/rmi and bench/serial subdirectories. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The webrev moves all the RMI benchmarks to the top >>>>>>>>>>>>>>> benchmark directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>>>>>> The RMI benchmarks are now all cluttering the top >>>>>>>>>>>>>>> directory, but the main serial benchmark test is now >>>>>>>>>>>>>>> buried in the bench/serial directory. >>>>>>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>>>>>> scripts to Java? I would prefer the original arrangement >>>>>>>>>>>>>>> be left in place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of >>>>>>>>>>>>>>> the form, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 >>>>>>>>>>>>>>> -server Main -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>>>>>> option is passed to the >>JVM<< and not as an argument >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> main() method. >>>>>>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>>>>>> argument, so its default "run mode" as defined by the >>>>>>>>>>>>>>> benchmark itself is SAMEVM. >>>>>>>>>>>>>>> This runs the client and server in the same JVM, which >>>>>>>>>>>>>>> is different from the shell script, which ran separate >>>>>>>>>>>>>>> client and server JVMs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The logic to process the -server argument still >>>>>>>>>>>>>>> expects to take a port, even though the port is assigned >>>>>>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 >>>>>>>>>>>>>>> Main -server -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>>>>>> increment the argument index to collect the port >>>>>>>>>>>>>>> argument should be removed. Also, the -server line >>>>>>>>>>>>>>> should be restored to the usage message, but without the port argument. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>>>>>> constructed improperly. The command line ends up looking >>>>>>>>>>>>>>> something like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java client -cp Main client >>>>>>>>>>>>>>> localhost:58583 -c config >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The word "client" appears twice, but what's really >>>>>>>>>>>>>>> required is "-client" to appear as an argument after Main. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The client is run using ProcessBuilder, which by >>>>>>>>>>>>>>> default sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>>>>>> But the parent never reads them, thus any messages from >>>>>>>>>>>>>>> the client are never seen. >>>>>>>>>>>>>>> The client is the one that emits the benchmark report, >>>>>>>>>>>>>>> so its output needs to be seen. It might be sufficient >>>>>>>>>>>>>>> to have the client inherit the parent's stdout and >>>>>>>>>>>>>>> stderr. This might intermix the client's and server's >>>>>>>>>>>>>>> output, but it's better than nothing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>> confFile = args[i]; >>>>>>>>>>>>>>> confstr = new >>>>>>>>>>>>>>> FileInputStream(System.getProperty("test.src") >>>>>>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is potentially misleading, as the message doesn't >>>>>>>>>>>>>>> print the actual filename that was attempted to be opened. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is important, as the test.src property doesn't >>>>>>>>>>>>>>> exist in the client JVM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note that the original shell script passed full >>>>>>>>>>>>>>> pathnames for the config file to both the client and the >>>>>>>>>>>>>>> server. The new @run tag merely says "-c config" which >>>>>>>>>>>>>>> redefines the config filename to be relative to the test.src directory. >>>>>>>>>>>>>>> You could pass -Dtest.src=... to the client, but it >>>>>>>>>>>>>>> seems like there should be something better than can be done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** The client needs to have its security policy set up. >>>>>>>>>>>>>>> This is missing from the construction of the client's command line. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> while (true) { >>>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>>> if (exitRequested) { >>>>>>>>>>>>>>> System.exit(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> was replaced with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>>>>>> always executed the loop at least once. It seems >>>>>>>>>>>>>>> unlikely, but it's possible that a timer could set >>>>>>>>>>>>>>> exitRequested before loop entry, resulting in the >>>>>>>>>>>>>>> benchmark running zero times. I guess, if you really >>>>>>>>>>>>>>> want to clean this up (we do need to avoid System.exit >>>>>>>>>>>>>>> in jtreg tests), use a do-while loop instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh >>>>>>>>>>>>>>> entry from ProblemList.txt. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** Remove the references to RMISecurityManager and just >>>>>>>>>>>>>>> use SecurityManager. This is just general cleanup. (I >>>>>>>>>>>>>>> deprecated RMISecurityManager last week.) :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be good if you could fix up these issues and >>>>>>>>>>>>>>> post another webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. >>>>>>>>>>>>>>>>>> Based on my research, it looks like the issue of >>>>>>>>>>>>>>>>>> fixed port was already addressed by Stuart Marks in >>>>>>>>>>>>>>>>>> other RMI tests which are Java based. I would like to >>>>>>>>>>>>>>>>>> reuse his solution, however it does not work for shell based tests. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI >>>>>>>>>>>>>>>>> tests.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was the patch attached to your message? If so, it >>>>>>>>>>>>>>>>> didn't get through. Most OpenJDK mailing lists strip >>>>>>>>>>>>>>>>> off attachments before forwarding the message to the >>>>>>>>>>>>>>>>> recipients. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>>>>>> script test into Java based test and re-use the >>>>>>>>>>>>>>>>>> dynamic port allocation solution by Stuart Marks to >>>>>>>>>>>>>>>>>> address the issue >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3. Also this test was written with server/client mode >>>>>>>>>>>>>>>>>> in shell script. In the past there have been sync >>>>>>>>>>>>>>>>>> issues between server/client which caused the test to >>>>>>>>>>>>>>>>>> fail. If we convert the shell script into Java based >>>>>>>>>>>>>>>>>> test, it would avoid using "sleep 10" mechanism to >>>>>>>>>>>>>>>>>> allow for server and client to start up and also give >>>>>>>>>>>>>>>>>> us better control in synchronizing server and client. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Background for interested readers.) In general, yes, >>>>>>>>>>>>>>>>> it's quite difficult to make reliable shell tests, >>>>>>>>>>>>>>>>> especially for multi-process tests like this one. >>>>>>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>>>>>> issue of how long for the client to wait until the >>>>>>>>>>>>>>>>> server is ready. Error handling is also a problem, for >>>>>>>>>>>>>>>>> example, if one of the JVMs gets an unexpected >>>>>>>>>>>>>>>>> exception, it's easy for shell tests to mishandle this >>>>>>>>>>>>>>>>> case. They might hang or erroneously report success. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so >>>>>>>>>>>>>>>>> you need to upload it somewhere (e.g., >>>>>>>>>>>>>>>>> cr.openjdk.java.net) and then post a link to it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> the message to >>>>>>>>>>> the recipients. >>>>>>>>>>> >>>>>>>>>>>> 2. My recommendation would be to convert this shell script >>>>>>>>>>>> test into Java based test and re-use the dynamic port >>>>>>>>>>>> allocation solution by Stuart Marks to address the issue >>>>>>>>>>>> >>>>>>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>>>>>> In the >>>>>>>>>>>> past there have been sync issues between server/client >>>>>>>>>>>> which caused the test to fail. If we convert the shell >>>>>>>>>>>> script into Java based test, it would avoid using "sleep >>>>>>>>>>>> 10" mechanism to allow for server and client to start up >>>>>>>>>>>> and also give us better control in synchronizing server and client. >>>>>>>>>>> >>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>> quite difficult to make reliable shell tests, especially for >>>>>>>>>>> multi-process tests like this one. >>>>>>>>>>> There is the unique port issue, and there is also the issue >>>>>>>>>>> of how long for the client to wait until the server is >>>>>>>>>>> ready. Error handling is also a problem, for example, if one >>>>>>>>>>> of the JVMs gets an unexpected exception, it's easy for >>>>>>>>>>> shell tests to mishandle this case. They might hang or erroneously report success. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) and >>>>>>>>>>> then post a link to it. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> > From srikalyan.chandrashekar at oracle.com Tue Dec 3 02:39:47 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Mon, 02 Dec 2013 18:39:47 -0800 Subject: RFR for JDK-6963118 Intermittent test failure: test/java/nio/channels/Selector/Wakeup.java fail intermittently (win) Message-ID: <529D4473.8060909@oracle.com> Hi all, I am working on bug JDK-6963118 . Root Cause: - Sensitive timing dependency between events in Main and Sleeper threads are causes for test failure. Suggested Fix: 1) Main thread should wait for more than 1sec(made it 3sec) and check more often than 50ms(made it 1ms) intervals , sleeper thread may be still waiting for interrupt/wakeup hence main thread waiting for just 1sec to flag a failure is premature . The reason is especially on windows high priority virus scanners etc run(we faced it when simulating failures) and kept the system busy. 2) The test is essentially a sequence of 2 events a)Firing up wakeups/interrupts followed by a b)Check Check the sleeper.entries value and yield the main thread as required so that the above 2 events step in tandem. The webrev is hosted at http://cr.openjdk.java.net/~cl/host_for_kal/6963118-Wakeup/ . Please let me know if you have any comments or suggestions. -- -- Thanks kalyan From francis.andre.kampbell at orange.fr Tue Dec 3 04:03:37 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Tue, 03 Dec 2013 05:03:37 +0100 Subject: [7u]: org.omg.PortableServer.AdapterActivator.java compile fails on French platform Message-ID: <529D5819.2030202@orange.fr> Hi Found a surprising issue when building the jdk7u on a French platform with this compile error Z:\JDK\JDK7U-~2\build\windows-i586\corba\gensrc\org\omg\PortableServer\AdapterActivator.java:8: error: unmappable character for encoding ascii * lundi 2 d?cembre 2013 19 h 22 CET ^ In effect, the header generated is /** * org/omg/PortableServer/AdapterActivator.java . * Generated by the IDL-to-Java compiler (portable), version "3.2" * from ../../../../src/share/classes/org/omg/PortableServer/poa.idl * lundi 2 d?cembre 2013 19 h 22 CET */ which contains the "?" character in the french month of december. As the compiling command request an ASCII encoding, it fails as "?" is not ASCII. make[5]: Entering directory `/cygdrive/Z/JDK/jdk7u-dev/corba/make/org/omg/PortableServer' if [ -s Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list ] ; then \ /usr/bin/cat Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list; \ C:/Progra~1/Java/jdk1.6.0_35/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:Z:/JDK/JDK7U-~2/build/WINDOW~1/LANGTO~1/dist/bootstrap/lib/javac.jar" -jar Z:/JDK/JDK7U-~2/build/WINDOW~1/LANGTO~1/dist/bootstrap/lib/javac.jar -XDignore.symbol.file=true -source 7 -target 7 *-encoding ascii *-classpath C:/Progra~1/Java/jdk1.6.0_35/lib/tools.jar -Xprefer:source -sourcepath "Z:/JDK/JDK7U-~2/build/windows-i586/corba/gensrc;../../../../src/windows/classes;../../../../src/share/classes" -d Z:/JDK/JDK7U-~2/build/windows-i586/corba/classes @Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list; \ fi I would suggest to fix this issue by removing the "-encoding ascii" parameter since pao.idl should contains only ascii characters and is not subject to i18n problem (except for the idl-to-java translation time in the header comment). Francis From peter.levart at gmail.com Tue Dec 3 07:36:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Dec 2013 08:36:48 +0100 Subject: 8029281: Synchronization issues in Logger and LogManager In-Reply-To: <52987D5D.6070800@oracle.com> References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com> <529752AB.2050101@oracle.com> <52987D5D.6070800@oracle.com> Message-ID: <529D8A10.6090609@gmail.com> Hi Daniel, 1st sorry for the delay. I promised looking at the patch, but was then distracted by other things. I think that synchronization in LogManager is correct now. The fact that Mandy thinks so is also reassuring. I wonder if calling LoggerWeakRef.dispose() from LoggerContext.addLocalLoger() is needed now that you check the LogNode.loggerRef before clearing in LoggerWeakRef.dispose(): if (n.loggerRef == this) { n.loggerRef = null; // clear LogNode's weak ref to us } The LoggerContext.addLocalLoger() will already overwrite the namedLoggers Hashtable entry for the logger's name with new LoggerWeakRef: namedLoggers.put(name, ref); ...and it will already overwrite the LogNode.loggerRef with new LoggerWeakRef: // Find the new node and its parent. LogNode node = getNode(name); node.loggerRef = ref; So the only effect of calling LoggerWeakRef.dispose() from LoggerContext.addLocalLoger() is a more prompt unlinking of LoggerWeakRef child, which has already been cleared but not yet disposed(), from parent logger. This will eventually happen in a call to LogManager.drainLoggerRefQueueBounded(), called from public LogManager.addLogger(), which is the only entry point to LoggerContext.addLocalLoger(). But it's not wrong as it is now when you also ensure more prompt unlinking of cleared LoggerWeakRef and code is more uniform and less fragile then it would be if you created and called a hypothetical disposeFromParent() which only took care of unlinking from parent logger... Regards, Peter On 11/29/2013 12:41 PM, Daniel Fuchs wrote: > Hi, > > Here is a new revision that includes Peter's findings. > Thanks again for that Peter! > > > > It has passed all jdk_core tests and running the new tests > in a loop hasn't triggered any of the issues that appeared > before the fix. > > -- daniel > > On 11/28/13 3:26 PM, Daniel Fuchs wrote: >> On 11/27/13 10:34 PM, Peter Levart wrote: >>> Hi Daniel, >>> >>> I have started looking at the LogManager change first, and here's the >>> 1st race I found... >> >> Hi Peter, >> >> Thanks a lot for your feedback! see below... >> >>> The new method LoggerWeakRef.dispose() can be called from 3 places: >>> >>> - LoggerContext.addLocalLogger >>> - LoggerContext.findLogger >>> - LogManager.drainLoggerRefQueueBounded which is called from public >>> method LogManager.addLogger >>> >>> The 1st and 2nd are guarded by LoggerContext.this lock, but the 3rd is >>> unguarded. >>> >>> What can happen is the following: >>> >>> Thread1: >>> LogManager.addLogger(someLogger) >>> LogManager.drainLoggerRefQueueBounded() // finds some enqueued >>> LoggerWeakRef for name == 'X.Y' and... >>> LoggerWeakRef.dispose() // this is 1st call to dispose, >>> so... >>> synchronized (LoggerWeakRef.this) { >>> disposed = true; >>> } >>> >>> ---context switch--- >>> >>> Thread2: >>> LogManager.addLogger(logger{name=='X.Y'}) >>> LogManager.drainLoggerRefQueueBounded() // no enqueued >>> refs... >>> LoggerContext.addLocalLogger(logger{name=='X.Y'}, true) >>> LoggerWeakRef ref = namedLoggers.get(name); // returns >>> a non-null ref ('X.Y' still points to a cleared weak ref) >>> if (ref.get() == null) { >>> ref.dispose(); // this is a 2nd call to this ref, >>> so it returns quickly >>> } >>> // ... namedLoggers gets new entry, etc... >>> LogNode node = getNode(name); // get node for 'X.Y' >>> * node.loggerRef = ref;* >>> >>> ---context switch--- >>> >>> Thread1: (still in LoggerWeakRef.dispose()) >>> if (node != null) { >>> * node.loggerRef = null;* // clear LogNode's weak >>> ref to >>> us *!!! NOT QUITE !!!* >>> >>> >>> ... so Thread1 erroneously clears the reference from Node to new >>> LoggerWeakRef that was just added by Thread2 ... >> >> Damn. I believe that you're right! I overlooked the fact that LogNode is >> reused. >> >> Locking on LogNode.context is indeed a good way of solving the issue. >> The only method that we will call from within the lock is >> LogNode.context.rmoveLoggerRef(name this) - and that already requires >> a lock on LogNode.context so it would be safe. >> >> I have also double checked the places where LogNode.loggerRef is set, >> and all those places (except in dispose() so far) are already from >> within a lock on LoggerContext. >> >> I think I would prefer however to keep the 'disposed' flag - and to >> check whether LogNode.loggerRef == this before clearing it. >> >> Given that - as I said - LogNode.loggerRef is always modified >> from within a lock on LoggerContext I think the following would >> work: >> >> void dispose() { >> synchronized(this) { >> if (disposed) return; >> disposed = true; >> } >> >> final LogNode n = node; >> if (n != null) { >> synchronized (n.context) { >> n.context.removeLoggerRef(name, this); >> name = null; >> if (n.loggerRef == this) { >> n.loggerRef = null; >> } >> node = null; >> } >> } >> >> if (parentRef != null) { >> Logger parent = parentRef.get(); >> if (parent != null) { >> parent.removeChildLogger(this); >> } >> parentRef = null; // clear our weak ref to the parent Logger >> } >> } >> >> I don't think 'node' or 'parentRef' need to be volatile. >> That - said - we could still declare them volatile to make it obvious >> that the code in 'dispose()' will not see a stale value (I don't >> think it can, but having the variables volatile would make it >> obvious). >> If we reach 'dispose()' then it does mean that the LoggerWeakRef >> is no longer used - so I believe the real thing we need to guard against >> is actually modifications of the LogNode state - rather modification >> of the LoggerWeakRef state. >> Therefore I believe that the important thing is to guarantee that >> all modifications to LogNode.loggerRef happen from within a lock >> on LoggerContext. >> >> I'd also like to keep the disposed flag because it makes it immediately >> obvious that the method is processed only once (so we haven't to worry >> about making it re-entrant at every step). >> >> Would you agree with the code above? >> >> best regards, and congratulations for catching this! >> >> -- daniel >> >>> >>> >>> One way to fix this is to synchronize the clearing of node.logerRef on >>> node.context too. I would make LoggerWeakRef.node and parentRef fields >>> volatile and do the following: >>> >>> >>> final class LoggerWeakRef extends WeakReference { >>> private String name; // for >>> namedLoggers cleanup >>> private volatile LogNode node; // for loggerRef >>> cleanup >>> private volatile WeakReference parentRef; // for kids >>> cleanup >>> >>> LoggerWeakRef(Logger logger) { >>> super(logger, loggerRefQueue); >>> name = logger.getName(); // save for namedLoggers cleanup >>> } >>> >>> // dispose of this LoggerWeakRef object >>> void dispose() { >>> LogNode node = this.node; >>> if (node != null) { >>> synchronized (node.context) { >>> node = this.node; // double-checked locking >>> if (node != null) { >>> // if we have a LogNode, then we were a named >>> Logger >>> // so clear namedLoggers weak ref to us >>> node.context.removeLoggerRef(name, this); >>> name = null; // clear our ref to the >>> Logger's name >>> >>> node.loggerRef = null; // clear LogNode's >>> weak >>> ref to us >>> this.node = null; // clear our ref to >>> LogNode >>> } >>> } >>> } >>> >>> WeakReference parentRef = this.parentRef; >>> if (parentRef != null) { >>> // this LoggerWeakRef has or had a parent Logger >>> this.parentRef = null; // clear our weak ref to the >>> parent Logger (racy, but harmless) >>> Logger parent = parentRef.get(); >>> if (parent != null) { >>> // the parent Logger is still there so clear the >>> // parent Logger's weak ref to us >>> parent.removeChildLogger(this); >>> } >>> } >>> } >>> >>> ... >>> >>> >>> What do you think? >>> >>> That's all for today. Will check the rest of patch tomorrow. >>> >>> >>> Regards, Peter >>> >>> >>> >>> On 11/27/2013 08:23 PM, Daniel Fuchs wrote: >>>> Hi, >>>> >>>> Please find below a webrev for: >>>> >>>> 8029281: Synchronization issues in Logger and LogManager >>>> >>> >>>> I believe this changeset will also fix JDK-8027670 and >>>> JDK-8029092 - which I have thus closed as duplicates of JDK-8029281. >>>> >>>> webrev: >>>> >>>> Now some comments on the fix: >>>> >>>> LogManager: >>>> >>>> When a logger was garbage collected, and then a new logger >>>> of the same name requested, addlocalLogger used to call >>>> LoggerContext.removeLogger to remove the stale reference >>>> and replace it by a new one. But sometime, the stale reference >>>> was still in the reference queue, which caused the *new* logger >>>> to be wrongly removed later when the reference queue was drained. >>>> >>>> LogManager was also missing some synchronization for its 'props' >>>> variable. >>>> >>>> Logger: >>>> >>>> userBundle & resourceBundleName were sometimes accessed within >>>> a synchronized block, and sometimes without. In particular the >>>> getters were not synchronized, which could cause race conditions >>>> because an other thread could see inconsistent data. >>>> >>>> I also had to refactor the two methods getEffectiveResourceBundle() >>>> and getResourceBundleName() into a single method. >>>> The code there might be a bit more difficult to follow, >>>> because I made sure it preserved the former behavior wrt to >>>> what will be set in the LogRecord in doLog(). >>>> >>>> Tests: >>>> >>>> The new TestLoggerBundleSync.java has been great to test >>>> the issues above in both Logger & LogManager (it detected >>>> the drainLoggerRefQueueBounded issue). >>>> >>>> Since I had to touch at drainLoggerRefQueueBounded to make >>>> TestLoggerBundleSync.java pass I also threw in a >>>> TestLogConfigurationDeadLock.java to make sure I hadn't introduced >>>> any new deadlock (and it detected the lack of synchronization >>>> in LogManager.props). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> >>> >> > From shanliang.jiang at oracle.com Tue Dec 3 07:53:46 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Tue, 03 Dec 2013 07:53:46 +0000 Subject: hg: jdk8/tl/jdk: 8029063: test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds Message-ID: <20131203075435.DCDC1629B0@hg.openjdk.java.net> Changeset: c11553506228 Author: sjiang Date: 2013-12-03 08:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c11553506228 8029063: test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds Reviewed-by: alanb, dfuchs - test/com/sun/jmx/snmp/NoInfoLeakTest.java From peter.levart at gmail.com Tue Dec 3 08:51:56 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Dec 2013 09:51:56 +0100 Subject: Theoretical data race on java.util.logging.Handler.sealed Message-ID: <529D9BAC.1020904@gmail.com> Hi, While browsing the code of java.util.logging.Handler, I noticed a theoretical possibility that a security check in a j.u.l.StreamHandler be circumvented using a data race. There is a plain boolean instance field 'sealed' in j.u.l.Handler that is pre-initialized to 'true' in field initializer. StreamHandler sublcass' constructors overwrite this value with 'false' at the beginning, then issue some operations which circumvent security checks, and finally they reset the 'sealed' value back to 'true' at the end. If a reference to an instance of StreamHandler or subclass is passed to some thread without synchronization via data-race, this thread can see 'true' or 'false' as the possible values of 'sealed' variable, thus it is possible to circumvent security checks. One possibility to fix this is moving the field to StreamHandler and making it final: http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/ Just making the field volatile might not work. There is an ongoing debate on concurrency-interest which suggests that volatile fields are not exceptional in constructors like final fields are... Regards, Peter From peter.levart at gmail.com Tue Dec 3 09:44:40 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Dec 2013 10:44:40 +0100 Subject: Theoretical data race on java.util.logging.Handler.sealed In-Reply-To: <529D9BAC.1020904@gmail.com> References: <529D9BAC.1020904@gmail.com> Message-ID: <529DA808.7070009@gmail.com> On 12/03/2013 09:51 AM, Peter Levart wrote: > Hi, > > While browsing the code of java.util.logging.Handler, I noticed a > theoretical possibility that a security check in a j.u.l.StreamHandler > be circumvented using a data race. > > There is a plain boolean instance field 'sealed' in j.u.l.Handler that > is pre-initialized to 'true' in field initializer. StreamHandler > sublcass' constructors overwrite this value with 'false' at the > beginning, then issue some operations which circumvent security > checks, and finally they reset the 'sealed' value back to 'true' at > the end. > > If a reference to an instance of StreamHandler or subclass is passed > to some thread without synchronization via data-race, this thread can > see 'true' or 'false' as the possible values of 'sealed' variable, > thus it is possible to circumvent security checks. > > One possibility to fix this is moving the field to StreamHandler and > making it final: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/ > > Just making the field volatile might not work. There is an ongoing > debate on concurrency-interest which suggests that volatile fields are > not exceptional in constructors like final fields are... > > > Regards, Peter > The proposed patch is not complete. There are several subclasses of StreamHandler in the java.util.logging package that also need a way to bypass security checks for some operations in their constructors. So here's the updated webrev which updates them with the same code as StreamHandler. This means that there are two copies of 'sealed' flag in object of type ConsoleHandler, for example, but only the one declared in ConsoleHandler is relevant for governing access checks: http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.02/ Before filing the bug, I'm asking the list whether this can be considered a bug... Regards, Peter From peter.levart at gmail.com Tue Dec 3 12:06:36 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Dec 2013 13:06:36 +0100 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <5298F3CE.6000003@oracle.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> <5298F3CE.6000003@oracle.com> Message-ID: <529DC94C.20300@gmail.com> On 11/29/2013 09:06 PM, Ivan Gerasimov wrote: > Thank you Alan for the reply! > > On 29.11.2013 21:03, Alan Bateman wrote: >> On 19/11/2013 17:58, Ivan Gerasimov wrote: >>> Hello all! >>> >>> Would you please help review a fix for the bug? >>> https://bugs.openjdk.java.net/browse/JDK-6968459 >>> >>> It was reported that creating new InitialLdapContext() can fail with >>> "javax.naming.NamingException: LDAP response read timed out, timeout >>> used:30000ms", even though the specified timeout hadn't been elapsed. >>> >>> The fix was provided by the filer of the bug some time ago. >>> Here's the webrev with this fix: >>> http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ >> >> I haven't seen any replies to this but I've cc'ed Vinnie and Xuelei >> as they are more familiar with this area. >> >> If I understand correctly then the issue is that the timeout handling >> doesn't take account of wakeups when aren't any BerDecoders to >> dequeue. The changes mean it will retry the wait with a decreasing >> timeout until a reply is received or the timeout elapses. That seems >> reasonable, assuming the time doesn't change :-) You might find the >> code is a bit clearer if you have a "remaining" time as that would >> allow you get rid of timedOut, timeOut and endTime. >> > I modified the patch in the way you suggest. > http://cr.openjdk.java.net/~igerasim/6968459/1/webrev/ > > The timeOut variable now holds the remaining time. > If the system time had changed back, we start counting from the > beginning. > If it had changed forward, we have no way to catch it and the timeout > gets elapsed earlier. > >> I see the patch doesn't come with a test. Is there any test >> infrastructure for testing LDAP without require a complete server? >> > I didn't find anything like that, that's why I set 'noreg-hard' label. > > Sincerely yours, > Ivan > > >> -Alan. >> >> > Hi Ivan, From quick look I notice a danger that Connection.readReply() pauses (for the timeOut time) in spite of the fact that a reply is ready and enqueued before waiting. Imagine a situation where the 1st try of obtaining result returns null: 450 // Get the reply if it is already available. 451 BerDecoder rber = ldr.getReplyBer(); ...after that, but before reaching the following lines: 471 synchronized (ldr) { 472 ldr.wait(timeOut); 473 } The "other" thread enqueues a reply (LdapRequest.addReplyBer()) because the code in readReply() is executing without holding a lock on "ldr". When "this" thread (executing readReply()) finally enters synchronized block and waits, it will wait until wait() times out or another reply is enqueued which will issue another notify(). This can lead to unnecessary pauses. Old code does not exhibit this problem, because it re-checks the readiness of a reply immediately after entering the synchronized block. Regards, Peter From Alan.Bateman at oracle.com Tue Dec 3 13:57:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Dec 2013 13:57:40 +0000 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <529D007E.80801@oracle.com> References: <529535C7.8090403@oracle.com> <5295DFBB.1070008@oracle.com> <529D007E.80801@oracle.com> Message-ID: <529DE354.8060303@oracle.com> On 02/12/2013 21:49, Mandy Chung wrote: > On 11/27/13 4:04 AM, Alan Bateman wrote: >> On 26/11/2013 23:59, Mandy Chung wrote: >>> This is a simple patch that adds a new jdeps -jdkinternals option to >>> make it easier for developers to find dependencies on the JDK >>> internal APIs: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ >> This looks good (and I can't think of a better name for the option). >> Do you think this needs a test as otherwise this option will not be >> exercised? > > Here is the updated webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.01/ > > I added the new test cases. This also updates -v to include the from > class in the o and the verbose mode prints more information. Thanks for adding the test. It all looks good now. -Alan. From ivan.gerasimov at oracle.com Tue Dec 3 14:35:32 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 03 Dec 2013 18:35:32 +0400 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <529DC94C.20300@gmail.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> <5298F3CE.6000003@oracle.com> <529DC94C.20300@gmail.com> Message-ID: <529DEC34.3010309@oracle.com> Hi Peter! Thank you for your review! You are right, the patch changed the behavior of the code. I've reverted back all the unnecessary changes. This should minimize the risk. I've also made another correction: After decrementing the remaining timeOut, the startTime should be set to currTime. Would you please help review the updated webrev: http://cr.openjdk.java.net/~igerasim/6968459/2/webrev/ Sincerely yours, Ivan > > From quick look I notice a danger that Connection.readReply() pauses > (for the timeOut time) in spite of the fact that a reply is ready and > enqueued before waiting. > > Imagine a situation where the 1st try of obtaining result returns null: > > 450 // Get the reply if it is already available. > 451 BerDecoder rber = ldr.getReplyBer(); > > > ...after that, but before reaching the following lines: > > 471 synchronized (ldr) { > 472 ldr.wait(timeOut); > 473 } > > > The "other" thread enqueues a reply (LdapRequest.addReplyBer()) > because the code in readReply() is executing without holding a lock on > "ldr". When "this" thread (executing readReply()) finally enters > synchronized block and waits, it will wait until wait() times out or > another reply is enqueued which will issue another notify(). This can > lead to unnecessary pauses. Old code does not exhibit this problem, > because it re-checks the readiness of a reply immediately after > entering the synchronized block. > > > Regards, Peter > > > From vincent.x.ryan at oracle.com Tue Dec 3 14:51:28 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 3 Dec 2013 14:51:28 +0000 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <529DEC34.3010309@oracle.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> <5298F3CE.6000003@oracle.com> <529DC94C.20300@gmail.com> <529DEC34.3010309@oracle.com> Message-ID: <1E81B1BC-4603-4F0F-90C0-FDE232E17934@oracle.com> Hello Ivan, Thanks for the updated patch. I would like to see a testcase along with this fix, since it is modifying a critical component of the LDAP client code. An LDAP server may not even be required in order to exercise the timeouts. Thanks. On 3 Dec 2013, at 14:35, Ivan Gerasimov wrote: > Hi Peter! > > Thank you for your review! > > You are right, the patch changed the behavior of the code. > I've reverted back all the unnecessary changes. This should minimize the risk. > > I've also made another correction: After decrementing the remaining timeOut, the startTime should be set to currTime. > > Would you please help review the updated webrev: > http://cr.openjdk.java.net/~igerasim/6968459/2/webrev/ > > Sincerely yours, > Ivan > >> >> From quick look I notice a danger that Connection.readReply() pauses (for the timeOut time) in spite of the fact that a reply is ready and enqueued before waiting. >> >> Imagine a situation where the 1st try of obtaining result returns null: >> >> 450 // Get the reply if it is already available. >> 451 BerDecoder rber = ldr.getReplyBer(); >> >> >> ...after that, but before reaching the following lines: >> >> 471 synchronized (ldr) { >> 472 ldr.wait(timeOut); >> 473 } >> >> >> The "other" thread enqueues a reply (LdapRequest.addReplyBer()) because the code in readReply() is executing without holding a lock on "ldr". When "this" thread (executing readReply()) finally enters synchronized block and waits, it will wait until wait() times out or another reply is enqueued which will issue another notify(). This can lead to unnecessary pauses. Old code does not exhibit this problem, because it re-checks the readiness of a reply immediately after entering the synchronized block. >> >> >> Regards, Peter >> >> >> > From peter.levart at gmail.com Tue Dec 3 16:05:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Dec 2013 17:05:31 +0100 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <529DEC34.3010309@oracle.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> <5298F3CE.6000003@oracle.com> <529DC94C.20300@gmail.com> <529DEC34.3010309@oracle.com> Message-ID: <529E014B.6040602@gmail.com> On 12/03/2013 03:35 PM, Ivan Gerasimov wrote: > Hi Peter! > > Thank you for your review! > > You are right, the patch changed the behavior of the code. > I've reverted back all the unnecessary changes. This should minimize > the risk. > > I've also made another correction: After decrementing the remaining > timeOut, the startTime should be set to currTime. > > Would you please help review the updated webrev: > http://cr.openjdk.java.net/~igerasim/6968459/2/webrev/ > > Sincerely yours, > Ivan Hi Ivan, That's better. You could move the initial request for ldr.getReplyBer() (line 447) out of while loop, since it is not needed in the loop (all further ldr.getReplyBer() calls in loop are performed in synchronized block already - line 465). "else { break; }" (line 469) is not needed in that case. I would also make timeOut variable long to avoid overflows. Simplified logic could look like this: BerDecoder readReply(LdapRequest ldr) throws IOException, NamingException { long timeOut = (readTimeout > 0) ? readTimeout : 15 * 1000; // Default read timeout of 15 sec long currTime = System.currentTimeMillis(); BerDecoder rber = ldr.getReplyBer(); while (rber == null && timeOut > 0L) { long startTime = currTime; // If socket closed, don't even try synchronized (this) { if (sock == null) { throw new ServiceUnavailableException(host + ":" + port + "; socket closed"); } } synchronized (ldr) { // check if condition has changed since our last check rber = ldr.getReplyBer(); if (rber == null) { try { ldr.wait(timeOut); } catch (InterruptedException ex) { throw new InterruptedNamingException( "Interrupted during LDAP operation"); } } } currTime = System.currentTimeMillis(); if (startTime < currTime) { timeOut -= (currTime - startTime); } // else system time must have changed backwards (or not at all) } if (rber == null && readTimeout > 0) { removeRequest(ldr); throw new NamingException("LDAP response read timed out, timeout used:" + readTimeout + "ms." ); } return rber; } What do you think? Regards, Peter > >> >> From quick look I notice a danger that Connection.readReply() pauses >> (for the timeOut time) in spite of the fact that a reply is ready and >> enqueued before waiting. >> >> Imagine a situation where the 1st try of obtaining result returns null: >> >> 450 // Get the reply if it is already available. >> 451 BerDecoder rber = ldr.getReplyBer(); >> >> >> ...after that, but before reaching the following lines: >> >> 471 synchronized (ldr) { >> 472 ldr.wait(timeOut); >> 473 } >> >> >> The "other" thread enqueues a reply (LdapRequest.addReplyBer()) >> because the code in readReply() is executing without holding a lock >> on "ldr". When "this" thread (executing readReply()) finally enters >> synchronized block and waits, it will wait until wait() times out or >> another reply is enqueued which will issue another notify(). This can >> lead to unnecessary pauses. Old code does not exhibit this problem, >> because it re-checks the readiness of a reply immediately after >> entering the synchronized block. >> >> >> Regards, Peter >> >> >> > From michael.x.mcmahon at oracle.com Tue Dec 3 17:30:56 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 03 Dec 2013 17:30:56 +0000 Subject: hg: jdk8/tl/jdk: 8029127: Redirected POST request throws IllegalStateException on HttpURLConnection.getInputStream Message-ID: <20131203173114.21894629DD@hg.openjdk.java.net> Changeset: e01c6e0bf8ae Author: michaelm Date: 2013-12-03 17:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e01c6e0bf8ae 8029127: Redirected POST request throws IllegalStateException on HttpURLConnection.getInputStream Reviewed-by: alanb, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/RedirectOnPost.java From joe.darcy at oracle.com Tue Dec 3 17:49:23 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Dec 2013 09:49:23 -0800 Subject: JDK 8 RFR of javax.script doclint fixes Message-ID: <529E19A3.4080709@oracle.com> Hello, Please review the patch before which addresses a handful of doclint issues in javax.script. Thanks, -Joe diff -r c11553506228 src/share/classes/javax/script/ScriptEngineFactory.java --- a/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 03 08:53:23 2013 +0100 +++ b/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 03 09:48:11 2013 -0800 @@ -144,7 +144,7 @@ * Returns a String which can be used to invoke a method of a Java object using the syntax * of the supported scripting language. For instance, an implementation for a Javascript * engine might be; - *

+ * * 

{@code
       * public String getMethodCallSyntax(String obj,
       *                                   String m, String... args) {
@@ -180,7 +180,7 @@
       * Returns a String that can be used as a statement to display the 
specified String  using
       * the syntax of the supported scripting language.  For instance, 
the implementation for a Perl
       * engine might be;
-     * 

+     *
       * 

       * public String getOutputStatement(String toDisplay) {
       *      return "print(" + toDisplay + ")";
@@ -198,7 +198,7 @@
      /**
       * Returns a valid scripting language executable program with 
given statements.
       * For instance an implementation for a PHP engine might be:
-     * 

+     *
       * 
{@code
       * public String getProgram(String... statements) {
       *      String retval = "
References: <529E19A3.4080709@oracle.com>
Message-ID: <11977664-0D4C-4A1B-8D93-5BCA4CE3F77B@oracle.com>

Looks fine to me Joe.

-Chris.

On 3 Dec 2013, at 17:49, Joe Darcy wrote:

> Hello,
> 
> Please review the patch before which addresses a handful of doclint issues in javax.script.
> 
> Thanks,
> 
> -Joe
> 
> diff -r c11553506228 src/share/classes/javax/script/ScriptEngineFactory.java
> --- a/src/share/classes/javax/script/ScriptEngineFactory.java    Tue Dec 03 08:53:23 2013 +0100
> +++ b/src/share/classes/javax/script/ScriptEngineFactory.java    Tue Dec 03 09:48:11 2013 -0800
> @@ -144,7 +144,7 @@
>      * Returns a String which can be used to invoke a method of a Java object using the syntax
>      * of the supported scripting language.  For instance, an implementation for a Javascript
>      * engine might be;
> -     * 

> +     *
>      * 
{@code
>      * public String getMethodCallSyntax(String obj,
>      *                                   String m, String... args) {
> @@ -180,7 +180,7 @@
>      * Returns a String that can be used as a statement to display the specified String  using
>      * the syntax of the supported scripting language.  For instance, the implementation for a Perl
>      * engine might be;
> -     * 

> +     *
>      * 

>      * public String getOutputStatement(String toDisplay) {
>      *      return "print(" + toDisplay + ")";
> @@ -198,7 +198,7 @@
>     /**
>      * Returns a valid scripting language executable program with given statements.
>      * For instance an implementation for a PHP engine might be:
> -     * 

> +     *
>      * 
{@code
>      * public String getProgram(String... statements) {
>      *      String retval = " 



From mike.duigou at oracle.com  Tue Dec  3 17:53:19 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 09:53:19 -0800
Subject: JDK 8 RFR of javax.script doclint fixes
In-Reply-To: <529E19A3.4080709@oracle.com>
References: <529E19A3.4080709@oracle.com>
Message-ID: 

Approved.

On Dec 3 2013, at 09:49 , Joe Darcy  wrote:

> Hello,
> 
> Please review the patch before which addresses a handful of doclint issues in javax.script.
> 
> Thanks,
> 
> -Joe
> 
> diff -r c11553506228 src/share/classes/javax/script/ScriptEngineFactory.java
> --- a/src/share/classes/javax/script/ScriptEngineFactory.java    Tue Dec 03 08:53:23 2013 +0100
> +++ b/src/share/classes/javax/script/ScriptEngineFactory.java    Tue Dec 03 09:48:11 2013 -0800
> @@ -144,7 +144,7 @@
>      * Returns a String which can be used to invoke a method of a Java object using the syntax
>      * of the supported scripting language.  For instance, an implementation for a Javascript
>      * engine might be;
> -     * 

> +     *
>      * 
{@code
>      * public String getMethodCallSyntax(String obj,
>      *                                   String m, String... args) {
> @@ -180,7 +180,7 @@
>      * Returns a String that can be used as a statement to display the specified String  using
>      * the syntax of the supported scripting language.  For instance, the implementation for a Perl
>      * engine might be;
> -     * 

> +     *
>      * 

>      * public String getOutputStatement(String toDisplay) {
>      *      return "print(" + toDisplay + ")";
> @@ -198,7 +198,7 @@
>     /**
>      * Returns a valid scripting language executable program with given statements.
>      * For instance an implementation for a PHP engine might be:
> -     * 

> +     *
>      * 
{@code
>      * public String getProgram(String... statements) {
>      *      String retval = " 



From roger.riggs at oracle.com  Tue Dec  3 17:55:39 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 03 Dec 2013 12:55:39 -0500
Subject: JDK 8 RFR of javax.script doclint fixes
In-Reply-To: <529E19A3.4080709@oracle.com>
References: <529E19A3.4080709@oracle.com>
Message-ID: <529E1B1B.1050708@oracle.com>

Hi Joe,

looks fine,

Not a reviewer, Roger

On 12/3/2013 12:49 PM, Joe Darcy wrote:
> Hello,
>
> Please review the patch before which addresses a handful of doclint 
> issues in javax.script.
>
> Thanks,
>
> -Joe
>
> diff -r c11553506228 
> src/share/classes/javax/script/ScriptEngineFactory.java
> --- a/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 
> 03 08:53:23 2013 +0100
> +++ b/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 
> 03 09:48:11 2013 -0800
> @@ -144,7 +144,7 @@
>       * Returns a String which can be used to invoke a method of a 
> Java object using the syntax
>       * of the supported scripting language.  For instance, an 
> implementation for a Javascript
>       * engine might be;
> -     * 

> +     *
>       * 
{@code
>       * public String getMethodCallSyntax(String obj,
>       *                                   String m, String... args) {
> @@ -180,7 +180,7 @@
>       * Returns a String that can be used as a statement to display 
> the specified String  using
>       * the syntax of the supported scripting language.  For instance, 
> the implementation for a Perl
>       * engine might be;
> -     * 

> +     *
>       * 

>       * public String getOutputStatement(String toDisplay) {
>       *      return "print(" + toDisplay + ")";
> @@ -198,7 +198,7 @@
>      /**
>       * Returns a valid scripting language executable program with 
> given statements.
>       * For instance an implementation for a PHP engine might be:
> -     * 

> +     *
>       * 
{@code
>       * public String getProgram(String... statements) {
>       *      String retval = "



From roger.riggs at oracle.com  Tue Dec  3 17:57:01 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 03 Dec 2013 12:57:01 -0500
Subject: JDK 8 RFR of javax.script doclint fixes
In-Reply-To: <529E1B1B.1050708@oracle.com>
References: <529E19A3.4080709@oracle.com> <529E1B1B.1050708@oracle.com>
Message-ID: <529E1B6D.9070204@oracle.com>

Hi,

Not specific to your change, but the previous sentences end in ";" in 
some cases and ":" in others.
I thing ":" colon is more natural.

Roger

On 12/3/2013 12:55 PM, roger riggs wrote:
> Hi Joe,
>
> looks fine,
>
> Not a reviewer, Roger
>
> On 12/3/2013 12:49 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review the patch before which addresses a handful of doclint 
>> issues in javax.script.
>>
>> Thanks,
>>
>> -Joe
>>
>> diff -r c11553506228 
>> src/share/classes/javax/script/ScriptEngineFactory.java
>> --- a/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 
>> 03 08:53:23 2013 +0100
>> +++ b/src/share/classes/javax/script/ScriptEngineFactory.java Tue Dec 
>> 03 09:48:11 2013 -0800
>> @@ -144,7 +144,7 @@
>>       * Returns a String which can be used to invoke a method of a 
>> Java object using the syntax
>>       * of the supported scripting language.  For instance, an 
>> implementation for a Javascript
>>       * engine might be;
>> -     * 

>> +     *
>>       * 
{@code
>>       * public String getMethodCallSyntax(String obj,
>>       *                                   String m, String... args) {
>> @@ -180,7 +180,7 @@
>>       * Returns a String that can be used as a statement to display 
>> the specified String  using
>>       * the syntax of the supported scripting language.  For 
>> instance, the implementation for a Perl
>>       * engine might be;
>> -     * 

>> +     *
>>       * 

>>       * public String getOutputStatement(String toDisplay) {
>>       *      return "print(" + toDisplay + ")";
>> @@ -198,7 +198,7 @@
>>      /**
>>       * Returns a valid scripting language executable program with 
>> given statements.
>>       * For instance an implementation for a PHP engine might be:
>> -     * 

>> +     *
>>       * 
{@code
>>       * public String getProgram(String... statements) {
>>       *      String retval = ">
>



From jan.lahoda at oracle.com  Tue Dec  3 18:07:29 2013
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Tue, 03 Dec 2013 18:07:29 +0000
Subject: hg: jdk8/tl/langtools: 8028699: Compiler crash during speculative
	attribution of annotated type
Message-ID: <20131203180751.7BA5A629E2@hg.openjdk.java.net>

Changeset: a746587a1ff1
Author:    jlahoda
Date:      2013-12-03 18:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a746587a1ff1

8028699: Compiler crash during speculative attribution of annotated type
Summary: Moving the checkForDeclarationAnnotations check into Attr.TypeAnnotationsValidator
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/CheckForDeclAnnoNPE.java
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out



From joe.darcy at oracle.com  Tue Dec  3 18:07:29 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 03 Dec 2013 18:07:29 +0000
Subject: hg: jdk8/tl/jdk: 8029478: Fix more doclint issues in javax.script
Message-ID: <20131203180759.7D730629E3@hg.openjdk.java.net>

Changeset: 1c3d58caa7da
Author:    darcy
Date:      2013-12-03 10:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c3d58caa7da

8029478: Fix more doclint issues in javax.script
Reviewed-by: chegar, mduigou

! src/share/classes/javax/script/ScriptEngineFactory.java



From stuart.marks at oracle.com  Tue Dec  3 18:15:19 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Dec 2013 10:15:19 -0800
Subject: RFR: 8028757: CharSequence.subSequence improperly requires a "new"
	CharSequence be returned
Message-ID: <529E1FB7.4080502@oracle.com>

Hi all,

Please review this small change to the subSequence() method specs of 
CharSequence and String. Essentially this removes the requirement of returning a 
"new" character sequence at each call. This brings the spec in line with 
String's implementation, which will return 'this' in appropriate circumstances.

No change is necessary for the other CharSequence implementations. 
StringBuilder/Buffer still say "new" and in fact they always return new String 
objects. CharBuffer defines its exact sharing behavior. Segment returns a "new" 
Segment with a shared character array, which is (supposedly) immutable.

Diffs appended below.

Thanks,

s'marks


# HG changeset patch
# User smarks
# Date 1386094056 28800
# Node ID c15e257074e48a1927755ff48393baa8f3f3ab0e
# Parent  4d9078b1f25b72071d91acc7e1ce5bb7e91748fb
8028757: CharSequence.subSequence improperly requires a "new" CharSequence be 
returned
Reviewed-by: XXX

diff -r 4d9078b1f25b -r c15e257074e4 src/share/classes/java/lang/CharSequence.java
--- a/src/share/classes/java/lang/CharSequence.java	Tue Nov 26 14:49:55 2013 +0900
+++ b/src/share/classes/java/lang/CharSequence.java	Tue Dec 03 10:07:36 2013 -0800
@@ -87,7 +87,7 @@
      char charAt(int index);

      /**
-     * Returns a new CharSequence that is a subsequence of this 
sequence.
+     * Returns a CharSequence that is a subsequence of this sequence.
       * The subsequence starts with the char value at the 
specified index and
       * ends with the char value at index end - 1.  The 
length
       * (in chars) of the
diff -r 4d9078b1f25b -r c15e257074e4 src/share/classes/java/lang/String.java
--- a/src/share/classes/java/lang/String.java	Tue Nov 26 14:49:55 2013 +0900
+++ b/src/share/classes/java/lang/String.java	Tue Dec 03 10:07:36 2013 -0800
@@ -1958,7 +1958,7 @@
      }

      /**
-     * Returns a new character sequence that is a subsequence of this sequence.
+     * Returns a character sequence that is a subsequence of this sequence.
       *
       * 
 An invocation of this method of the form
       *


From vicente.romero at oracle.com  Tue Dec  3 18:13:44 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 03 Dec 2013 18:13:44 +0000
Subject: hg: jdk8/tl/langtools: 8029179: javac produces a compile error for
	valid boolean expressions
Message-ID: <20131203181347.2F361629E4@hg.openjdk.java.net>

Changeset: fb8c59cf26c8
Author:    vromero
Date:      2013-12-03 18:13 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb8c59cf26c8

8029179: javac produces a compile error for valid boolean expressions
Reviewed-by: jjg, jlahoda

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/T8029179/CompileErrorForValidBooleanExpTest.java



From henry.jen at oracle.com  Tue Dec  3 18:36:16 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 03 Dec 2013 10:36:16 -0800
Subject: RFR: 8029434: Spliterator of Stream returned by BufferedReader.lines()
	should have NONNULL characteristic
In-Reply-To: <529CCE7D.8000409@oracle.com>
References: <5299B881.3040702@gmail.com> <529CCE7D.8000409@oracle.com>
Message-ID: <529E24A0.9090604@oracle.com>

Hi,

Please review a small fix that add missing NONNULL characteristic and 
cleanup in javadoc.

Thanks Anthony Vanelverdinghe for reporting of this bug.

http://cr.openjdk.java.net/~henryjen/tl/8029434/0/webrev/

Cheers,
Henry


From daniel.fuchs at oracle.com  Tue Dec  3 18:57:06 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 03 Dec 2013 19:57:06 +0100
Subject: 8029281: Synchronization issues in Logger and LogManager
In-Reply-To: <529D8A10.6090609@gmail.com>
References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com>
	<529752AB.2050101@oracle.com> <52987D5D.6070800@oracle.com>
	<529D8A10.6090609@gmail.com>
Message-ID: <529E2982.9040601@oracle.com>

On 12/3/13 8:36 AM, Peter Levart wrote:
> Hi Daniel,
>
> 1st sorry for the delay. I promised looking at the patch, but was then
> distracted by other things. I think that synchronization in LogManager
> is correct now. The fact that Mandy thinks so is also reassuring.

Yes - that's usually a good sign :-)

> I wonder if calling LoggerWeakRef.dispose() from
> LoggerContext.addLocalLoger() is needed now that you check the
> LogNode.loggerRef before clearing in LoggerWeakRef.dispose():

Yes - we could probably call dispose() only when draining the
queue - but I still have the feeling that calling it early
is better. It makes sure that everything is properly cleaned-up
before we modify it.

I also like that we now have a single entry point - 'dispose()' - to
clean up after a gc'ed logger rather than doing half of the job now
and leaving the other half for later (and trusting that the later
code will not do anything stupid).

Thank you again for your reviews and feedback - they are very
helpful!

-- daniel

>
>                      if (n.loggerRef == this) {
>                          n.loggerRef = null;  // clear LogNode's weak
> ref to us
>                      }
>
>
> The LoggerContext.addLocalLoger() will already overwrite the
> namedLoggers Hashtable entry for the logger's name with new LoggerWeakRef:
>
>              namedLoggers.put(name, ref);
>
> ...and it will already overwrite the LogNode.loggerRef with new
> LoggerWeakRef:
>
>              // Find the new node and its parent.
>              LogNode node = getNode(name);
>              node.loggerRef = ref;
>
> So the only effect of calling LoggerWeakRef.dispose() from
> LoggerContext.addLocalLoger() is a more prompt unlinking of
> LoggerWeakRef child, which has already been cleared but not yet
> disposed(), from parent logger. This will eventually happen in a call to
> LogManager.drainLoggerRefQueueBounded(), called from public
> LogManager.addLogger(), which is the only entry point to
> LoggerContext.addLocalLoger(). But it's not wrong as it is now when you
> also ensure more prompt unlinking of cleared LoggerWeakRef and code is
> more uniform and less fragile then it would be if you created and called
> a hypothetical disposeFromParent() which only took care of unlinking
> from parent logger...
>
> Regards, Peter
>
>
> On 11/29/2013 12:41 PM, Daniel Fuchs wrote:
>> Hi,
>>
>> Here is a new revision that includes Peter's findings.
>> Thanks again for that Peter!
>>
>> 
>>
>> It has passed all jdk_core tests and running the new tests
>> in a loop hasn't triggered any of the issues that appeared
>> before the fix.
>>
>> -- daniel
>>
>> On 11/28/13 3:26 PM, Daniel Fuchs wrote:
>>> On 11/27/13 10:34 PM, Peter Levart wrote:
>>>> Hi Daniel,
>>>>
>>>> I have started looking at the LogManager change first, and here's the
>>>> 1st race I found...
>>>
>>> Hi Peter,
>>>
>>> Thanks a lot for your feedback! see below...
>>>
>>>>   The new method LoggerWeakRef.dispose() can be called from 3 places:
>>>>
>>>> - LoggerContext.addLocalLogger
>>>> - LoggerContext.findLogger
>>>> - LogManager.drainLoggerRefQueueBounded which is called from public
>>>> method LogManager.addLogger
>>>>
>>>> The 1st and 2nd are guarded by LoggerContext.this lock, but the 3rd is
>>>> unguarded.
>>>>
>>>> What can happen is the following:
>>>>
>>>> Thread1:
>>>>      LogManager.addLogger(someLogger)
>>>>          LogManager.drainLoggerRefQueueBounded() // finds some enqueued
>>>> LoggerWeakRef for name == 'X.Y' and...
>>>>              LoggerWeakRef.dispose() // this is 1st call to dispose,
>>>> so...
>>>>                  synchronized (LoggerWeakRef.this) {
>>>>                     disposed = true;
>>>>                  }
>>>>
>>>> ---context switch---
>>>>
>>>> Thread2:
>>>>          LogManager.addLogger(logger{name=='X.Y'})
>>>>              LogManager.drainLoggerRefQueueBounded()  // no enqueued
>>>> refs...
>>>>              LoggerContext.addLocalLogger(logger{name=='X.Y'}, true)
>>>>                  LoggerWeakRef ref = namedLoggers.get(name); // returns
>>>> a non-null ref ('X.Y' still points to a cleared weak ref)
>>>>                  if (ref.get() == null) {
>>>>                      ref.dispose(); // this is a 2nd call to this ref,
>>>> so it returns quickly
>>>>                  }
>>>>                  // ... namedLoggers gets new entry, etc...
>>>>                  LogNode node = getNode(name); // get node for 'X.Y'
>>>> *                node.loggerRef = ref;*
>>>>
>>>> ---context switch---
>>>>
>>>> Thread1: (still in LoggerWeakRef.dispose())
>>>>              if (node != null) {
>>>> *                node.loggerRef = null;*  // clear LogNode's weak
>>>> ref to
>>>> us *!!! NOT QUITE !!!*
>>>>
>>>>
>>>> ... so Thread1 erroneously clears the reference from Node to new
>>>> LoggerWeakRef that was just added by Thread2 ...
>>>
>>> Damn. I believe that you're right! I overlooked the fact that LogNode is
>>> reused.
>>>
>>> Locking on LogNode.context is indeed a good way of solving the issue.
>>> The only method that we will call from within the lock is
>>> LogNode.context.rmoveLoggerRef(name this) - and that already requires
>>> a lock on LogNode.context so it would be safe.
>>>
>>> I have also double checked the places where LogNode.loggerRef is set,
>>> and all those places (except in dispose() so far) are already from
>>> within a lock on LoggerContext.
>>>
>>> I think I would prefer however to keep the 'disposed' flag - and to
>>> check whether LogNode.loggerRef == this before clearing it.
>>>
>>> Given that - as I said - LogNode.loggerRef is always modified
>>> from within a lock on LoggerContext I think the following would
>>> work:
>>>
>>> void dispose() {
>>>      synchronized(this) {
>>>          if (disposed) return;
>>>          disposed = true;
>>>      }
>>>
>>>      final LogNode n = node;
>>>      if (n != null) {
>>>          synchronized (n.context) {
>>>              n.context.removeLoggerRef(name, this);
>>>              name = null;
>>>              if (n.loggerRef == this) {
>>>                  n.loggerRef = null;
>>>              }
>>>              node = null;
>>>           }
>>>      }
>>>
>>>      if (parentRef != null) {
>>>          Logger parent = parentRef.get();
>>>          if (parent != null) {
>>>              parent.removeChildLogger(this);
>>>          }
>>>          parentRef = null;  // clear our weak ref to the parent Logger
>>>      }
>>> }
>>>
>>> I don't think 'node' or 'parentRef' need to be volatile.
>>> That - said - we could still declare them volatile to make it obvious
>>> that the code in 'dispose()' will not see a stale value (I don't
>>> think it can, but having the variables volatile would make it
>>> obvious).
>>> If we reach 'dispose()' then it does mean that the LoggerWeakRef
>>> is no longer used - so I believe the real thing we need to guard against
>>> is actually modifications of the LogNode state - rather modification
>>> of the LoggerWeakRef  state.
>>> Therefore I believe that the important thing is to guarantee that
>>> all modifications to LogNode.loggerRef happen from within a lock
>>> on LoggerContext.
>>>
>>> I'd also like to keep the disposed flag because it makes it immediately
>>> obvious that the method is processed only once (so we haven't to worry
>>> about making it re-entrant at every step).
>>>
>>> Would you agree with the code above?
>>>
>>> best regards, and congratulations for catching this!
>>>
>>> -- daniel
>>>
>>>>
>>>>
>>>> One way to fix this is to synchronize the clearing of node.logerRef on
>>>> node.context too. I would make LoggerWeakRef.node and parentRef fields
>>>> volatile and do the following:
>>>>
>>>>
>>>>      final class LoggerWeakRef extends WeakReference {
>>>>          private String                         name; // for
>>>> namedLoggers cleanup
>>>>          private volatile LogNode               node; // for loggerRef
>>>> cleanup
>>>>          private volatile WeakReference parentRef;  // for kids
>>>> cleanup
>>>>
>>>>          LoggerWeakRef(Logger logger) {
>>>>              super(logger, loggerRefQueue);
>>>>              name = logger.getName();  // save for namedLoggers cleanup
>>>>          }
>>>>
>>>>          // dispose of this LoggerWeakRef object
>>>>          void dispose() {
>>>>              LogNode node = this.node;
>>>>              if (node != null) {
>>>>                  synchronized (node.context) {
>>>>                      node = this.node; // double-checked locking
>>>>                      if (node != null) {
>>>>                          // if we have a LogNode, then we were a named
>>>> Logger
>>>>                          // so clear namedLoggers weak ref to us
>>>>                          node.context.removeLoggerRef(name, this);
>>>>                          name = null;  // clear our ref to the
>>>> Logger's name
>>>>
>>>>                          node.loggerRef = null;  // clear LogNode's
>>>> weak
>>>> ref to us
>>>>                          this.node = null;       // clear our ref to
>>>> LogNode
>>>>                      }
>>>>                  }
>>>>              }
>>>>
>>>>              WeakReference parentRef = this.parentRef;
>>>>              if (parentRef != null) {
>>>>                  // this LoggerWeakRef has or had a parent Logger
>>>>                  this.parentRef = null;  // clear our weak ref to the
>>>> parent Logger (racy, but harmless)
>>>>                  Logger parent = parentRef.get();
>>>>                  if (parent != null) {
>>>>                      // the parent Logger is still there so clear the
>>>>                      // parent Logger's weak ref to us
>>>>                      parent.removeChildLogger(this);
>>>>                  }
>>>>              }
>>>>          }
>>>>
>>>> ...
>>>>
>>>>
>>>> What do you think?
>>>>
>>>> That's all for today. Will check the rest of patch tomorrow.
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>>
>>>> On 11/27/2013 08:23 PM, Daniel Fuchs wrote:
>>>>> Hi,
>>>>>
>>>>> Please find below a webrev for:
>>>>>
>>>>> 8029281: Synchronization issues in Logger and LogManager
>>>>> >>>>
>>>>> I believe this changeset will also fix JDK-8027670 and
>>>>> JDK-8029092 - which I have thus closed as duplicates of JDK-8029281.
>>>>>
>>>>> webrev: 
>>>>>
>>>>> Now some comments on the fix:
>>>>>
>>>>> LogManager:
>>>>>
>>>>> When a logger was garbage collected, and then a new logger
>>>>> of the same name requested, addlocalLogger used to call
>>>>> LoggerContext.removeLogger to remove the stale reference
>>>>> and replace it by a new one. But sometime, the stale reference
>>>>> was still in the reference queue, which caused the *new* logger
>>>>> to be wrongly removed later when the reference queue was drained.
>>>>>
>>>>> LogManager was also missing some synchronization for its 'props'
>>>>> variable.
>>>>>
>>>>> Logger:
>>>>>
>>>>> userBundle & resourceBundleName were sometimes accessed within
>>>>> a synchronized block, and sometimes without. In particular the
>>>>> getters were not synchronized, which could cause race conditions
>>>>> because an other thread could see inconsistent data.
>>>>>
>>>>> I also had to refactor the two methods getEffectiveResourceBundle()
>>>>> and getResourceBundleName() into a single method.
>>>>> The code there might be a bit more difficult to follow,
>>>>> because I made sure it preserved the former behavior wrt to
>>>>> what will be set in the LogRecord in doLog().
>>>>>
>>>>> Tests:
>>>>>
>>>>> The new TestLoggerBundleSync.java has been great to test
>>>>> the issues above in both Logger & LogManager (it detected
>>>>> the drainLoggerRefQueueBounded issue).
>>>>>
>>>>> Since I had to touch at drainLoggerRefQueueBounded to make
>>>>> TestLoggerBundleSync.java pass I also threw in a
>>>>> TestLogConfigurationDeadLock.java to make sure I hadn't introduced
>>>>> any new deadlock (and it detected the lack of synchronization
>>>>> in LogManager.props).
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From daniel.fuchs at oracle.com  Tue Dec  3 18:57:31 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 03 Dec 2013 19:57:31 +0100
Subject: 8029281: Synchronization issues in Logger and LogManager
In-Reply-To: <529D2A9C.2020001@oracle.com>
References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com>
	<529752AB.2050101@oracle.com> <52987D5D.6070800@oracle.com>
	<529D2A9C.2020001@oracle.com>
Message-ID: <529E299B.3020202@oracle.com>

Hi Mandy,

I have updated the webrev taking your comments into account.



Changes are small and outlined below:

On 12/3/13 1:49 AM, Mandy Chung wrote:
> On 11/29/2013 3:41 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Here is a new revision that includes Peter's findings.
>> Thanks again for that Peter!
>>
>> 
>>
>
> LogManager.java
>     L156: make props volatile is good.
>
>     I think the reason why LoggerWeakRef.node and parentRef don't need
> to be volatile because of the synchronized block to check and set
> disposed flag that ensures that only one thread will be doing the node
> and parentRef cleanup.  I agree that the two lines should be done with
> synchronized on the LoggerContext.
>
>       node.context.removeLogger(name);
>       node.loggerRef = null;  // clear LogNode's weak ref to us
>
> I don't see anything obvious wrong with this patch.   Have you
> considered having the dispose() method simply synchronizes on
> node.context (probably need to get the LoggerContext when instantiating
> LoggerWeakRef and break dispose method into two - one for the node and
> the other for the parentRef)?    I'm not proposing to do this in JDK 8
> since we are ramping down and get a low risk fix in.   It may be
> something to revisit for jdk 9 to a cleaner version.

I believe that nulling the instance variables in LoggerWeakRef
is probably no longer needed - since we now should be calling
dispose only once - but I didn't want to change the code too
much. I agree it would be better to revisit that in 9.


> Logger.java
>     The assert this.loggerBundle == NO_RESOURCE_BUNDLE; in the Logger
> constructors doesn't seem to be needed.

OK - removed.

> Having an immutable LoggerBundle class is good to ensure the
> resourceBundleName and resourceBundle are consistent.
>
>     L1930: is lb.userBundle and lb.resourceBundleName null when getting
> to this line?  Might be better to rename setupResourceInfo to
> setResourceBundleName (that creates a LoggerBundle with a null RB). On
> the other hand,  setResourceBundle will instantiate a LoggerBundle with
> non-null rbname and RB.  It wasn't obvious to me what does what.

Right. Let's keep the old name for now. We can revisit the naming in 9.
You right that when we reach the last line lb.userBundle must be null,
otherwise we would have either returned or thrown an exception, since
lb.userBundle != null => lb.resourceBundleName != null.

Therefore I added an assert lb.userBundle == null and
replaced the call to
   LoggerBundle.get(name, lb.userBundle)
by
   LoggerBundle.get(name, null)

Hopefully it will make what happens more obvious.

> 2137             final String rbName = getResourceBundleName();
> 2138             if (!SYSTEM_LOGGER_RB_NAME.equals(rbName)
> 2139                     &&
> !SYSTEM_LOGGER_RB_NAME.equals(b.getBaseBundleName())) {
> 2140                 return LoggerBundle.get(rbName, b);
> 2141             } else {
> 2142                 return SYSTEM_BUNDLE;
> 2143             }
>
> To get to the above line, either lb.userBundle is null or
> getResourceBundle() isoverridden.  L2126 already checks that this logger
> does not associate with the system rbname.  It seems to me that the
> special case here is when the Logger subclass overrides
> getResourceBundleName() to returnSYSTEM_LOGGER_RB_NAME or override
> getResourceBundle to return the "sun.util.logging.resources.logging" RB.
> I tink that we might just simplify the above and just return
> LoggerBundle.get(rbName, b) and no need to worry about those overridden
> case which does no use to such a Logger subclass with unmatched rbname
> and RB.  Same comment applied to L2157-2165.

Ah. I'm glad to hear that. This is a great simplification.
done.

-- daniel


>
> thanks
> Mandy



From mike.duigou at oracle.com  Tue Dec  3 19:01:50 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 11:01:50 -0800
Subject: RFR: 8028757: CharSequence.subSequence improperly requires a
	"new" CharSequence be returned
In-Reply-To: <529E1FB7.4080502@oracle.com>
References: <529E1FB7.4080502@oracle.com>
Message-ID: <3B52FBF2-58D1-42A6-B4D8-20117BB85BAD@oracle.com>

The changes look OK.

The needs of mutable CharSequences to isolate the subsequence changes seems adequately handled in the mutable classes.

Mike

On Dec 3 2013, at 10:15 , Stuart Marks  wrote:

> Hi all,
> 
> Please review this small change to the subSequence() method specs of CharSequence and String. Essentially this removes the requirement of returning a "new" character sequence at each call. This brings the spec in line with String's implementation, which will return 'this' in appropriate circumstances.
> 
> No change is necessary for the other CharSequence implementations. StringBuilder/Buffer still say "new" and in fact they always return new String objects. CharBuffer defines its exact sharing behavior. Segment returns a "new" Segment with a shared character array, which is (supposedly) immutable.
> 
> Diffs appended below.
> 
> Thanks,
> 
> s'marks
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1386094056 28800
> # Node ID c15e257074e48a1927755ff48393baa8f3f3ab0e
> # Parent  4d9078b1f25b72071d91acc7e1ce5bb7e91748fb
> 8028757: CharSequence.subSequence improperly requires a "new" CharSequence be returned
> Reviewed-by: XXX
> 
> diff -r 4d9078b1f25b -r c15e257074e4 src/share/classes/java/lang/CharSequence.java
> --- a/src/share/classes/java/lang/CharSequence.java	Tue Nov 26 14:49:55 2013 +0900
> +++ b/src/share/classes/java/lang/CharSequence.java	Tue Dec 03 10:07:36 2013 -0800
> @@ -87,7 +87,7 @@
>     char charAt(int index);
> 
>     /**
> -     * Returns a new CharSequence that is a subsequence of this sequence.
> +     * Returns a CharSequence that is a subsequence of this sequence.
>      * The subsequence starts with the char value at the specified index and
>      * ends with the char value at index end - 1.  The length
>      * (in chars) of the
> diff -r 4d9078b1f25b -r c15e257074e4 src/share/classes/java/lang/String.java
> --- a/src/share/classes/java/lang/String.java	Tue Nov 26 14:49:55 2013 +0900
> +++ b/src/share/classes/java/lang/String.java	Tue Dec 03 10:07:36 2013 -0800
> @@ -1958,7 +1958,7 @@
>     }
> 
>     /**
> -     * Returns a new character sequence that is a subsequence of this sequence.
> +     * Returns a character sequence that is a subsequence of this sequence.
>      *
>      * 
 An invocation of this method of the form
>      *



From henry.jen at oracle.com  Tue Dec  3 19:44:37 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 03 Dec 2013 19:44:37 +0000
Subject: hg: jdk8/tl/jdk: 8029483: BufferedReader.lines() javadoc typo should
	be fixed
Message-ID: <20131203194451.8E040629F3@hg.openjdk.java.net>

Changeset: 1061f4d085b5
Author:    henryjen
Date:      2013-12-03 11:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1061f4d085b5

8029483: BufferedReader.lines() javadoc typo should be fixed
Reviewed-by: mduigou

! src/share/classes/java/io/BufferedReader.java



From henry.jen at oracle.com  Tue Dec  3 19:49:34 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 03 Dec 2013 11:49:34 -0800
Subject: RFR: 8029434: Spliterator of Stream returned by
	BufferedReader.lines() should have NONNULL characteristic
In-Reply-To: <77EB7336-4EDE-44C7-945A-99CB8C045B86@oracle.com>
References: <5299B881.3040702@gmail.com> <529CCE7D.8000409@oracle.com>
	<529E24A0.9090604@oracle.com>
	<77EB7336-4EDE-44C7-945A-99CB8C045B86@oracle.com>
Message-ID: <529E35CE.6010104@oracle.com>

I have separated the fix into two part,

8029434: Spliterator of Stream returned by BufferedReader.lines() should 
have NONNULL characteristic

8029483: BufferedReader.lines() javadoc typo should be fixed

So that we can at least fix the javadoc by jdk8 release if not the 
characteristic.

Cheers,
Henry

On 12/03/2013 10:52 AM, Mike Duigou wrote:
> Looks good to me.
>
> Mike
>
> On Dec 3 2013, at 10:36 , Henry Jen  wrote:
>
>> Hi,
>>
>> Please review a small fix that add missing NONNULL characteristic and cleanup in javadoc.
>>
>> Thanks Anthony Vanelverdinghe for reporting of this bug.
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8029434/0/webrev/
>>
>> Cheers,
>> Henry
>


From mike.duigou at oracle.com  Tue Dec  3 19:48:49 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 11:48:49 -0800
Subject: RFR: 8029434: Spliterator of Stream returned by
	BufferedReader.lines() should have NONNULL characteristic
In-Reply-To: <529E35CE.6010104@oracle.com>
References: <5299B881.3040702@gmail.com> <529CCE7D.8000409@oracle.com>
	<529E24A0.9090604@oracle.com>
	<77EB7336-4EDE-44C7-945A-99CB8C045B86@oracle.com>
	<529E35CE.6010104@oracle.com>
Message-ID: 

Go ahead with pushing 8029483 as no approval is required for doc only change.

Mike

On Dec 3 2013, at 11:49 , Henry Jen  wrote:

> I have separated the fix into two part,
> 
> 8029434: Spliterator of Stream returned by BufferedReader.lines() should have NONNULL characteristic
> 
> 8029483: BufferedReader.lines() javadoc typo should be fixed
> 
> So that we can at least fix the javadoc by jdk8 release if not the characteristic.
> 
> Cheers,
> Henry
> 
> On 12/03/2013 10:52 AM, Mike Duigou wrote:
>> Looks good to me.
>> 
>> Mike
>> 
>> On Dec 3 2013, at 10:36 , Henry Jen  wrote:
>> 
>>> Hi,
>>> 
>>> Please review a small fix that add missing NONNULL characteristic and cleanup in javadoc.
>>> 
>>> Thanks Anthony Vanelverdinghe for reporting of this bug.
>>> 
>>> http://cr.openjdk.java.net/~henryjen/tl/8029434/0/webrev/
>>> 
>>> Cheers,
>>> Henry
>> 



From joe.darcy at oracle.com  Tue Dec  3 19:52:40 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 03 Dec 2013 19:52:40 +0000
Subject: hg: jdk8/tl/jdk: 8029475: Fix more doclint issues in javax.security
Message-ID: <20131203195252.F1421629F4@hg.openjdk.java.net>

Changeset: cd4aabc40f72
Author:    darcy
Date:      2013-12-03 11:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd4aabc40f72

8029475: Fix more doclint issues in javax.security
Reviewed-by: juh

! src/share/classes/javax/crypto/Cipher.java
! src/share/classes/javax/crypto/CipherSpi.java
! src/share/classes/javax/crypto/KeyGenerator.java
! src/share/classes/javax/crypto/SealedObject.java
! src/share/classes/javax/net/ssl/SSLEngine.java
! src/share/classes/javax/net/ssl/SSLPermission.java
! src/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/javax/security/auth/login/LoginContext.java
! src/share/classes/javax/security/auth/x500/X500Principal.java



From Alan.Bateman at oracle.com  Tue Dec  3 20:03:14 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Dec 2013 20:03:14 +0000
Subject: RFR: 8028757: CharSequence.subSequence improperly requires a
	"new" CharSequence be returned
In-Reply-To: <529E1FB7.4080502@oracle.com>
References: <529E1FB7.4080502@oracle.com>
Message-ID: <529E3902.1080602@oracle.com>

On 03/12/2013 18:15, Stuart Marks wrote:
> Hi all,
>
> Please review this small change to the subSequence() method specs of 
> CharSequence and String. Essentially this removes the requirement of 
> returning a "new" character sequence at each call. This brings the 
> spec in line with String's implementation, which will return 'this' in 
> appropriate circumstances.
>
> No change is necessary for the other CharSequence implementations. 
> StringBuilder/Buffer still say "new" and in fact they always return 
> new String objects. CharBuffer defines its exact sharing behavior. 
> Segment returns a "new" Segment with a shared character array, which 
> is (supposedly) immutable.
Looks good and I think is the best solution for this.

-Alan


From sebastian.sickelmann at gmx.de  Tue Dec  3 20:13:06 2013
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 03 Dec 2013 21:13:06 +0100
Subject: RFR: MethodHandles.Lookup. Wrong access verification
In-Reply-To: 
References: <529CFED4.7040008@gmx.de>
	
Message-ID: <529E3B52.8000901@gmx.de>

Thanks.

I would like to add the test[1] prior to fixing it.
JDK 7 shows the same behavior.

As i am not an author of any openjdk-project but i signed the OCA some
time ago i would love to find and sponsor for this[1].

? Sebastian

Am 03.12.2013 01:08, schrieb John Rose:
> I appreciate the report and the proposed fixes.  We are looking at
> this seriously.
>
> ? John
>
> P.S.  The root issue may be an accidental inheritance of private
> methods.   I have been thinking for a while that, in the name of
> compatibility, the JVMS allows an "invokevirtual" invocation to reach
> a private method, but that this is unfortunate, since "invokespecial"
> already supplies a more specific way to get to the method.  Likewise,
> an "invokeinterface" instruction can reach a virtual method of Object,
> while "invokevirtual" gives a more specific way.  There are a number
> of odd pathways through the linkResolver, to support these extra
> combinations, that I would like to regularize or remove.  I think we
> should investigate tightening up the JVM linkage rules to avoid the
> extra corner cases.  That will probably have the effect of removing
> surprise effects like this one, as we continue to extend the JVM
> linkage rules.
>
>
> On Dec 2, 2013, at 1:42 PM, Sebastian Sickelmann
> > wrote:
>
>> Hi,
>>
>> some days ago i had written[0] that i maybe found a bug in access
>> verification in MethodHandles.Lookup.
>>
>> Now i produces webrev's for the two repos jdk and hotspot.
>>
>> In the jdk webrev [1] I implemented some additional tests.
>>
>> In the hotspot webrev [2] I tried to fix the wrong behavior. I am not
>> sure if it is the right place to fix this.
>> It is more an proof-of-concept--like--reverse-engineering-fix that
>> fixes the symptom, and i do not fully
>> understand all the things in the patched source. In fact i think that
>> we can move line 187 to 182 instead
>> of chaning line 245 in methodHandles.cpp. But as i said i do not
>> fully understand init_method_MemberName
>> and all those CallInfo::vtable_call / CallInfo::itable_call /
>> CallInfo::direct_call differences.
>>
>> Hope my works helps solving this issue. And i hope it is an issue.
>> And i hope my fix isn't breaking anything else
>> so that it was enough to test my fix against my new testcase in
>> MethodHandlesTest.testFindPrivate
>>
>> Kind regards
>> Sebastian
>>
>> [0]
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010228.html
>> [1]
>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_jdk/index.html
>> [2]
>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_hotspot/index.html
>>
>



From brian.burkhalter at oracle.com  Tue Dec  3 20:28:14 2013
From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com)
Date: Tue, 03 Dec 2013 20:28:14 +0000
Subject: hg: jdk8/tl/jdk: 8022181: Tune algorithm crossover thresholds in
	BigInteger
Message-ID: <20131203202828.AF6B2629F5@hg.openjdk.java.net>

Changeset: c138b0d33980
Author:    bpb
Date:      2013-12-03 12:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138b0d33980

8022181: Tune algorithm crossover thresholds in BigInteger
Summary: Change multiplication, squaring, division, and base conversion thresholds to values which retain performance improvement in most cases but with a a lower overall risk of regression.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java



From mandy.chung at oracle.com  Tue Dec  3 20:33:27 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 03 Dec 2013 12:33:27 -0800
Subject: 8029281: Synchronization issues in Logger and LogManager
In-Reply-To: <529E299B.3020202@oracle.com>
References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com>
	<529752AB.2050101@oracle.com> <52987D5D.6070800@oracle.com>
	<529D2A9C.2020001@oracle.com> <529E299B.3020202@oracle.com>
Message-ID: <529E4017.4050908@oracle.com>

On 12/3/2013 10:57 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> I have updated the webrev taking your comments into account.
>
> 
>

Looks much cleaner.  Thanks for the update.

Nit LogManager.java L1050: formatting - one extra space.  No need to 
generate a new webrev.

Mandy

> Changes are small and outlined below:
>
> On 12/3/13 1:49 AM, Mandy Chung wrote:
>> On 11/29/2013 3:41 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Here is a new revision that includes Peter's findings.
>>> Thanks again for that Peter!
>>>
>>> 
>>>
>>
>> LogManager.java
>>     L156: make props volatile is good.
>>
>>     I think the reason why LoggerWeakRef.node and parentRef don't need
>> to be volatile because of the synchronized block to check and set
>> disposed flag that ensures that only one thread will be doing the node
>> and parentRef cleanup.  I agree that the two lines should be done with
>> synchronized on the LoggerContext.
>>
>>       node.context.removeLogger(name);
>>       node.loggerRef = null;  // clear LogNode's weak ref to us
>>
>> I don't see anything obvious wrong with this patch.   Have you
>> considered having the dispose() method simply synchronizes on
>> node.context (probably need to get the LoggerContext when instantiating
>> LoggerWeakRef and break dispose method into two - one for the node and
>> the other for the parentRef)?    I'm not proposing to do this in JDK 8
>> since we are ramping down and get a low risk fix in.   It may be
>> something to revisit for jdk 9 to a cleaner version.
>
> I believe that nulling the instance variables in LoggerWeakRef
> is probably no longer needed - since we now should be calling
> dispose only once - but I didn't want to change the code too
> much. I agree it would be better to revisit that in 9.
>
>
>> Logger.java
>>     The assert this.loggerBundle == NO_RESOURCE_BUNDLE; in the Logger
>> constructors doesn't seem to be needed.
>
> OK - removed.
>
>> Having an immutable LoggerBundle class is good to ensure the
>> resourceBundleName and resourceBundle are consistent.
>>
>>     L1930: is lb.userBundle and lb.resourceBundleName null when getting
>> to this line?  Might be better to rename setupResourceInfo to
>> setResourceBundleName (that creates a LoggerBundle with a null RB). On
>> the other hand,  setResourceBundle will instantiate a LoggerBundle with
>> non-null rbname and RB.  It wasn't obvious to me what does what.
>
> Right. Let's keep the old name for now. We can revisit the naming in 9.
> You right that when we reach the last line lb.userBundle must be null,
> otherwise we would have either returned or thrown an exception, since
> lb.userBundle != null => lb.resourceBundleName != null.
>
> Therefore I added an assert lb.userBundle == null and
> replaced the call to
>   LoggerBundle.get(name, lb.userBundle)
> by
>   LoggerBundle.get(name, null)
>
> Hopefully it will make what happens more obvious.
>
>> 2137             final String rbName = getResourceBundleName();
>> 2138             if (!SYSTEM_LOGGER_RB_NAME.equals(rbName)
>> 2139                     &&
>> !SYSTEM_LOGGER_RB_NAME.equals(b.getBaseBundleName())) {
>> 2140                 return LoggerBundle.get(rbName, b);
>> 2141             } else {
>> 2142                 return SYSTEM_BUNDLE;
>> 2143             }
>>
>> To get to the above line, either lb.userBundle is null or
>> getResourceBundle() isoverridden.  L2126 already checks that this logger
>> does not associate with the system rbname.  It seems to me that the
>> special case here is when the Logger subclass overrides
>> getResourceBundleName() to returnSYSTEM_LOGGER_RB_NAME or override
>> getResourceBundle to return the "sun.util.logging.resources.logging" RB.
>> I tink that we might just simplify the above and just return
>> LoggerBundle.get(rbName, b) and no need to worry about those overridden
>> case which does no use to such a Logger subclass with unmatched rbname
>> and RB.  Same comment applied to L2157-2165.
>
> Ah. I'm glad to hear that. This is a great simplification.
> done.
>
> -- daniel
>
>
>>
>> thanks
>> Mandy
>



From joel.franck at oracle.com  Tue Dec  3 20:40:20 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 3 Dec 2013 21:40:20 +0100
Subject: RFR: JDK-8029117: (reflect) clarify javadoc for getMethod(...) and
	getMethods()
Message-ID: <81CAEEA0-8C1F-45DC-A077-E9079EEFFC10@oracle.com>

Hi

Please review this javadoc fix for Class.getMethod(name, params) and Class.getMethods() when called on an interface.

This fix aligns the javadoc with the long standing implementation to not return any implicitly declared object methods when calling getMethod(s) on an interface.

Bug: https://bugs.openjdk.java.net/browse/JDK-8029117
Webrev: http://cr.openjdk.java.net/~jfranck/8029117/webrev.01/

cheers
/Joel

From roger.riggs at oracle.com  Tue Dec  3 21:22:14 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Tue, 03 Dec 2013 21:22:14 +0000
Subject: hg: jdk8/tl/jdk: 8028019: AWT Doclint warning/error cleanup
Message-ID: <20131203212232.959A2629F9@hg.openjdk.java.net>

Changeset: 3e95aadb479f
Author:    rriggs
Date:      2013-12-03 16:20 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e95aadb479f

8028019: AWT Doclint warning/error cleanup
Summary: Fix numerious javadoc and html errors and warnings
Reviewed-by: yan

! src/share/classes/java/applet/Applet.java
! src/share/classes/java/applet/AppletContext.java
! src/share/classes/java/awt/AWTPermission.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/BorderLayout.java
! src/share/classes/java/awt/Button.java
! src/share/classes/java/awt/Checkbox.java
! src/share/classes/java/awt/CheckboxGroup.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/EventFilter.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/FileDialog.java
! src/share/classes/java/awt/FlowLayout.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/GridBagConstraints.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/GridLayout.java
! src/share/classes/java/awt/Label.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/LinearGradientPaintContext.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/Scrollbar.java
! src/share/classes/java/awt/SystemColor.java
! src/share/classes/java/awt/SystemTray.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/color/CMMException.java
! src/share/classes/java/awt/color/ColorSpace.java
! src/share/classes/java/awt/color/ICC_ColorSpace.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/color/ICC_ProfileGray.java
! src/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/share/classes/java/awt/dnd/DnDEventMulticaster.java
! src/share/classes/java/awt/dnd/DragSourceDropEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/event/MouseAdapter.java
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/StyledParagraph.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ColorConvertOp.java
! src/share/classes/java/awt/peer/CheckboxPeer.java
! src/share/classes/java/awt/peer/DesktopPeer.java



From mike.duigou at oracle.com  Tue Dec  3 22:21:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 14:21:45 -0800
Subject: RFR: 8028816: Add value-type notice to Optional* classes
Message-ID: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>

Hello all;

There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review:

http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/

I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not.

Mike

From bhavesh.x.patel at oracle.com  Tue Dec  3 22:22:36 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Tue, 03 Dec 2013 22:22:36 +0000
Subject: hg: jdk8/tl/langtools: 8025416: doclet not substituting {@docRoot} in
	some cases
Message-ID: <20131203222239.EE96B629FF@hg.openjdk.java.net>

Changeset: 4cb9de4dd420
Author:    bpatel
Date:      2013-12-03 14:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cb9de4dd420

8025416: doclet not substituting {@docRoot} in some cases
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java
! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java
! test/com/sun/javadoc/testDocRootLink/pkg1/package.html
! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java
! test/com/sun/javadoc/testDocRootLink/pkg2/package.html



From mike.duigou at oracle.com  Tue Dec  3 22:46:20 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 14:46:20 -0800
Subject: RFR: 8029055: Map.merge must refuse null values
In-Reply-To: 
References: 
	<528E568D.8020909@oracle.com>
	
	<528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com>
	
	<52929A59.20204@oracle.com>
	<63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com>
	
Message-ID: <56A1176F-3CC7-4DF9-AB6F-D5E4DC266B34@oracle.com>


On Nov 26 2013, at 05:35 , Stephen Colebourne  wrote:

> See the new thread for the general Javadoc issues. I'll focus on null here.
> 
> Given a map {"Key" -> null} I find the notion that putIfAbsent() or
> computeIfAbsent() ignore the existing mapping just plain wrong. While
> I can rationalise it (just) it is a horrible reworking of the meaning
> of "absent".

We tried it a couple of ways. The interpretation of null mapping as "absent" was the compromise we came up with. 

> Similarly, for "computeIfPresent()", my expectation is that the
> mapping is present, and that the null should be an input to the
> function.

This would have meant contradictory interpretations of absent for the different methods. 

> Yes, I get that nulls in collections are a pain, but trying to
> redefine the meaning of "absent" is more of a pain.

The problem is that not all of these methods are new, some are backports from java.util.concurrent.ConcurrentMap where there were existing null handling semantics (which didn't take into account null values). Producing consistent results across implementations seemed most important. This meant favouring the "null means absent" semantic rather than the "null might mean absent or might mean a null mapping".

> I'm aware that
> ConcurrentMap makes things interesting, but these two just look wrong.
> 
> 
> So, my rules would be
> - if an existing mapping has a null value, then the mapping is
> "present" and not "absent" (only affects methods with those words in
> their name)
> - none of these methods should try to add/update a mapping with a null value

That seems too surprising.

> - null returned from a function means remove (or is invalid)
> - a null value parameter is invalid

I had chosen to add this rule for merge() in my most recent webrev to reduce the complexity. It kind of goes against the "null is fully supported as a value".

> - merge where the existing mapping has a null value should not pass
> the null to the function

This is the same as treating it as absent. 

> 
> Stephen
> 
> 
> 
> On 26 November 2013 04:32, Mike Duigou  wrote:
>> 
>> On Nov 24 2013, at 16:31 , David Holmes  wrote:
>> 
>>> Hi Mike,
>>> 
>>> There is still no clear spec for what should happen if the param value is null.
>> 
>> I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated.
>> 
>> Currently:
>> 
>> - The provided value may be either null or non-null. Is null a legal value? It depends upon:
>>        - Is there an existing value?
>>        - Does the Map allow null values?
>>        - Does the function allow null values?
>> - Existing null values are treated as absent.
>>        - If a null value is passed should we remove this mapping or add it to the map?
>>              - null might not be accepted by the map
>>              - The associated value would still be regarded as absent for future operations.
>> - The function may return null to signal "remove".
>> 
>> In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse.
>> 
>> So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly.
>> 
>>> The parenthesized part is wrong.
>> 
>> I think that's overzealous copying from compute(). I have removed it.
>> 
>>> 
>>> Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading.
>> 
>> I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param"
>> 
>> I have updated the webrev.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/
>> 
>> Thanks,
>> 
>> Mike
>> 
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 23/11/2013 10:25 AM, Mike Duigou wrote:
>>>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue.
>>>> 
>>>> I've posted a webrev here:
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/
>>>> 
>>>> There is an identical change in ConcurrentMap's merge().
>>>> 
>>>> Mike
>>>> 
>>>> On Nov 22 2013, at 16:01 , Henry Jen  wrote:
>>>> 
>>>>> 
>>>>> On 11/21/2013 06:33 PM, David Holmes wrote:
>>>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote:
>>>>>>> While I agree that case should be specified, I'm not certain I follow why
>>>>>>> that's what's going on here.
>>>>>>> 
>>>>>>> The weird condition is that if oldValue is null, not value; oldValue
>>>>>>> is the
>>>>>>> old result of map.get(key).  The Javadoc seems not just unspecified, but
>>>>>>> actively wrong.  Here's a worked example:
>>>>>>> 
>>>>>>> Map map = new HashMap<>();
>>>>>>> map.merge("foo", 3, Integer::plus);
>>>>>>> Integer fooValue = map.get("foo");
>>>>>>> 
>>>>>>> Going through the Javadoc-specified default implementation:
>>>>>>> 
>>>>>>>  V oldValue = map.get(key); // oldValue is null
>>>>>>>  V newValue = (oldValue == null) ? value :
>>>>>>>               remappingFunction.apply(oldValue, value);
>>>>>>>     // newValue is set to value, which is 3
>>>>>>>  if (newValue == null) // newValue is nonnull, branch not taken
>>>>>>>      map.remove(key);
>>>>>>>  else if (oldValue == null) // oldValue is null, branch taken
>>>>>>>      map.remove(key); // removes the entry from the map
>>>>>>>  else // else if was already triggered, branch not taken
>>>>>>>      map.put(key, newValue);
>>>>>>> 
>>>>> 
>>>>> Seems like a document bug to me, we should fix this @implSpec.
>>>>> 
>>>>> Cheers,
>>>>> Henry
>>>>> 
>>>> 
>> 



From stuart.marks at oracle.com  Tue Dec  3 22:36:05 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Tue, 03 Dec 2013 22:36:05 +0000
Subject: hg: jdk8/tl/jdk: 7190106: java/rmi/reliability/benchmark fails
	intermittently because of use of fixed port
Message-ID: <20131203223622.73D2762A01@hg.openjdk.java.net>

Changeset: df819e356901
Author:    tyan
Date:      2013-12-03 14:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df819e356901

7190106: java/rmi/reliability/benchmark fails intermittently because of use of fixed port
Reviewed-by: smarks, mduigou

! test/ProblemList.txt
! test/java/rmi/reliability/benchmark/bench/rmi/Main.java
! test/java/rmi/reliability/benchmark/bench/serial/Main.java
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh



From mandy.chung at oracle.com  Tue Dec  3 23:27:33 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 03 Dec 2013 15:27:33 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <529DA808.7070009@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
Message-ID: <529E68E5.7000103@oracle.com>


On 12/3/2013 1:44 AM, Peter Levart wrote:
> On 12/03/2013 09:51 AM, Peter Levart wrote:
>> Hi,
>>
>> While browsing the code of java.util.logging.Handler, I noticed a 
>> theoretical possibility that a security check in a 
>> j.u.l.StreamHandler be circumvented using a data race.
>>
>> There is a plain boolean instance field 'sealed' in j.u.l.Handler 
>> that is pre-initialized to 'true' in field initializer. StreamHandler 
>> sublcass' constructors overwrite this value with 'false' at the 
>> beginning, then issue some operations which circumvent security 
>> checks, and finally they reset the 'sealed' value back to 'true' at 
>> the end.
>>
>> If a reference to an instance of StreamHandler or subclass is passed 
>> to some thread without synchronization via data-race, this thread can 
>> see 'true' or 'false' as the possible values of 'sealed' variable, 
>> thus it is possible to circumvent security checks.
>>
>> One possibility to fix this is moving the field to StreamHandler and 
>> making it final:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/ 
>>
>>
>> Just making the field volatile might not work. There is an ongoing 
>> debate on concurrency-interest which suggests that volatile fields 
>> are not exceptional in constructors like final fields are...
>>
>>
>> Regards, Peter
>>
>
> The proposed patch is not complete. There are several subclasses of 
> StreamHandler in the java.util.logging package that also need a way to 
> bypass security checks for some operations in their constructors. So 
> here's the updated webrev which updates them with the same code as 
> StreamHandler. This means that there are two copies of 'sealed' flag 
> in object of type ConsoleHandler, for example, but only the one 
> declared in ConsoleHandler is relevant for governing access checks:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.02/
>
> Before filing the bug, I'm asking the list whether this can be 
> considered a bug...
>

This does look a possible data race that might return a partially 
constructed object with sealed = false.  I am not sure how likely we 
will run into this race though.

W.r.t. the patch, it might be better to get rid of the sealed field and 
wrap the calls with doPrivileged with limited privilege (just 
LoggingPermission("control"))

Mandy


From stuart.marks at oracle.com  Tue Dec  3 23:52:06 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Tue, 03 Dec 2013 23:52:06 +0000
Subject: hg: jdk8/tl/jdk: 8028757: CharSequence.subSequence improperly
	requires a "new" CharSequence be returned
Message-ID: <20131203235219.4DA4A62A11@hg.openjdk.java.net>

Changeset: accd6ffd4b3f
Author:    smarks
Date:      2013-12-03 15:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/accd6ffd4b3f

8028757: CharSequence.subSequence improperly requires a "new" CharSequence be returned
Reviewed-by: alanb, darcy, mduigou

! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/lang/String.java



From weijun.wang at oracle.com  Wed Dec  4 01:21:06 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 04 Dec 2013 01:21:06 +0000
Subject: hg: jdk8/tl/jdk: 8028351: JWS doesn't get authenticated when using
	kerberos auth proxy
Message-ID: <20131204012124.11CE962A1E@hg.openjdk.java.net>

Changeset: e1bc55ddf1ad
Author:    weijun
Date:      2013-12-04 09:14 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1bc55ddf1ad

8028351: JWS doesn't get authenticated when using kerberos auth proxy
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/LoginNoPass.java



From daniel.fuchs at oracle.com  Wed Dec  4 00:59:36 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Wed, 04 Dec 2013 00:59:36 +0000
Subject: hg: jdk8/tl/jdk: 8029281: Synchronization issues in Logger and
	LogManager
Message-ID: <20131204005949.2A6B262A14@hg.openjdk.java.net>

Changeset: 9f624e115c6b
Author:    dfuchs
Date:      2013-12-04 01:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f624e115c6b

8029281: Synchronization issues in Logger and LogManager
Summary: Fixes several race conditions in logging which have been at the root cause of intermittent test failures.
Reviewed-by: mchung, plevart

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/TestLogConfigurationDeadLock.java
+ test/java/util/logging/TestLoggerBundleSync.java



From valerie.peng at oracle.com  Wed Dec  4 01:29:16 2013
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Wed, 04 Dec 2013 01:29:16 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131204012946.0F0A762A20@hg.openjdk.java.net>

Changeset: d922c8aba2f8
Author:    valeriep
Date:      2013-12-03 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d922c8aba2f8

8029158: sun/security/pkcs11/Signature/TestDSAKeyLength.java does not compile (or run)
Summary: Add the missing library path and skip testing against NSS 1.14 or later due to known NSS issue
Reviewed-by: vinnie, ascarpino

! test/sun/security/pkcs11/Signature/TestDSAKeyLength.java

Changeset: 75165f6c1c50
Author:    valeriep
Date:      2013-12-03 17:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75165f6c1c50

Merge




From brian.burkhalter at oracle.com  Wed Dec  4 01:33:20 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 3 Dec 2013 17:33:20 -0800
Subject: JDK 8 RFR 8029501: BigInteger division algorithm selection heuristic
	is incorrect
Message-ID: <85AFBB18-2683-4C99-9706-37727293B965@oracle.com>

Hello,

Issue:	https://bugs.openjdk.java.net/browse/JDK-8029501
Webrev:	http://cr.openjdk.java.net/~bpb/8029501/webrev/

This patch would change the division algorithm selection heuristic as previously described in [1]. Many subsequent performance benchmark runs have determined that the threshold offset should be 40 if the division threshold itself is 80 [2]. With the existing algorithm selection heuristic, i.e., dividend and divisor int-length both above the tB-Z threshold, performance regressions of up to 100% will be observed when the int-lengths of the dividend and divisor exceed the B-Z threshold but the dividend int-length is less than approximately 40 more than the divisor int-length. The proposed patch fixes that problem.

Thanks,

Brian

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023493.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/023668.html

From joe.darcy at oracle.com  Wed Dec  4 01:38:53 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 03 Dec 2013 17:38:53 -0800
Subject: JDK 8 RFR 8029501: BigInteger division algorithm selection
	heuristic is incorrect
In-Reply-To: <85AFBB18-2683-4C99-9706-37727293B965@oracle.com>
References: <85AFBB18-2683-4C99-9706-37727293B965@oracle.com>
Message-ID: <529E87AD.1070403@oracle.com>

Looks good Brian; thanks,

-Joe

On 12/3/2013 5:33 PM, Brian Burkhalter wrote:
> Hello,
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8029501
> Webrev:	http://cr.openjdk.java.net/~bpb/8029501/webrev/
>
> This patch would change the division algorithm selection heuristic as previously described in [1]. Many subsequent performance benchmark runs have determined that the threshold offset should be 40 if the division threshold itself is 80 [2]. With the existing algorithm selection heuristic, i.e., dividend and divisor int-length both above the tB-Z threshold, performance regressions of up to 100% will be observed when the int-lengths of the dividend and divisor exceed the B-Z threshold but the dividend int-length is less than approximately 40 more than the divisor int-length. The proposed patch fixes that problem.
>
> Thanks,
>
> Brian
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023493.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/023668.html



From stuart.marks at oracle.com  Wed Dec  4 01:40:03 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Dec 2013 17:40:03 -0800
Subject: RFR: 8029489: StringJoiner spec for setEmptyValue() and length()
	is malformatted
Message-ID: <529E87F3.2000200@oracle.com>

Hi all,

Please review the following small javadoc change. The StringJoiner doc for a 
couple methods uses "i.e." in the first sentence, which screws up the javadoc 
logic that pulls the first sentence into the Method Summary. This is an 
editorial change to fix this up; there is no actual specification change.

Thanks!

s'marks

# HG changeset patch
# User smarks
# Date 1386121046 28800
# Node ID 0bc91b9f6afd9b4dceea31ecd1036e367b365690
# Parent  75165f6c1c505ff43f7fd235a95b2e7955413b78
8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
Reviewed-by: XXX

diff -r 75165f6c1c50 -r 0bc91b9f6afd src/share/classes/java/util/StringJoiner.java
--- a/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:25:28 2013 -0800
+++ b/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:37:26 2013 -0800
@@ -131,7 +131,7 @@
      /**
       * Sets the sequence of characters to be used when determining the string
       * representation of this {@code StringJoiner} and no elements have been
-     * added yet, i.e. when it is empty.  A copy of the {@code emptyValue}
+     * added yet, that is, when it is empty.  A copy of the {@code emptyValue}
       * parameter is made for this purpose. Note that once an add method has been
       * called, the {@code StringJoiner} is no longer considered empty, even if
       * the element(s) added correspond to the empty {@code String}.
@@ -228,8 +228,8 @@
      }

      /**
-     * The length of the {@code StringJoiner} value, i.e. the length of
-     * {@code String} representation of the {@code StringJoiner}. Note that if
+     * Returns the length of the {@code String} representation
+     * of this {@code StringJoiner}. Note that if
       * no add methods have been called, then the length of the {@code String}
       * representation (either {@code prefix + suffix} or {@code emptyValue})
       * will be returned. The value should be equivalent to


From Lance.Andersen at oracle.com  Wed Dec  4 01:46:09 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 3 Dec 2013 20:46:09 -0500
Subject: RFR: 8029489: StringJoiner spec for setEmptyValue() and length()
	is malformatted
In-Reply-To: <529E87F3.2000200@oracle.com>
References: <529E87F3.2000200@oracle.com>
Message-ID: 

looks OK
On Dec 3, 2013, at 8:40 PM, Stuart Marks wrote:

> Hi all,
> 
> Please review the following small javadoc change. The StringJoiner doc for a couple methods uses "i.e." in the first sentence, which screws up the javadoc logic that pulls the first sentence into the Method Summary. This is an editorial change to fix this up; there is no actual specification change.
> 
> Thanks!
> 
> s'marks
> 
> # HG changeset patch
> # User smarks
> # Date 1386121046 28800
> # Node ID 0bc91b9f6afd9b4dceea31ecd1036e367b365690
> # Parent  75165f6c1c505ff43f7fd235a95b2e7955413b78
> 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
> Reviewed-by: XXX
> 
> diff -r 75165f6c1c50 -r 0bc91b9f6afd src/share/classes/java/util/StringJoiner.java
> --- a/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:25:28 2013 -0800
> +++ b/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:37:26 2013 -0800
> @@ -131,7 +131,7 @@
>     /**
>      * Sets the sequence of characters to be used when determining the string
>      * representation of this {@code StringJoiner} and no elements have been
> -     * added yet, i.e. when it is empty.  A copy of the {@code emptyValue}
> +     * added yet, that is, when it is empty.  A copy of the {@code emptyValue}
>      * parameter is made for this purpose. Note that once an add method has been
>      * called, the {@code StringJoiner} is no longer considered empty, even if
>      * the element(s) added correspond to the empty {@code String}.
> @@ -228,8 +228,8 @@
>     }
> 
>     /**
> -     * The length of the {@code StringJoiner} value, i.e. the length of
> -     * {@code String} representation of the {@code StringJoiner}. Note that if
> +     * Returns the length of the {@code String} representation
> +     * of this {@code StringJoiner}. Note that if
>      * no add methods have been called, then the length of the {@code String}
>      * representation (either {@code prefix + suffix} or {@code emptyValue})
>      * will be returned. The value should be equivalent to

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From mike.duigou at oracle.com  Wed Dec  4 01:46:39 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 17:46:39 -0800
Subject: RFR: 8029489: StringJoiner spec for setEmptyValue() and length()
	is malformatted
In-Reply-To: <529E87F3.2000200@oracle.com>
References: <529E87F3.2000200@oracle.com>
Message-ID: <29FA588F-7B36-4D30-BCB3-6C1B5BBA8509@oracle.com>

Looks fine.

On Dec 3 2013, at 17:40 , Stuart Marks  wrote:

> Hi all,
> 
> Please review the following small javadoc change. The StringJoiner doc for a couple methods uses "i.e." in the first sentence, which screws up the javadoc logic that pulls the first sentence into the Method Summary. This is an editorial change to fix this up; there is no actual specification change.
> 
> Thanks!
> 
> s'marks
> 
> # HG changeset patch
> # User smarks
> # Date 1386121046 28800
> # Node ID 0bc91b9f6afd9b4dceea31ecd1036e367b365690
> # Parent  75165f6c1c505ff43f7fd235a95b2e7955413b78
> 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
> Reviewed-by: XXX
> 
> diff -r 75165f6c1c50 -r 0bc91b9f6afd src/share/classes/java/util/StringJoiner.java
> --- a/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:25:28 2013 -0800
> +++ b/src/share/classes/java/util/StringJoiner.java	Tue Dec 03 17:37:26 2013 -0800
> @@ -131,7 +131,7 @@
>     /**
>      * Sets the sequence of characters to be used when determining the string
>      * representation of this {@code StringJoiner} and no elements have been
> -     * added yet, i.e. when it is empty.  A copy of the {@code emptyValue}
> +     * added yet, that is, when it is empty.  A copy of the {@code emptyValue}
>      * parameter is made for this purpose. Note that once an add method has been
>      * called, the {@code StringJoiner} is no longer considered empty, even if
>      * the element(s) added correspond to the empty {@code String}.
> @@ -228,8 +228,8 @@
>     }
> 
>     /**
> -     * The length of the {@code StringJoiner} value, i.e. the length of
> -     * {@code String} representation of the {@code StringJoiner}. Note that if
> +     * Returns the length of the {@code String} representation
> +     * of this {@code StringJoiner}. Note that if
>      * no add methods have been called, then the length of the {@code String}
>      * representation (either {@code prefix + suffix} or {@code emptyValue})
>      * will be returned. The value should be equivalent to



From joe.darcy at oracle.com  Wed Dec  4 01:50:10 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 03 Dec 2013 17:50:10 -0800
Subject: RFR: 8029489: StringJoiner spec for setEmptyValue() and length()
	is malformatted
In-Reply-To: <529E87F3.2000200@oracle.com>
References: <529E87F3.2000200@oracle.com>
Message-ID: <529E8A52.20803@oracle.com>

Hi Stuart,

Looks good; thanks,

-Joe

On 12/3/2013 5:40 PM, Stuart Marks wrote:
> Hi all,
>
> Please review the following small javadoc change. The StringJoiner doc 
> for a couple methods uses "i.e." in the first sentence, which screws 
> up the javadoc logic that pulls the first sentence into the Method 
> Summary. This is an editorial change to fix this up; there is no 
> actual specification change.
>
> Thanks!
>
> s'marks
>
> # HG changeset patch
> # User smarks
> # Date 1386121046 28800
> # Node ID 0bc91b9f6afd9b4dceea31ecd1036e367b365690
> # Parent  75165f6c1c505ff43f7fd235a95b2e7955413b78
> 8029489: StringJoiner spec for setEmptyValue() and length() is 
> malformatted
> Reviewed-by: XXX
>
> diff -r 75165f6c1c50 -r 0bc91b9f6afd 
> src/share/classes/java/util/StringJoiner.java
> --- a/src/share/classes/java/util/StringJoiner.java    Tue Dec 03 
> 17:25:28 2013 -0800
> +++ b/src/share/classes/java/util/StringJoiner.java    Tue Dec 03 
> 17:37:26 2013 -0800
> @@ -131,7 +131,7 @@
>      /**
>       * Sets the sequence of characters to be used when determining 
> the string
>       * representation of this {@code StringJoiner} and no elements 
> have been
> -     * added yet, i.e. when it is empty.  A copy of the {@code 
> emptyValue}
> +     * added yet, that is, when it is empty.  A copy of the {@code 
> emptyValue}
>       * parameter is made for this purpose. Note that once an add 
> method has been
>       * called, the {@code StringJoiner} is no longer considered 
> empty, even if
>       * the element(s) added correspond to the empty {@code String}.
> @@ -228,8 +228,8 @@
>      }
>
>      /**
> -     * The length of the {@code StringJoiner} value, i.e. the length of
> -     * {@code String} representation of the {@code StringJoiner}. 
> Note that if
> +     * Returns the length of the {@code String} representation
> +     * of this {@code StringJoiner}. Note that if
>       * no add methods have been called, then the length of the {@code 
> String}
>       * representation (either {@code prefix + suffix} or {@code 
> emptyValue})
>       * will be returned. The value should be equivalent to



From xueming.shen at oracle.com  Wed Dec  4 01:56:23 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 04 Dec 2013 01:56:23 +0000
Subject: hg: jdk8/tl/jdk: 8028397: Undo the lenient MIME BASE64 decoder
	support change (JDK-8025003) and remove methods de/encode(buf, buf)
Message-ID: <20131204015640.0F3A762A24@hg.openjdk.java.net>

Changeset: 301d76b8cb55
Author:    sherman
Date:      2013-12-03 17:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/301d76b8cb55

8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf)
Summary: updated the spec and implementation as requested
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/Base64GetEncoderTest.java
! test/java/util/Base64/TestBase64.java
! test/java/util/Base64/TestBase64Golden.java



From stuart.marks at oracle.com  Wed Dec  4 02:06:31 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Dec 2013 18:06:31 -0800
Subject: RFR: 8028816: Add value-type notice to Optional* classes
In-Reply-To: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
References: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
Message-ID: <529E8E27.6070706@oracle.com>

Overall looks fine.

If you're listing yourself as the reviewer, jcheck will object if you're also 
the changeset author. Instead of listing Brian Goetz in Contributed-by, make him 
the changeset author instead. Using MQ, do "hg qref -u briangoetz".

The gist of the paragraph being added to each class is,

     Use of identity-sensitive operations ... on instances of 
     may have unpredictable effects and should be avoided.

The phrase "unpredictable effects" strikes me oddly. This phrase is also used at 
the very end of the HTML doc. It makes it sound as if using an 
identity-sensitive operation might have side effects. That won't be the case, as 
far as I know. Using such an operation will indeed have "unpredictable results". 
That phrase is used at the beginning of the last paragraph of the HTML doc, and 
it makes much more sense to me than "unpredictable effects".

s'marks



On 12/3/13 2:21 PM, Mike Duigou wrote:
> Hello all;
>
> There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/
>
> I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not.
>
> Mike
>


From stuart.marks at oracle.com  Wed Dec  4 02:20:35 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Wed, 04 Dec 2013 02:20:35 +0000
Subject: hg: jdk8/tl/jdk: 8029489: StringJoiner spec for setEmptyValue() and
	length() is malformatted
Message-ID: <20131204022047.C83E062A25@hg.openjdk.java.net>

Changeset: c6b6b515cf4f
Author:    smarks
Date:      2013-12-03 18:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6b6b515cf4f

8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
Reviewed-by: darcy, lancea, mduigou

! src/share/classes/java/util/StringJoiner.java



From mike.duigou at oracle.com  Wed Dec  4 05:03:13 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Dec 2013 21:03:13 -0800
Subject: RFR: 8028816: Add value-type notice to Optional* classes
In-Reply-To: <529E8E27.6070706@oracle.com>
References: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
	<529E8E27.6070706@oracle.com>
Message-ID: 


On Dec 3 2013, at 18:06 , Stuart Marks  wrote:

> Overall looks fine.
> 
> If you're listing yourself as the reviewer, jcheck will object if you're also the changeset author. Instead of listing Brian Goetz in Contributed-by, make him the changeset author instead. Using MQ, do "hg qref -u briangoetz".

OK. I am reluctant to use the -u option but don't want to anger jcheck.

> 
> The gist of the paragraph being added to each class is,
> 
>    Use of identity-sensitive operations ... on instances of 
>    may have unpredictable effects and should be avoided.
> 
> The phrase "unpredictable effects" strikes me oddly. This phrase is also used at the very end of the HTML doc. It makes it sound as if using an identity-sensitive operation might have side effects. That won't be the case, as far as I know. Using such an operation will indeed have "unpredictable results". That phrase is used at the beginning of the last paragraph of the HTML doc, and it makes much more sense to me than "unpredictable effects".

I prefer "results" to "effects" as well.

Mike

> 
> s'marks
> 
> 
> 
> On 12/3/13 2:21 PM, Mike Duigou wrote:
>> Hello all;
>> 
>> There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/
>> 
>> I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not.
>> 
>> Mike
>> 



From joe.darcy at oracle.com  Wed Dec  4 05:23:39 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 03 Dec 2013 21:23:39 -0800
Subject: JDK 8 RFR for JDK-8023471, ,
	Add compatibility note to AnnotatedElement
Message-ID: <529EBC5B.1000209@oracle.com>

Hello,

Please review the patch below to address

     JDK-8023471 Add compatibility note to AnnotatedElement

Thanks,

-Joe

diff -r cd4aabc40f72 
src/share/classes/java/lang/reflect/AnnotatedElement.java
--- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue Dec 
03 11:52:18 2013 -0800
+++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue Dec 
03 21:23:16 2013 -0800
@@ -135,7 +135,63 @@
   * annotations on E are directly present on E in place
   * of their container annotation, in the order in which they appear in
   * the value element of the container annotation.
-
+ *
+ * 
There are several compatibility concerns to keep in mind if an
+ * annotation type T is not repeatable in one release
+ * of a library and retrofitted to be repeatable in a subsequent
+ * release.
+ *
+ * 
    
+ *
+ * 
  • If an annotation of type T is present on an
+ * element and T is made repeatable and more annotations of
+ * type T are added to the element:
+ *
+ *
+ * 
      
+ *
+ * 
    •  The addition of the additional annotations is both source
+ * compatible and binary compatible. That is, the source containing
+ * the element and its annotations will still compile and the class
+ * file resulting from the compilation will continue to link.
+ *
+ * 
    • The addition of the additional annotations is not
+ * behaviorally compatible with respect to the {@code
+ * get[Declared]Annotation(Class)} methods and {@code
+ * get[Declared]Annotations()} methods, because those methods will now
+ * only see a container annotations on the element and not see an
+ * annotation of type T.
+ *
+ * 
    
+ *
+ * 
  • If an annotation type TC is present
+ * on an element, then making some other annotation type T
+ * repeatable with TC as its containing annotation type then:
+ *
+ * 
      
+ *
+ * 
    • The change to Tis source and binary compatible with
+ * existing uses of annotations of type T as well as
+ * annotations of type TC.
+ *
+ * 
    • The change to T is behaviorally compatible with respect
+ * to the {@code get[Declared]Annotation(Class)} (called with an
+ * argument of T or TC) and {@code
+ * get[Declared]Annotations()} methods because the results of the
+ * methods will not change due to TC becoming the containing
+ * annotation type for T.
+ *
+ * 
    • The change to T is not behaviorally compatible
+ * with respect to the {@code
+ * get[Declared]AnnotationsByType(Class)} methods, because those
+ * methods will now recognize an annotation of type TC as a
+ * container annotation and "look through" it to expose annotations of
+ * type T.
+ *
+ * 
    
+ *
+ * 

+ *
   * 
If an annotation returned by a method in this interface contains
   * (directly or indirectly) a {@link Class}-valued member referring to
   * a class that is not accessible in this VM, attempting to read the class



From mike.duigou at oracle.com  Wed Dec  4 05:23:04 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 04 Dec 2013 05:23:04 +0000
Subject: hg: jdk8/tl/jdk: 8028816: Add value-type notice to Optional* classes
Message-ID: <20131204052316.CF4FC62A2B@hg.openjdk.java.net>

Changeset: 2aae624bb833
Author:    briangoetz
Date:      2013-12-03 21:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aae624bb833

8028816: Add value-type notice to Optional* classes
Reviewed-by: mduigou, smarks
Contributed-by: bitterfoxc at gmail.com

+ src/share/classes/java/lang/doc-files/ValueBased.html
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/OptionalDouble.java
! src/share/classes/java/util/OptionalInt.java
! src/share/classes/java/util/OptionalLong.java



From tristan.yan at oracle.com  Wed Dec  4 07:05:51 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Tue, 3 Dec 2013 23:05:51 -0800 (PST)
Subject: Initial with JDK-7168267
Message-ID: <147942d4-f052-4403-b374-3d3ed59e7175@default>

Hi Stuart

I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is asking performance improvement for RMI test. Because this would involve different RMI tests. I'd like to use this cr as an umbrella bug, create sub-cr for different test. Then I can make progress on sub-cr. Please let me know your opinion on this.

Thank you.

 

Tristan Yan(Haibo Yan)

 


From lana.steuck at oracle.com  Wed Dec  4 07:55:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:24 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20131204075527.E773062A42@hg.openjdk.java.net>

Changeset: b55a011cf8ae
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b55a011cf8ae

Added tag jdk8-b118 for changeset 8d014b039b44

! .hgtags

Changeset: c3343930c73c
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c3343930c73c

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:55:32 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:32 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20131204075545.5ED2562A43@hg.openjdk.java.net>

Changeset: 1f6ffcd56363
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f6ffcd56363

Added tag jdk8-b118 for changeset 4fd6a7ff8c06

! .hgtags

Changeset: 43a80d75d06e
Author:    lana
Date:      2013-12-03 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/43a80d75d06e

Merge


Changeset: 1b69023743be
Author:    lana
Date:      2013-12-03 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1b69023743be

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:55:31 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:31 +0000
Subject: hg: jdk8/tl/hotspot: 11 new changesets
Message-ID: <20131204075556.DCBBF62A44@hg.openjdk.java.net>

Changeset: e6dfcdf37ef2
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e6dfcdf37ef2

Added tag jdk8-b118 for changeset c9f439732b18

! .hgtags

Changeset: e51d73189692
Author:    amurillo
Date:      2013-11-22 13:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e51d73189692

8028815: new hotspot build - hs25-b61
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 19146c82b6fc
Author:    hseigel
Date:      2013-11-21 14:41 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19146c82b6fc

8028520: JVM should not throw VerifyError when a private method overrides a final method
Summary: Exclude private methods when checking for final method override.
Reviewed-by: kamg, coleenp, dholmes, mseledtsov

! src/share/vm/classfile/classFileParser.cpp

Changeset: 260ac69dc096
Author:    mgronlun
Date:      2013-11-23 09:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/260ac69dc096

Merge


Changeset: 86e6d691f2e1
Author:    mgronlun
Date:      2013-11-23 12:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86e6d691f2e1

8028128: Add a type safe alternative for working with counter based data
Reviewed-by: dholmes, egahlin

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/shared/gcTimer.cpp
! src/share/vm/gc_implementation/shared/gcTimer.hpp
! src/share/vm/gc_implementation/shared/gcTrace.cpp
! src/share/vm/gc_implementation/shared/gcTrace.hpp
! src/share/vm/gc_implementation/shared/gcTraceSend.cpp
! src/share/vm/gc_implementation/shared/gcTraceTime.cpp
! src/share/vm/gc_implementation/shared/gcTraceTime.hpp
! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp
! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/trace/noTraceBackend.hpp
! src/share/vm/trace/trace.xml
! src/share/vm/trace/traceBackend.hpp
! src/share/vm/trace/traceEvent.hpp
! src/share/vm/trace/traceEventClasses.xsl
! src/share/vm/trace/traceTime.hpp
! src/share/vm/trace/traceTypes.xsl
! src/share/vm/trace/tracetypes.xml
+ src/share/vm/utilities/ticks.cpp
+ src/share/vm/utilities/ticks.hpp
+ src/share/vm/utilities/ticks.inline.hpp

Changeset: 22eaa15b7960
Author:    hseigel
Date:      2013-11-26 09:52 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22eaa15b7960

8026065: InterfaceMethodref for invokespecial must name a direct superinterface
Summary: Add verification to check that invokespecial of an InterfaceMethodref names a method in a direct superinterface of the current class or interface in accordance with JSR 335, JVMS 4.9.2 Structural Constraints.
Reviewed-by: acorn, hseigel, coleenp
Contributed-by: lois.foltan at oracle.com

! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: e567d5afd4dd
Author:    hseigel
Date:      2013-11-26 16:03 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e567d5afd4dd

8028160: [TESTBUG] Exclude failing (runtime) jtreg tests using @ignore
Summary: Use @ignore to exclude failing tests
Reviewed-by: coleenp, ctornqvi, mseledtsov
Contributed-by: george.triantafillou at oracle.com

! test/runtime/6626217/Test6626217.sh
! test/runtime/6929067/Test6929067.sh
! test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/InitialThreadOverflow/testme.sh
! test/runtime/LoadClass/LoadClassNegative.java
! test/runtime/XCheckJniJsig/XCheckJSig.java
! test/runtime/jsig/Test8017498.sh
! test/runtime/memory/ReadFromNoaccessArea.java

Changeset: 9d15b81d5d1b
Author:    drchase
Date:      2013-11-26 18:16 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d15b81d5d1b

8016839: JSR292: AME instead of IAE when calling a method
Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null.
Reviewed-by: acorn, jrose, coleenp

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klassVtable.cpp
! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java
! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java
+ test/compiler/jsr292/methodHandleExceptions/p/C.java
+ test/compiler/jsr292/methodHandleExceptions/p/Dok.java
+ test/compiler/jsr292/methodHandleExceptions/p/E.java
+ test/compiler/jsr292/methodHandleExceptions/p/F.java
+ test/compiler/jsr292/methodHandleExceptions/p/I.java
+ test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java
+ test/compiler/jsr292/methodHandleExceptions/p/Treflect.java

Changeset: 2315fab779ca
Author:    drchase
Date:      2013-11-29 11:32 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2315fab779ca

Merge

! src/share/vm/classfile/systemDictionary.hpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: b2426da30009
Author:    amurillo
Date:      2013-11-29 11:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2426da30009

Merge

- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: ce42d815dd21
Author:    amurillo
Date:      2013-11-29 11:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce42d815dd21

Added tag hs25-b61 for changeset b2426da30009

! .hgtags



From lana.steuck at oracle.com  Wed Dec  4 07:55:17 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:17 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20131204075518.A88B862A3F@hg.openjdk.java.net>

Changeset: 06d512d44c31
Author:    cl
Date:      2013-11-28 08:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/06d512d44c31

Added tag jdk8-b118 for changeset 0a6db1aac998

! .hgtags

Changeset: 9e90215673be
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/9e90215673be

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:55:17 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:17 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20131204075525.B2B1C62A40@hg.openjdk.java.net>

Changeset: 7ac7d1afd966
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7ac7d1afd966

Added tag jdk8-b118 for changeset 76a598cf50c4

! .hgtags

Changeset: 172b8e056ff2
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/172b8e056ff2

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:55:13 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:13 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20131204075516.484DC62A3E@hg.openjdk.java.net>

Changeset: 5029f982dfae
Author:    cl
Date:      2013-11-28 08:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/5029f982dfae

Added tag jdk8-b118 for changeset d6820a414f18

! .hgtags

Changeset: 379fc7609beb
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/379fc7609beb

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:55:17 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:55:17 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20131204075526.C901E62A41@hg.openjdk.java.net>

Changeset: 6b37ae056340
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6b37ae056340

Added tag jdk8-b118 for changeset e4e5069250e7

! .hgtags

Changeset: 69a930376c70
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/69a930376c70

Merge




From lana.steuck at oracle.com  Wed Dec  4 07:57:44 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 07:57:44 +0000
Subject: hg: jdk8/tl/jdk: 32 new changesets
Message-ID: <20131204080445.1F45662A45@hg.openjdk.java.net>

Changeset: 6c1f5c7baab0
Author:    ksrini
Date:      2013-11-21 12:01 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c1f5c7baab0

8028645: [infra] purge applet demos from the Solaris distros
Reviewed-by: erikj

! makefiles/CompileDemos.gmk

Changeset: 66c98bd811f1
Author:    rgallard
Date:      2013-11-25 20:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66c98bd811f1

8029043: Update nroff files for JDK 8
Reviewed-by: weijun, alanb, ksrini, naoto

! src/bsd/doc/man/appletviewer.1
! src/bsd/doc/man/extcheck.1
! src/bsd/doc/man/idlj.1
! src/bsd/doc/man/jar.1
! src/bsd/doc/man/jarsigner.1
! src/bsd/doc/man/java.1
! src/bsd/doc/man/javac.1
! src/bsd/doc/man/javadoc.1
! src/bsd/doc/man/javah.1
! src/bsd/doc/man/javap.1
+ src/bsd/doc/man/jcmd.1
! src/bsd/doc/man/jconsole.1
! src/bsd/doc/man/jdb.1
+ src/bsd/doc/man/jdeps.1
! src/bsd/doc/man/jhat.1
! src/bsd/doc/man/jinfo.1
+ src/bsd/doc/man/jjs.1
! src/bsd/doc/man/jmap.1
! src/bsd/doc/man/jps.1
! src/bsd/doc/man/jrunscript.1
! src/bsd/doc/man/jsadebugd.1
! src/bsd/doc/man/jstack.1
! src/bsd/doc/man/jstat.1
! src/bsd/doc/man/jstatd.1
! src/bsd/doc/man/keytool.1
! src/bsd/doc/man/native2ascii.1
! src/bsd/doc/man/orbd.1
! src/bsd/doc/man/pack200.1
! src/bsd/doc/man/policytool.1
! src/bsd/doc/man/rmic.1
! src/bsd/doc/man/rmid.1
! src/bsd/doc/man/rmiregistry.1
! src/bsd/doc/man/schemagen.1
! src/bsd/doc/man/serialver.1
! src/bsd/doc/man/servertool.1
! src/bsd/doc/man/tnameserv.1
! src/bsd/doc/man/unpack200.1
! src/bsd/doc/man/wsgen.1
! src/bsd/doc/man/wsimport.1
! src/bsd/doc/man/xjc.1
! src/linux/doc/man/appletviewer.1
! src/linux/doc/man/extcheck.1
! src/linux/doc/man/idlj.1
! src/linux/doc/man/jar.1
! src/linux/doc/man/jarsigner.1
! src/linux/doc/man/java.1
! src/linux/doc/man/javac.1
! src/linux/doc/man/javadoc.1
! src/linux/doc/man/javah.1
! src/linux/doc/man/javap.1
! src/linux/doc/man/jcmd.1
! src/linux/doc/man/jconsole.1
! src/linux/doc/man/jdb.1
+ src/linux/doc/man/jdeps.1
! src/linux/doc/man/jhat.1
! src/linux/doc/man/jinfo.1
+ src/linux/doc/man/jjs.1
! src/linux/doc/man/jmap.1
! src/linux/doc/man/jps.1
! src/linux/doc/man/jrunscript.1
! src/linux/doc/man/jsadebugd.1
! src/linux/doc/man/jstack.1
! src/linux/doc/man/jstat.1
! src/linux/doc/man/jstatd.1
! src/linux/doc/man/keytool.1
! src/linux/doc/man/native2ascii.1
! src/linux/doc/man/orbd.1
! src/linux/doc/man/pack200.1
! src/linux/doc/man/policytool.1
! src/linux/doc/man/rmic.1
! src/linux/doc/man/rmid.1
! src/linux/doc/man/rmiregistry.1
! src/linux/doc/man/schemagen.1
! src/linux/doc/man/serialver.1
! src/linux/doc/man/servertool.1
! src/linux/doc/man/tnameserv.1
! src/linux/doc/man/unpack200.1
! src/linux/doc/man/wsgen.1
! src/linux/doc/man/wsimport.1
! src/linux/doc/man/xjc.1
! src/solaris/doc/sun/man/man1/appletviewer.1
! src/solaris/doc/sun/man/man1/extcheck.1
! src/solaris/doc/sun/man/man1/idlj.1
! src/solaris/doc/sun/man/man1/jar.1
! src/solaris/doc/sun/man/man1/jarsigner.1
! src/solaris/doc/sun/man/man1/java.1
! src/solaris/doc/sun/man/man1/javac.1
! src/solaris/doc/sun/man/man1/javadoc.1
! src/solaris/doc/sun/man/man1/javah.1
! src/solaris/doc/sun/man/man1/javap.1
! src/solaris/doc/sun/man/man1/jcmd.1
! src/solaris/doc/sun/man/man1/jconsole.1
! src/solaris/doc/sun/man/man1/jdb.1
+ src/solaris/doc/sun/man/man1/jdeps.1
! src/solaris/doc/sun/man/man1/jhat.1
! src/solaris/doc/sun/man/man1/jinfo.1
+ src/solaris/doc/sun/man/man1/jjs.1
! src/solaris/doc/sun/man/man1/jmap.1
! src/solaris/doc/sun/man/man1/jps.1
! src/solaris/doc/sun/man/man1/jrunscript.1
! src/solaris/doc/sun/man/man1/jsadebugd.1
! src/solaris/doc/sun/man/man1/jstack.1
! src/solaris/doc/sun/man/man1/jstat.1
! src/solaris/doc/sun/man/man1/jstatd.1
! src/solaris/doc/sun/man/man1/keytool.1
! src/solaris/doc/sun/man/man1/native2ascii.1
! src/solaris/doc/sun/man/man1/orbd.1
! src/solaris/doc/sun/man/man1/pack200.1
! src/solaris/doc/sun/man/man1/policytool.1
! src/solaris/doc/sun/man/man1/rmic.1
! src/solaris/doc/sun/man/man1/rmid.1
! src/solaris/doc/sun/man/man1/rmiregistry.1
! src/solaris/doc/sun/man/man1/schemagen.1
! src/solaris/doc/sun/man/man1/serialver.1
! src/solaris/doc/sun/man/man1/servertool.1
! src/solaris/doc/sun/man/man1/tnameserv.1
! src/solaris/doc/sun/man/man1/unpack200.1
! src/solaris/doc/sun/man/man1/wsgen.1
! src/solaris/doc/sun/man/man1/wsimport.1
! src/solaris/doc/sun/man/man1/xjc.1

Changeset: 28ca338366ff
Author:    rgallard
Date:      2013-11-25 20:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28ca338366ff

Merge


Changeset: a1c49f8881ae
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1c49f8881ae

Added tag jdk8-b118 for changeset 28ca338366ff

! .hgtags

Changeset: e5eb65043d31
Author:    prr
Date:      2013-11-19 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5eb65043d31

8027541: ully transparent jframe becomes black.
Reviewed-by: bae, ceisserer

! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java

Changeset: 4592f0985e78
Author:    yan
Date:      2013-11-20 12:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4592f0985e78

8025235: [javadoc] fix some errors in 2D
Reviewed-by: prr, yan
Contributed-by: Dmitry Ginzburg 

! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsConfiguration.java
! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/Image.java
! src/share/classes/java/awt/MediaTracker.java
! src/share/classes/java/awt/PageAttributes.java
! src/share/classes/java/awt/Rectangle.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/TextAttribute.java
! src/share/classes/java/awt/geom/FlatteningPathIterator.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/print/Book.java
! src/share/classes/java/awt/print/PageFormat.java
! src/share/classes/java/awt/print/Printable.java
! src/share/classes/java/awt/print/PrinterJob.java

Changeset: c7b0f01e2268
Author:    ceisserer
Date:      2013-11-25 09:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7b0f01e2268

8028722: Render: Drawing strings with exactly 254 glyphs causes hangs
Reviewed-by: prr, bae

! src/solaris/classes/sun/font/XRTextRenderer.java
+ test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java

Changeset: f8104b663f58
Author:    lana
Date:      2013-11-25 12:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8104b663f58

Merge

! src/share/classes/java/awt/GraphicsDevice.java
- src/share/classes/sun/management/OperatingSystemImpl.java
- src/share/native/java/lang/ref/Finalizer.c
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
- test/java/lang/management/ThreadMXBean/ThreadStateTest.java
- test/java/lang/reflect/Method/DefaultMethodModeling.java
- test/java/net/URLPermission/nstest/policy
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java

Changeset: 723bcc68738b
Author:    jgodinez
Date:      2013-11-26 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/723bcc68738b

8028584: sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection
Reviewed-by: bae, prr

! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! test/java/awt/print/PageFormat/PageFormatFromAttributes.java

Changeset: 76171168e894
Author:    bae
Date:      2013-11-27 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76171168e894

8024767: [TEST] need test to cover JDK-7189452
Reviewed-by: ceisserer, bae
Contributed-by: alexander.v.stepanov at oracle.com

+ test/java/awt/Graphics2D/DrawString/TextRenderingTest.java

Changeset: d98e37b8209d
Author:    lana
Date:      2013-11-27 10:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d98e37b8209d

Merge


Changeset: 0d5cc1f305c6
Author:    alexsch
Date:      2013-11-15 14:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5cc1f305c6

8025126: [macosx] Invalid calls to setValueAt() within JTable in Java 7 on Mac OS X
Reviewed-by: serb

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java

Changeset: d3acc0e0ca3d
Author:    pchelko
Date:      2013-11-15 17:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3acc0e0ca3d

7124253: [macosx] Flavor change notification not coming
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/native/sun/awt/CClipboard.h
! src/macosx/native/sun/awt/CClipboard.m

Changeset: 919562e54af8
Author:    pchelko
Date:      2013-11-18 19:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919562e54af8

8027992: FileInputStream and BufferedInputStream should be closed in sun.applet.*
Reviewed-by: anthony, serb

! src/share/classes/sun/applet/AppletPanel.java
! src/share/classes/sun/applet/AppletViewer.java
! src/share/classes/sun/applet/Main.java

Changeset: 3ee121726c17
Author:    bagiras
Date:      2013-11-18 23:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ee121726c17

8027628: JWindow jumps to (0, 0) after mouse clicked
Reviewed-by: anthony, serb

! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
+ test/java/awt/Window/TopLevelLocation/TopLevelLocation.java

Changeset: 0e1e52166f70
Author:    serb
Date:      2013-11-19 18:16 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e1e52166f70

8027913: drop target notifications are sent out of order during DnD
Reviewed-by: anthony, art

! src/share/classes/java/awt/Container.java
+ test/java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java

Changeset: 91279a4a41f3
Author:    pchelko
Date:      2013-11-22 10:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91279a4a41f3

8028485: [macosx] java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java fails
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/AWTWindow.m
! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java

Changeset: 876c81f7f44c
Author:    serb
Date:      2013-11-22 15:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/876c81f7f44c

8027479: [macosx] Appletviewer is broken after 8014718
Reviewed-by: anthony, leonidr

! src/macosx/classes/sun/lwawt/LWComponentPeer.java

Changeset: c1bbf2d0bc80
Author:    serb
Date:      2013-11-22 17:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1bbf2d0bc80

8028512: [macosx] Crash in full screen api if incorrect display mode is used
Reviewed-by: anthony, leonidr

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: e3df535c613f
Author:    bagiras
Date:      2013-11-25 14:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3df535c613f

8028995: Write regression test for JDK-8016356
Reviewed-by: serb, anthony

+ test/javax/swing/JFrame/8016356/bug8016356.java

Changeset: bee2cc6941bb
Author:    lana
Date:      2013-11-25 13:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bee2cc6941bb

Merge

- src/share/classes/sun/management/OperatingSystemImpl.java
- src/share/native/java/lang/ref/Finalizer.c
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
- test/java/lang/management/ThreadMXBean/ThreadStateTest.java
- test/java/lang/reflect/Method/DefaultMethodModeling.java
- test/java/net/URLPermission/nstest/policy
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java

Changeset: 6829d28b3da5
Author:    malenkov
Date:      2013-11-26 13:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6829d28b3da5

8028054: com.sun.beans.finder.MethodFinder has unsynchronized access to a static Map
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/beans/finder/ConstructorFinder.java
! src/share/classes/com/sun/beans/finder/MethodFinder.java
! src/share/classes/com/sun/beans/finder/Signature.java
+ src/share/classes/com/sun/beans/finder/SignatureException.java
+ src/share/classes/com/sun/beans/util/Cache.java
+ test/java/beans/XMLDecoder/8028054/Task.java
+ test/java/beans/XMLDecoder/8028054/TestConstructorFinder.java
+ test/java/beans/XMLDecoder/8028054/TestMethodFinder.java

Changeset: 610da7dcd1be
Author:    bagiras
Date:      2013-11-26 15:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/610da7dcd1be

7160604: Using non-opaque windows - popups are initially not painted correctly
Reviewed-by: serb, alexsch

! src/share/classes/javax/swing/JPopupMenu.java
+ test/javax/swing/JPopupMenu/7160604/bug7160604.html
+ test/javax/swing/JPopupMenu/7160604/bug7160604.java

Changeset: ab933b508274
Author:    mcherkas
Date:      2013-11-26 17:16 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab933b508274

8028271: Wrong alt processing during switching between windows.
Reviewed-by: serb, alexsch

! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java

Changeset: 7d33bca26091
Author:    pchelko
Date:      2013-11-26 18:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d33bca26091

8024161: [TEST_BUG] [macosx] java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java failed "menu was opened by first click after opened Choice"
Reviewed-by: anthony, serb

! test/java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java

Changeset: f99277913d40
Author:    pchelko
Date:      2013-11-27 11:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f99277913d40

8011142: [TEST_BUG] 2 AppContext regression tests failed since 7u25b03 with NullPointerException
Reviewed-by: anthony, serb

! test/java/awt/EventQueue/MainAppContext/MainAppContext.java

Changeset: 85dc748aa403
Author:    serb
Date:      2013-11-27 20:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85dc748aa403

8029024: [TEST_BUG] java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java fails
Reviewed-by: malenkov, alexsch

! test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java

Changeset: 2bcdf1e05642
Author:    lana
Date:      2013-11-27 10:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bcdf1e05642

Merge


Changeset: 657a3cccf8a1
Author:    lana
Date:      2013-11-27 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/657a3cccf8a1

Merge

+ make/CompileDemos.gmk
- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- 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/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- 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/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- 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/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml
- test/javax/xml/jaxp/transform/jdk8004476/TestBase.java
- test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher

Changeset: ad44a8473b3f
Author:    lana
Date:      2013-12-03 10:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad44a8473b3f

Merge


Changeset: e4499a6529e8
Author:    amurillo
Date:      2013-12-03 12:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4499a6529e8

8029421: Add java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java to exclude list
Reviewed-by: alanb, jcoomes

! test/ProblemList.txt

Changeset: a5b8506f418a
Author:    lana
Date:      2013-12-03 23:09 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5b8506f418a

Merge

! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Font.java
! test/ProblemList.txt



From jeroen at sumatra.nl  Wed Dec  4 08:24:05 2013
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Wed, 4 Dec 2013 08:24:05 +0000
Subject: Request: Remove System.out check from Class.checkInitted()
Message-ID: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>

Hi,

I'd like to propose to change Class.checkInitted() to check if the VM initialization has completed by using sun.misc.VM.isBooted() instead of System.out != null.

The current check needlessly triggers System class initialization (thus complicating bootstrap initialization order on VMs that don't have a strict initialization bootstrap) and is also not strictly correct, because System.out == null is a valid state after initialization has completed.

Thanks,
Jeroen



From staffan.larsen at oracle.com  Wed Dec  4 08:44:24 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 04 Dec 2013 08:44:24 +0000
Subject: hg: jdk8/tl/jdk: 6461635: [TESTBUG] BasicTests.sh test fails
	intermittently
Message-ID: <20131204084440.B262062A4B@hg.openjdk.java.net>

Changeset: d30f49aa2d01
Author:    sla
Date:      2013-12-03 17:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f49aa2d01

6461635: [TESTBUG] BasicTests.sh test fails intermittently
Summary: Transform dummy class instead of BigInteger to avoid complication by -Xshare. Ported from script to java.
Reviewed-by: alanb
Contributed-by: mattias.tobiasson at oracle.com

! test/ProblemList.txt
- test/com/sun/tools/attach/AgentSetup.sh
! test/com/sun/tools/attach/Application.java
- test/com/sun/tools/attach/ApplicationSetup.sh
! test/com/sun/tools/attach/BasicTests.java
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
! test/com/sun/tools/attach/PermissionTest.java
- test/com/sun/tools/attach/PermissionTests.sh
! test/com/sun/tools/attach/ProviderTest.java
- test/com/sun/tools/attach/ProviderTests.sh
! test/com/sun/tools/attach/RedefineAgent.java
+ test/com/sun/tools/attach/RedefineDummy.java
+ test/com/sun/tools/attach/RunnerUtil.java
! test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/lib/testlibrary/jdk/testlibrary/Utils.java
! test/sun/tools/jstatd/JstatdTest.java



From huizhe.wang at oracle.com  Wed Dec  4 08:18:18 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Wed, 04 Dec 2013 08:18:18 +0000
Subject: hg: jdk8/tl/jaxp: 8027973: Error in the documentation for newFactory
	method of the javax.xml.stream factories
Message-ID: <20131204081820.774FA62A46@hg.openjdk.java.net>

Changeset: aed9ca4d33ec
Author:    joehw
Date:      2013-12-04 00:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aed9ca4d33ec

8027973: Error in the documentation for newFactory method of the javax.xml.stream factories
Reviewed-by: alanb, dfuchs, lancea, rriggs

! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/stream/XMLEventFactory.java
! src/javax/xml/stream/XMLInputFactory.java
! src/javax/xml/stream/XMLOutputFactory.java



From stuart.marks at oracle.com  Wed Dec  4 08:54:34 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Dec 2013 00:54:34 -0800
Subject: JDK 8 RFR for JDK-8023471, ,
	Add compatibility note to AnnotatedElement
In-Reply-To: <529EBC5B.1000209@oracle.com>
References: <529EBC5B.1000209@oracle.com>
Message-ID: <529EEDCA.3070201@oracle.com>

Hi Joe,

The changes look sensible to me. Funnily enough, when I read the next, the voice 
echoing in my head sounds like Alex's....

A small clarification:

> + * 
  •  The addition of the additional annotations is both source
> + * compatible and binary compatible. That is, the source containing
> + * the element and its annotations will still compile and the class
> + * file resulting from the compilation will continue to link.

This seems to imply that binary compatibility is with respect to the binary 
resulting from having recompiled the source. I have no doubt that such a binary 
will link successfully, but that's not quite what I had expected when I read 
"binary compatibility".

I would think that binary compatibility in this context would refer to clients 
that have *not* been recompiled, but which are linked with a newer version of 
the library that has changed to allow repeating annotations. Or perhaps it would 
refer to an old class binary that *uses an annotation, being linked with a 
library that *defines* that annotation, whose definition has been changed to 
allow that annotation to repeat. I don't know if these are real issues, but 
they're what came to mind when "binary compatibility" was mentioned.

The statement in the paragraph I quoted above would seem more sensible to me if 
the mention of "binary compatible" were struck.

s'marks

On 12/3/13 9:23 PM, Joe Darcy wrote:
> Hello,
>
> Please review the patch below to address
>
>      JDK-8023471 Add compatibility note to AnnotatedElement
>
> Thanks,
>
> -Joe
>
> diff -r cd4aabc40f72 src/share/classes/java/lang/reflect/AnnotatedElement.java
> --- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue Dec 03
> 11:52:18 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue Dec 03
> 21:23:16 2013 -0800
> @@ -135,7 +135,63 @@
>    * annotations on E are directly present on E in place
>    * of their container annotation, in the order in which they appear in
>    * the value element of the container annotation.
> -
> + *
> + * 
    There are several compatibility concerns to keep in mind if an
> + * annotation type T is not repeatable in one release
> + * of a library and retrofitted to be repeatable in a subsequent
> + * release.
> + *
> + * 
      
> + *
> + * 
    • If an annotation of type T is present on an
> + * element and T is made repeatable and more annotations of
> + * type T are added to the element:
> + *
> + *
> + * 
        
> + *
> + * 
      •  The addition of the additional annotations is both source
> + * compatible and binary compatible. That is, the source containing
> + * the element and its annotations will still compile and the class
> + * file resulting from the compilation will continue to link.
> + *
> + * 
      • The addition of the additional annotations is not
> + * behaviorally compatible with respect to the {@code
> + * get[Declared]Annotation(Class)} methods and {@code
> + * get[Declared]Annotations()} methods, because those methods will now
> + * only see a container annotations on the element and not see an
> + * annotation of type T.
> + *
> + * 
      
> + *
> + * 
    • If an annotation type TC is present
> + * on an element, then making some other annotation type T
> + * repeatable with TC as its containing annotation type then:
> + *
> + * 
        
> + *
> + * 
      • The change to Tis source and binary compatible with
> + * existing uses of annotations of type T as well as
> + * annotations of type TC.
> + *
> + * 
      • The change to T is behaviorally compatible with respect
> + * to the {@code get[Declared]Annotation(Class)} (called with an
> + * argument of T or TC) and {@code
> + * get[Declared]Annotations()} methods because the results of the
> + * methods will not change due to TC becoming the containing
> + * annotation type for T.
> + *
> + * 
      • The change to T is not behaviorally compatible
> + * with respect to the {@code
> + * get[Declared]AnnotationsByType(Class)} methods, because those
> + * methods will now recognize an annotation of type TC as a
> + * container annotation and "look through" it to expose annotations of
> + * type T.
> + *
> + * 
      
> + *
> + * 
    
> + *
>    * 
    If an annotation returned by a method in this interface contains
>    * (directly or indirectly) a {@link Class}-valued member referring to
>    * a class that is not accessible in this VM, attempting to read the class
>


From Alan.Bateman at oracle.com  Wed Dec  4 09:00:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Dec 2013 09:00:59 +0000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
Message-ID: <529EEF4B.4000103@oracle.com>

On 04/12/2013 08:24, Jeroen Frijters wrote:
> Hi,
>
> I'd like to propose to change Class.checkInitted() to check if the VM initialization has completed by using sun.misc.VM.isBooted() instead of System.out != null.
This should be changed (I can only guess that whoever added this wasn't 
aware of VM.isBooted).

-Alan.



From paul.sandoz at oracle.com  Wed Dec  4 09:32:16 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 04 Dec 2013 09:32:16 +0000
Subject: hg: jdk8/tl/jdk: 8029164: Race condition in
	CompletableFuture.thenCompose with asynchronous task
Message-ID: <20131204093231.6D1D662A4C@hg.openjdk.java.net>

Changeset: 2aa455506c49
Author:    psandoz
Date:      2013-12-04 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa455506c49

8029164: Race condition in CompletableFuture.thenCompose with asynchronous task
Reviewed-by: dl, chegar, mduigou

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java



From joel.franck at oracle.com  Wed Dec  4 10:07:20 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Wed, 04 Dec 2013 10:07:20 +0000
Subject: hg: jdk8/tl/jdk: 8029117: (reflect) clarify javadoc for
	getMethod(...) and getMethods()
Message-ID: <20131204100738.8AAF562A4D@hg.openjdk.java.net>

Changeset: e984e2871bf7
Author:    jfranck
Date:      2013-12-04 11:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e984e2871bf7

8029117: (reflect) clarify javadoc for getMethod(...) and getMethods()
Reviewed-by: darcy

! src/share/classes/java/lang/Class.java



From paul.sandoz at oracle.com  Wed Dec  4 10:31:59 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 4 Dec 2013 11:31:59 +0100
Subject: 8028564: Concurrent calls to CHM.put can fail to add the
	key/value to the map
In-Reply-To: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
Message-ID: 

I have reviewed Doug's code, just need someone to quickly review the test code.

Paul.

On Dec 2, 2013, at 5:29 PM, Paul Sandoz  wrote:

> Hi,
> 
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/
> 
> This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap:
> 
>  1) A problem with concurrent resizes; and
> 
>  2) The skipping of elements when traversing through bins that are trees of entries.
> 
> Both of these issues can result in elements "disappearing" from the map, either because an update operation such as put failed, or because a contains operation failed to find the entry in the map.
> 
> Issue 1) was causing stream tests to fail intermittently on systems with many cores (24 to 32) (furthermore the CHM-based JDK test ToArray was also intermittently failing with less frequency). 
> 
> After some investigation the cause was distilled down to the use of ConcurrentHashMap in the F/J task used by Stream.forEachOrdered. 
> 
> Issue 2) was serendipitously reported on concurrentcy-interest just yesterday :-)
> 
> Both issues have test cases associated with them that have been tuned to reproduce on systems with low cores i.e. my MacBook!
> 
> Paul.


From sundararajan.athijegannathan at oracle.com  Wed Dec  4 10:31:17 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 04 Dec 2013 10:31:17 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20131204103123.EEAC662A4E@hg.openjdk.java.net>

Changeset: e0b4483668a7
Author:    jlaskey
Date:      2013-11-26 11:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e0b4483668a7

8029173: Debugger support doesn't handle ConsString
Reviewed-by: lagergren, hannesw, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/DebuggerSupport.java

Changeset: c14fe3f90616
Author:    sundar
Date:      2013-12-04 14:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c14fe3f90616

Merge




From chris.hegarty at oracle.com  Wed Dec  4 11:00:05 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Dec 2013 11:00:05 +0000
Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value
	to the map
In-Reply-To: 
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
	
Message-ID: <529F0B35.7090202@oracle.com>

On 04/12/13 10:31, Paul Sandoz wrote:
> I have reviewed Doug's code, just need someone to quickly review the test code.

The tests look pretty comprehensive to me. I see no issues with them.

-Chris.

>
> Paul.
>
> On Dec 2, 2013, at 5:29 PM, Paul Sandoz  wrote:
>
>> Hi,
>>
>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/
>>
>> This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap:
>>
>>   1) A problem with concurrent resizes; and
>>
>>   2) The skipping of elements when traversing through bins that are trees of entries.
>>
>> Both of these issues can result in elements "disappearing" from the map, either because an update operation such as put failed, or because a contains operation failed to find the entry in the map.
>>
>> Issue 1) was causing stream tests to fail intermittently on systems with many cores (24 to 32) (furthermore the CHM-based JDK test ToArray was also intermittently failing with less frequency).
>>
>> After some investigation the cause was distilled down to the use of ConcurrentHashMap in the F/J task used by Stream.forEachOrdered.
>>
>> Issue 2) was serendipitously reported on concurrentcy-interest just yesterday :-)
>>
>> Both issues have test cases associated with them that have been tuned to reproduce on systems with low cores i.e. my MacBook!
>>
>> Paul.
>


From Alan.Bateman at oracle.com  Wed Dec  4 11:22:12 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Dec 2013 11:22:12 +0000
Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value
	to the map
In-Reply-To: 
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
	
Message-ID: <529F1064.1060703@oracle.com>

On 04/12/2013 10:31, Paul Sandoz wrote:
> I have reviewed Doug's code, just need someone to quickly review the test code.
>
> Paul.
>
Tests looks good, I guess I would use shorter names as the directory 
name makes it clear that the tests are for ConcurrentHashMap but that is 
a minor point.

-Alan.


From joel.franck at oracle.com  Wed Dec  4 12:27:24 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Wed, 4 Dec 2013 13:27:24 +0100
Subject: JDK 8 RFR for JDK-8023471,,Add compatibility note to
	AnnotatedElement
In-Reply-To: <529EEDCA.3070201@oracle.com>
 <529EBC5B.1000209@oracle.com>
Message-ID: <20131204122724.GE1061@oracle.com>

Hi Joe, Stuart,

I think this looks good enough but Stuart has a point.

Perhaps add that it is a binary compatible change to make an annotation
type repeatable to begin with.

cheers
/Joel

On 2013-12-04, Stuart Marks wrote:
> Hi Joe,
> 
> The changes look sensible to me. Funnily enough, when I read the
> next, the voice echoing in my head sounds like Alex's....
> 
> A small clarification:
> 
> >+ * 
  •  The addition of the additional annotations is both source
> >+ * compatible and binary compatible. That is, the source containing
> >+ * the element and its annotations will still compile and the class
> >+ * file resulting from the compilation will continue to link.
> 
> This seems to imply that binary compatibility is with respect to the
> binary resulting from having recompiled the source. I have no doubt
> that such a binary will link successfully, but that's not quite what
> I had expected when I read "binary compatibility".
> 
> I would think that binary compatibility in this context would refer
> to clients that have *not* been recompiled, but which are linked
> with a newer version of the library that has changed to allow
> repeating annotations. Or perhaps it would refer to an old class
> binary that *uses an annotation, being linked with a library that
> *defines* that annotation, whose definition has been changed to
> allow that annotation to repeat. I don't know if these are real
> issues, but they're what came to mind when "binary compatibility"
> was mentioned.
> 
> The statement in the paragraph I quoted above would seem more
> sensible to me if the mention of "binary compatible" were struck.
> 

On 2013-12-03, Joe Darcy wrote:
> Hello,
> 
> Please review the patch below to address
> 
>     JDK-8023471 Add compatibility note to AnnotatedElement
> 
> Thanks,
> 
> -Joe
> 
> diff -r cd4aabc40f72
> src/share/classes/java/lang/reflect/AnnotatedElement.java
> --- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue
> Dec 03 11:52:18 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue
> Dec 03 21:23:16 2013 -0800
> @@ -135,7 +135,63 @@
>   * annotations on E are directly present on E in place
>   * of their container annotation, in the order in which they appear in
>   * the value element of the container annotation.
> -
> + *
> + * 
    There are several compatibility concerns to keep in mind if an
> + * annotation type T is not repeatable in one release
> + * of a library and retrofitted to be repeatable in a subsequent
> + * release.
> + *
> + * 
      
> + *
> + * 
    • If an annotation of type T is present on an
> + * element and T is made repeatable and more annotations of
> + * type T are added to the element:
> + *
> + *
> + * 
        
> + *
> + * 
      •  The addition of the additional annotations is both source
> + * compatible and binary compatible. That is, the source containing
> + * the element and its annotations will still compile and the class
> + * file resulting from the compilation will continue to link.
> + *
> + * 
      • The addition of the additional annotations is not
> + * behaviorally compatible with respect to the {@code
> + * get[Declared]Annotation(Class)} methods and {@code
> + * get[Declared]Annotations()} methods, because those methods will now
> + * only see a container annotations on the element and not see an
> + * annotation of type T.
> + *
> + * 
      
> + *
> + * 
    • If an annotation type TC is present
> + * on an element, then making some other annotation type T
> + * repeatable with TC as its containing annotation type then:
> + *
> + * 
        
> + *
> + * 
      • The change to Tis source and binary compatible with
> + * existing uses of annotations of type T as well as
> + * annotations of type TC.
> + *
> + * 
      • The change to T is behaviorally compatible with respect
> + * to the {@code get[Declared]Annotation(Class)} (called with an
> + * argument of T or TC) and {@code
> + * get[Declared]Annotations()} methods because the results of the
> + * methods will not change due to TC becoming the containing
> + * annotation type for T.
> + *
> + * 
      • The change to T is not behaviorally compatible
> + * with respect to the {@code
> + * get[Declared]AnnotationsByType(Class)} methods, because those
> + * methods will now recognize an annotation of type TC as a
> + * container annotation and "look through" it to expose annotations of
> + * type T.
> + *
> + * 
      
> + *
> + * 
    
> + *
>   * 
    If an annotation returned by a method in this interface contains
>   * (directly or indirectly) a {@link Class}-valued member referring to
>   * a class that is not accessible in this VM, attempting to read the class
> 


From chris.hegarty at oracle.com  Wed Dec  4 14:16:17 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Dec 2013 14:16:17 +0000
Subject: RFR (trivial) 8029141: Add @FunctionalInterface annotation to Callable
	interface
Message-ID: <529F3931.6080109@oracle.com>

A trivial one on our JDK8 list. Doug has already accepted this into the 
166 CVS.

Stuart brought this up a while back, and given our short deadline to get 
doc changes into jdk8. I'll just go ahead with the review now on his 
behalf. I have already review this.

The @FunctionalInterface annotation should to be added to the 
java.util.concurrent.Callable interface, see 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022729.html 


diff -r 4d9078b1f25b src/share/classes/java/util/concurrent/Callable.java
--- a/src/share/classes/java/util/concurrent/Callable.java      Tue Nov 
26 14:49:55 2013 +0900
+++ b/src/share/classes/java/util/concurrent/Callable.java      Wed Nov 
27 13:10:39 2013 -0800
@@ -54,6 +54,7 @@
   * @author Doug Lea
   * @param  the result type of method {@code call}
   */
+ at FunctionalInterface
  public interface Callable {
      /**
       * Computes a result, or throws an exception if unable to do so.

-Chris.


From Alan.Bateman at oracle.com  Wed Dec  4 14:59:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Dec 2013 14:59:50 +0000
Subject: RFR (trivial) 8029141: Add @FunctionalInterface annotation to
	Callable interface
In-Reply-To: <529F3931.6080109@oracle.com>
References: <529F3931.6080109@oracle.com>
Message-ID: <529F4366.7000203@oracle.com>

On 04/12/2013 14:16, Chris Hegarty wrote:
> A trivial one on our JDK8 list. Doug has already accepted this into 
> the 166 CVS.
>
> Stuart brought this up a while back, and given our short deadline to 
> get doc changes into jdk8. I'll just go ahead with the review now on 
> his behalf. I have already review this.
>
This looks fine.

-Alan



From sean.coffey at oracle.com  Wed Dec  4 15:44:59 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 04 Dec 2013 15:44:59 +0000
Subject: RFR : 8029347 : sun/rmi/runtime/Log/checkLogging/CheckLogging.java
	fails in nightly intermittently
Message-ID: <529F4DFB.5030508@oracle.com>

Recent jdk8 builds seem to be more ambitious on the GC front. It turns 
out that we've no strong reference for the Logger being created in this 
testcase and it's collected before use.

Verified that test now passes.

suggested fix :

diff -r 28ca338366ff test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
--- a/test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java	Mon Nov 25 20:22:23 2013 -0800
+++ b/test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java	Wed Dec 04 15:22:42 2013 +0000
@@ -76,6 +76,7 @@
  public class CheckLogging {
      private static int REGISTRY_PORT = -1;
      private static String LOCATION;
+    private static Logger logger;
  
      private static final ByteArrayOutputStream clientCallOut =
          new ByteArrayOutputStream();
@@ -89,8 +90,8 @@
              System.err.println("set default stream");
              LogStream.setDefaultStream(new PrintStream(clientCallOut));
          } else {
-            Logger.getLogger("sun.rmi.client.call").
-                addHandler(new InternalStreamHandler(clientCallOut));
+            logger = Logger.getLogger("sun.rmi.client.call");
+            logger.addHandler(new InternalStreamHandler(clientCallOut));
          }
      }

regards,
Sean.


From Alan.Bateman at oracle.com  Wed Dec  4 15:51:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Dec 2013 15:51:27 +0000
Subject: RFR : 8029347 : sun/rmi/runtime/Log/checkLogging/CheckLogging.java
	fails in nightly intermittently
In-Reply-To: <529F4DFB.5030508@oracle.com>
References: <529F4DFB.5030508@oracle.com>
Message-ID: <529F4F7F.4040305@oracle.com>

On 04/12/2013 15:44, Se?n Coffey wrote:
> Recent jdk8 builds seem to be more ambitious on the GC front. It turns 
> out that we've no strong reference for the Logger being created in 
> this testcase and it's collected before use.
Thanks Sean, I've seen this fail many times recently due to the logger 
being GC'ed. The change looks good. At some point we should check to see 
if there are other tests that might have similar issues.

-Alan


From roger.riggs at oracle.com  Wed Dec  4 15:57:00 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 04 Dec 2013 10:57:00 -0500
Subject: RFR: 8028816: Add value-type notice to Optional* classes
In-Reply-To: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
References: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
Message-ID: <529F50CC.5090807@oracle.com>

Hi Mike,

It is cleaner specification avoid mixing normative language and 
informative language in the same sentence.

"..may have unpredictable effects and should be avoided"


The first part is specifying the unpredictable behavior and the 2nd part 
is advice to a user of the API.

"may" is weak language, it is cleaner/clearer to say it is unpredictable 
without qualification.

I believe it is preferred to use "{@docRoot}" instead of ".." for the 
link reference in java.util.Optional

$.02, Roger

p.s. I did not find the discussion mentioned at the link to the lambda 
archive.

On 12/3/2013 5:21 PM, Mike Duigou wrote:
> Hello all;
>
> There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/
>
> I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not.
>
> Mike



From henry.jen at oracle.com  Wed Dec  4 16:15:43 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 04 Dec 2013 16:15:43 +0000
Subject: hg: jdk8/tl/jdk: 8029434: Spliterator of Stream returned by
	BufferedReader.lines() should have NONNULL characteristic
Message-ID: <20131204161558.0CCA862A57@hg.openjdk.java.net>

Changeset: 6d583b9d99e1
Author:    henryjen
Date:      2013-12-04 08:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d583b9d99e1

8029434: Spliterator of Stream returned by BufferedReader.lines() should have NONNULL characteristic
Reviewed-by: mduigou

! src/share/classes/java/io/BufferedReader.java
! test/java/io/BufferedReader/Lines.java



From mandy.chung at oracle.com  Wed Dec  4 16:44:32 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 04 Dec 2013 08:44:32 -0800
Subject: RFR : 8029347 : sun/rmi/runtime/Log/checkLogging/CheckLogging.java
	fails in nightly intermittently
In-Reply-To: <529F4F7F.4040305@oracle.com>
References: <529F4DFB.5030508@oracle.com> <529F4F7F.4040305@oracle.com>
Message-ID: <529F5BF0.3020403@oracle.com>


On 12/4/2013 7:51 AM, Alan Bateman wrote:
> On 04/12/2013 15:44, Se?n Coffey wrote:
>> Recent jdk8 builds seem to be more ambitious on the GC front. It 
>> turns out that we've no strong reference for the Logger being created 
>> in this testcase and it's collected before use.
> Thanks Sean, I've seen this fail many times recently due to the logger 
> being GC'ed. The change looks good. At some point we should check to 
> see if there are other tests that might have similar issues.

Agree.  We should probably consider having a test library method 
creating a logger that hopefully the new tests can avoid running into 
the same issue.

Mandy


From sean.coffey at oracle.com  Wed Dec  4 17:05:14 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Wed, 04 Dec 2013 17:05:14 +0000
Subject: hg: jdk8/tl/jdk: 8029347:
	sun/rmi/runtime/Log/checkLogging/CheckLogging.java fails in
	nightly intermittently
Message-ID: <20131204170535.825A262A58@hg.openjdk.java.net>

Changeset: 0f1332dd805c
Author:    coffeys
Date:      2013-12-04 17:03 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f1332dd805c

8029347: sun/rmi/runtime/Log/checkLogging/CheckLogging.java fails in nightly intermittently
Reviewed-by: alanb

! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java



From forax at univ-mlv.fr  Wed Dec  4 17:09:58 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 04 Dec 2013 18:09:58 +0100
Subject: RFR (trivial) 8029141: Add @FunctionalInterface annotation to
	Callable interface
In-Reply-To: <529F4366.7000203@oracle.com>
References: <529F3931.6080109@oracle.com> <529F4366.7000203@oracle.com>
Message-ID: <529F61E6.9000005@univ-mlv.fr>

On 12/04/2013 03:59 PM, Alan Bateman wrote:
> On 04/12/2013 14:16, Chris Hegarty wrote:
>> A trivial one on our JDK8 list. Doug has already accepted this into 
>> the 166 CVS.
>>
>> Stuart brought this up a while back, and given our short deadline to 
>> get doc changes into jdk8. I'll just go ahead with the review now on 
>> his behalf. I have already review this.
>>
> This looks fine.
>
> -Alan
>

yes,

R?mi



From forax at univ-mlv.fr  Wed Dec  4 17:37:16 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 04 Dec 2013 18:37:16 +0100
Subject: RFR: 8028816: Add value-type notice to Optional* classes
In-Reply-To: <529E8E27.6070706@oracle.com>
References: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com>
	<529E8E27.6070706@oracle.com>
Message-ID: <529F684C.2030206@univ-mlv.fr>

On 12/04/2013 03:06 AM, Stuart Marks wrote:
> Overall looks fine.
>
> If you're listing yourself as the reviewer, jcheck will object if 
> you're also the changeset author. Instead of listing Brian Goetz in 
> Contributed-by, make him the changeset author instead. Using MQ, do 
> "hg qref -u briangoetz".
>
> The gist of the paragraph being added to each class is,
>
>     Use of identity-sensitive operations ... on instances of 
>     may have unpredictable effects and should be avoided.
>
> The phrase "unpredictable effects" strikes me oddly. This phrase is 
> also used at the very end of the HTML doc. It makes it sound as if 
> using an identity-sensitive operation might have side effects. That 
> won't be the case, as far as I know. Using such an operation will 
> indeed have "unpredictable results". That phrase is used at the 
> beginning of the last paragraph of the HTML doc, and it makes much 
> more sense to me than "unpredictable effects".
>
> s'marks

Hi Stuart,
the worst thing you can have is an allocation which is IMO a side effect.

R?mi

>
>
>
> On 12/3/13 2:21 PM, Mike Duigou wrote:
>> Hello all;
>>
>> There's been a discussion on the lambda spec experts list 
>> (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about 
>> adding a notice to the Optional classes about implications of their 
>> likely future as values. This discussion recently completed so now 
>> there's a doc patch to review:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/
>>
>> I have already reviewed this but will hold off pushing it for a few 
>> hours in case someone notices a mistake that I did not.
>>
>> Mike
>>



From erik.joelsson at oracle.com  Wed Dec  4 17:35:55 2013
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 04 Dec 2013 17:35:55 +0000
Subject: hg: jdk8/tl: 8027963: Create unlimited policy jars.
Message-ID: <20131204173555.408D062A5F@hg.openjdk.java.net>

Changeset: c009462c1e92
Author:    erikj
Date:      2013-12-04 12:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c009462c1e92

8027963: Create unlimited policy jars.
Reviewed-by: wetmore, ihse

! common/autoconf/spec.gmk.in



From chris.hegarty at oracle.com  Mon Dec  2 18:23:45 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 2 Dec 2013 18:23:45 +0000
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
	files to build the class library on AIX
In-Reply-To: 
References: 
	
	<5294D453.5050402@oracle.com>
	
Message-ID: 


On 26 Nov 2013, at 18:08, Iris Clark wrote:

>> So overall it looks good to me and should be pushed to the staging > forest once you hear from others that commented previously.
> 
> I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov.  Alan, please correct me if I'm wrong.

I'm ok with these changes going into the staging forest as are.

-Chris.

> 
> Thanks,
> iris
> 
> -----Original Message-----
> From: Alan Bateman 
> Sent: Tuesday, November 26, 2013 9:03 AM
> To: Volker Simonis
> Cc: Vladimir Kozlov; 2d-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev; ppc-aix-port-dev at openjdk.java.net; awt-dev at openjdk.java.net; Java Core Libs; net-dev
> Subject: Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX
> 
> On 26/11/2013 16:23, Volker Simonis wrote:
>> Hi,
>> 
>> thanks to everybody for the prompt and helpful reviews. Here comes the 
>> final webrev which incorporates all the corrections and suggestions 
>> from the second review round:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>> 
>> I've successfully build (and run some smoke tests) with these changes 
>> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
>> MacOSX and AIX (5.3, 7.1).
>> 
> I've skimmed over the last webrev with focus on:
> 
> NetworkingLibraries.gmk where I see this is now fixed for all platforms.
> 
> net_util.* and the platform specific net_util_md.* where I see you've added platformInit so it's much cleaner.
> 
> UnixNativeDispatcher.c where the error translation is now removed (and looks fine).
> 
> So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously.
> 
> -Alan



From chris.hegarty at oracle.com  Wed Dec  4 18:04:03 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 04 Dec 2013 18:04:03 +0000
Subject: hg: jdk8/tl/jdk: 8029141: Add @FunctionalInterface annotation to
	Callable interface
Message-ID: <20131204180421.359A262A66@hg.openjdk.java.net>

Changeset: 2a6611ebfb6c
Author:    smarks
Date:      2013-12-04 18:02 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a6611ebfb6c

8029141: Add @FunctionalInterface annotation to Callable interface
Reviewed-by: chegar, alanb

! src/share/classes/java/util/concurrent/Callable.java



From michael.fang at oracle.com  Wed Dec  4 17:35:22 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 04 Dec 2013 17:35:22 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131204173607.36EFE62A60@hg.openjdk.java.net>

Changeset: 6a5a54193118
Author:    mfang
Date:      2013-12-04 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a5a54193118

8027244: Need to translate new error message and usage information for jar tool
Reviewed-by: naoto, yhuang

! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties

Changeset: bfe3a26a2c5e
Author:    mfang
Date:      2013-12-04 09:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfe3a26a2c5e

Merge

- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh



From mandy.chung at oracle.com  Wed Dec  4 17:28:54 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 04 Dec 2013 17:28:54 +0000
Subject: hg: jdk8/tl/jdk: 7067973:
	test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
	hanging intermittently
Message-ID: <20131204172907.E7CF162A5A@hg.openjdk.java.net>

Changeset: a3b804e3d5f7
Author:    mchung
Date:      2013-12-04 09:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3b804e3d5f7

7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently
Reviewed-by: mchung
Contributed-by: yiming.wang at oracle.com

! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh



From alex.buckley at oracle.com  Wed Dec  4 19:30:07 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 04 Dec 2013 11:30:07 -0800
Subject: JDK 8 RFR for JDK-8023471, ,
	Add compatibility note to AnnotatedElement
In-Reply-To: <529EBC5B.1000209@oracle.com>
References: <529EBC5B.1000209@oracle.com>
Message-ID: <529F82BF.3010503@oracle.com>

On 12/3/2013 9:23 PM, Joe Darcy wrote:
> + *
> + * 
    There are several compatibility concerns to keep in mind if an
> + * annotation type T is not repeatable in one release
> + * of a library and retrofitted to be repeatable in a subsequent
> + * release.

The term "retrofitted" is linguistically correct but I think it's a bit 
jarring to say something is retrofitted in a _subsequent_ release. Too 
many frames of reference. How about just "modified" to be repeatable?

> + * 
      
> + *
> + * 
    • If an annotation of type T is present on an
> + * element and T is made repeatable and more annotations of
> + * type T are added to the element:
> + *
> + *
> + * 
        
> + *
> + * 
      •  The addition of the additional annotations is both source
> + * compatible and binary compatible. That is, the source containing
> + * the element and its annotations will still compile and the class
> + * file resulting from the compilation will continue to link.
> + *
> + * 
      • The addition of the additional annotations is not
> + * behaviorally compatible with respect to the {@code
> + * get[Declared]Annotation(Class)} methods and {@code
> + * get[Declared]Annotations()} methods, because those methods will now
> + * only see a container annotations on the element and not see an
> + * annotation of type T.
> + *
> + * 
      

"The addition of the annotations is both source compatible and binary 
compatible. That is, the _source code_ containing the annotated element 
will still compile, and class files will link against the newly compiled 
class file if they linked against the older class file."

"The addition of the annotations is not behaviorally ... because those 
methods will now return a _container annotation_ /* no plural */ on the 
element rather than an annotation of type T."

What happened to the paragraph about get[Declared]AnnotationsByType ?

> + * 
    • If an annotation type TC is present
> + * on an element, then making some other annotation type T
> + * repeatable with TC as its containing annotation type then:

The first "then" should become "and some other annotation type T is made 
repeatable with TC as its containing annotation type, then:"

> + * 
        
> + *
> + * 
      • The change to Tis source and binary compatible with
> + * existing uses of annotations of type T as well as
> + * annotations of type TC.

The effect of making T repeatable on existing annotations was covered 
earlier. This paragraph was meant to be about how code which said @TC is 
still compilable and linkable even after TC became someone's containing 
annotation type:

"The change to T is both source compatible and binary compatible for TC. 
That is, source code containing annotations of type TC will still 
compile, and class files will still link against the resulting class file."

> + * 
      • The change to T is behaviorally compatible with respect
> + * to the {@code get[Declared]Annotation(Class)} (called with an
> + * argument of T or TC) and {@code
> + * get[Declared]Annotations()} methods because the results of the
> + * methods will not change due to TC becoming the containing
> + * annotation type for T.
> + *
> + * 
      • The change to T is not behaviorally compatible
> + * with respect to the {@code
> + * get[Declared]AnnotationsByType(Class)} methods, because those
> + * methods will now recognize an annotation of type TC as a
> + * container annotation and "look through" it to expose annotations of
> + * type T.

Reading this, I would be inclined to swap the major order of the new 
text. First, say what happens when T is made repeatable _before even one 
more @T annotation is written anywhere_. Second, say what happens when 
@T is repeated.

Alex


From stuart.marks at oracle.com  Wed Dec  4 19:55:01 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Dec 2013 11:55:01 -0800
Subject: RFR : 8029347 : sun/rmi/runtime/Log/checkLogging/CheckLogging.java
	fails in nightly intermittently
In-Reply-To: <529F4DFB.5030508@oracle.com>
References: <529F4DFB.5030508@oracle.com>
Message-ID: <529F8895.3020706@oracle.com>

I see this was pushed already. Good, quick work guys!

Yes, there are a couple other RMI test failures caused by aggressive GC of 
loggers (or possibly other objects). I know the Hotspot folks have filed a 
couple already. But we should keep an eye out for them.

s'marks

On 12/4/13 7:44 AM, Se?n Coffey wrote:
> Recent jdk8 builds seem to be more ambitious on the GC front. It turns out that
> we've no strong reference for the Logger being created in this testcase and it's
> collected before use.
>
> Verified that test now passes.
>
> suggested fix :
>
> diff -r 28ca338366ff test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
> --- a/test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java    Mon Nov 25
> 20:22:23 2013 -0800
> +++ b/test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java    Wed Dec 04
> 15:22:42 2013 +0000
> @@ -76,6 +76,7 @@
>   public class CheckLogging {
>       private static int REGISTRY_PORT = -1;
>       private static String LOCATION;
> +    private static Logger logger;
>
>       private static final ByteArrayOutputStream clientCallOut =
>           new ByteArrayOutputStream();
> @@ -89,8 +90,8 @@
>               System.err.println("set default stream");
>               LogStream.setDefaultStream(new PrintStream(clientCallOut));
>           } else {
> -            Logger.getLogger("sun.rmi.client.call").
> -                addHandler(new InternalStreamHandler(clientCallOut));
> +            logger = Logger.getLogger("sun.rmi.client.call");
> +            logger.addHandler(new InternalStreamHandler(clientCallOut));
>           }
>       }
>
> regards,
> Sean.


From stuart.marks at oracle.com  Wed Dec  4 19:58:24 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Dec 2013 11:58:24 -0800
Subject: JDK 8 RFR for JDK-8023471, ,
	Add compatibility note to AnnotatedElement
In-Reply-To: <529F82BF.3010503@oracle.com>
References: <529EBC5B.1000209@oracle.com> <529F82BF.3010503@oracle.com>
Message-ID: <529F8960.7080501@oracle.com>



On 12/4/13 11:30 AM, Alex Buckley wrote:
> On 12/3/2013 9:23 PM, Joe Darcy wrote:
>> + * 
      •  The addition of the additional annotations is both source
>> + * compatible and binary compatible. That is, the source containing
>> + * the element and its annotations will still compile and the class
>> + * file resulting from the compilation will continue to link.
>
> "The addition of the annotations is both source compatible and binary
> compatible. That is, the _source code_ containing the annotated element will
> still compile, and class files will link against the newly compiled class file
> if they linked against the older class file."

Thanks Alex, this addresses the concern I had raised about use of the term 
"binary compatible."

s'marks


From roger.riggs at oracle.com  Wed Dec  4 20:00:25 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 04 Dec 2013 15:00:25 -0500
Subject: RFR: Add value-type notice to java.time classes
Message-ID: <529F89D9.5030103@oracle.com>

Following the lead of the notices added to Optional, the java.time value 
based
classes should include the same notice.

Please review:
    http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/

Thanks, Roger




From xueming.shen at oracle.com  Wed Dec  4 20:42:23 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 04 Dec 2013 12:42:23 -0800
Subject: RFR: Add value-type notice to java.time classes
In-Reply-To: <529F89D9.5030103@oracle.com>
References: <529F89D9.5030103@oracle.com>
Message-ID: <529F93AF.4030005@oracle.com>

On 12/04/2013 12:00 PM, roger riggs wrote:
> Following the lead of the notices added to Optional, the java.time value based
> classes should include the same notice.
>
> Please review:
>    http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/
>
> Thanks, Roger
>
>

http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/src/share/classes/java/time/ZonedDateTime.java.sdiff.html

LD -> ZDT


From roger.riggs at oracle.com  Wed Dec  4 21:08:26 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 04 Dec 2013 16:08:26 -0500
Subject: RFR: Add value-type notice to java.time classes
In-Reply-To: <529F93AF.4030005@oracle.com>
References: <529F89D9.5030103@oracle.com> <529F93AF.4030005@oracle.com>
Message-ID: <529F99CA.7010905@oracle.com>

Corrected.

Thanks, Roger

On 12/4/2013 3:42 PM, Xueming Shen wrote:
> On 12/04/2013 12:00 PM, roger riggs wrote:
>> Following the lead of the notices added to Optional, the java.time 
>> value based
>> classes should include the same notice.
>>
>> Please review:
>> http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/
>>
>> Thanks, Roger
>>
>>
>
> http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/src/share/classes/java/time/ZonedDateTime.java.sdiff.html 
>
>
> LD -> ZDT



From brian.burkhalter at oracle.com  Wed Dec  4 21:34:42 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 4 Dec 2013 13:34:42 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java failing
	since thresholds adjusted in 8022181
Message-ID: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>

Hello,

Issue:	https://bugs.openjdk.java.net/browse/JDK-8029514
Webrev:	http://cr.openjdk.java.net/~bpb/8029514/webrev/

The problem causing this failure is that the method getLower() used by Karatsuba multiplication is expected to return an unsigned value but instead returns 'this' if the parameter 'n' is not greater than the int-length of the BigInteger on which it is invoked. For multiplications in which there is a negative factor this could result in an incorrect product being obtained.

The BigIntegerTest is also updated to reflect the modified thresholds (should have been in the patch for 8022181 but was not ?).

Thanks,

Brian

From mandy.chung at oracle.com  Wed Dec  4 21:38:05 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 04 Dec 2013 21:38:05 +0000
Subject: hg: jdk8/tl/jdk: 8029552: Remove
	java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
	from ProblemList.txt
Message-ID: <20131204213817.AF80062A7D@hg.openjdk.java.net>

Changeset: 4345e3e82c55
Author:    mchung
Date:      2013-12-04 13:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4345e3e82c55

8029552: Remove java/lang/management/MemoryMXBean/CollectionUsageThreshold.java from ProblemList.txt
Reviewed-by: alanb

! test/ProblemList.txt



From mandy.chung at oracle.com  Wed Dec  4 23:41:57 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 04 Dec 2013 23:41:57 +0000
Subject: hg: jdk8/tl/langtools: 8029216: (jdeps) Provide a specific option to
	report JDK internal APIs
Message-ID: <20131204234200.EB76062A7F@hg.openjdk.java.net>

Changeset: 4a2ed1900428
Author:    mchung
Date:      2013-12-04 15:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a2ed1900428

8029216: (jdeps) Provide a specific option to report JDK internal APIs
Reviewed-by: alanb

! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
! test/tools/jdeps/APIDeps.java



From joe.darcy at oracle.com  Thu Dec  5 00:18:57 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Wed, 04 Dec 2013 16:18:57 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>
Message-ID: <529FC671.2020704@oracle.com>

Hi Brian,

I've taken a look at the change, but I don't understand why the problem 
wasn't surfaced before?

-Joe

On 12/4/2013 1:34 PM, Brian Burkhalter wrote:
> Hello,
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8029514
> Webrev:	http://cr.openjdk.java.net/~bpb/8029514/webrev/
>
> The problem causing this failure is that the method getLower() used by Karatsuba multiplication is expected to return an unsigned value but instead returns 'this' if the parameter 'n' is not greater than the int-length of the BigInteger on which it is invoked. For multiplications in which there is a negative factor this could result in an incorrect product being obtained.
>
> The BigIntegerTest is also updated to reflect the modified thresholds (should have been in the patch for 8022181 but was not ?).
>
> Thanks,
>
> Brian



From brian.burkhalter at oracle.com  Thu Dec  5 00:18:36 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 4 Dec 2013 16:18:36 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <529FC671.2020704@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>
	<529FC671.2020704@oracle.com>
Message-ID: 

Hi Joe,

Neither do I. It just did not turn up in the tests conducted.

Brian

On Dec 4, 2013, at 4:18 PM, Joseph Darcy wrote:

> I've taken a look at the change, but I don't understand why the problem wasn't surfaced before?



From stuart.marks at oracle.com  Thu Dec  5 01:02:33 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Dec 2013 17:02:33 -0800
Subject: Initial with JDK-7168267
In-Reply-To: <147942d4-f052-4403-b374-3d3ed59e7175@default>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>
Message-ID: <529FD0A9.9020400@oracle.com>

On 12/3/13 11:05 PM, Tristan Yan wrote:
> I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is
> asking performance improvement for RMI test. Because this would involve
> different RMI tests. I?d like to use this cr as an umbrella bug, create sub-cr
> for different test. Then I can make progress on sub-cr. Please let me know your
> opinion on this.

Actually JDK-7168267 is more about various test cleanups, and JDK-8005436 is 
more about performance. Both bugs, though, make general statements about "the 
RMI tests" and don't have much information about specific actions that need to 
be taken. I've added some notes to JDK-7168267 about some cleanups that could be 
done.

If there are specific actions for either of these bugs, then yes, creating 
Sub-Tasks of these bugs and fixing them individually is the right thing to do.

s'marks


From joe.darcy at oracle.com  Thu Dec  5 01:58:32 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 04 Dec 2013 17:58:32 -0800
Subject: JDK 8 RFR for JDK-8023471, ,
	Add compatibility note to AnnotatedElement
In-Reply-To: <529F8960.7080501@oracle.com>
References: <529EBC5B.1000209@oracle.com> <529F82BF.3010503@oracle.com>
	<529F8960.7080501@oracle.com>
Message-ID: <529FDDC8.7060208@oracle.com>

On 12/04/2013 11:58 AM, Stuart Marks wrote:
>
>
> On 12/4/13 11:30 AM, Alex Buckley wrote:
>> On 12/3/2013 9:23 PM, Joe Darcy wrote:
>>> + * 
      •  The addition of the additional annotations is both source
>>> + * compatible and binary compatible. That is, the source containing
>>> + * the element and its annotations will still compile and the class
>>> + * file resulting from the compilation will continue to link.
>>
>> "The addition of the annotations is both source compatible and binary
>> compatible. That is, the _source code_ containing the annotated 
>> element will
>> still compile, and class files will link against the newly compiled 
>> class file
>> if they linked against the older class file."
>
> Thanks Alex, this addresses the concern I had raised about use of the 
> term "binary compatible."
>
>

Thanks all for the feedback. I revised patch below to address the 
concerns that have been raised. Additionally, I added a "see 
compatibility discussion in AnnotatedElement" note to 
java.lang.annotation.Annotation.

Thanks,

-Joe

diff -r cd4aabc40f72 src/share/classes/java/lang/annotation/Annotation.java
--- a/src/share/classes/java/lang/annotation/Annotation.java    Tue Dec 
03 11:52:18 2013 -0800
+++ b/src/share/classes/java/lang/annotation/Annotation.java    Wed Dec 
04 17:56:47 2013 -0800
@@ -34,6 +34,10 @@
   * More information about annotation types can be found in section 9.6 of
   * The Java™ Language Specification.
   *
+ * The {@link java.lang.reflect.AnnotatedElement} interface discusses
+ * compatibility concerns when evolving an annotation type from being
+ * non-repeatable to being repeatable.
+ *
   * @author  Josh Bloch
   * @since   1.5
   */
diff -r cd4aabc40f72 
src/share/classes/java/lang/reflect/AnnotatedElement.java
--- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Tue Dec 
03 11:52:18 2013 -0800
+++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Wed Dec 
04 17:56:47 2013 -0800
@@ -135,7 +135,78 @@
   * annotations on E are directly present on E in place
   * of their container annotation, in the order in which they appear in
   * the value element of the container annotation.
-
+ *
+ * 
        There are several compatibility concerns to keep in mind if an
+ * annotation type T is originally not repeatable and
+ * later modified to be repeatable.
+ *
+ * The containing annotation type for T is TC.
+ *
+ * 
          
+ *
+ * 
        • Modifying T to be repeatable is source and binary
+ * compatible with existing uses of T and with existing uses
+ * of TC.
+ *
+ * That is, for source compatibility, source code with annotations of
+ * type T or of type TC will still compile. For binary
+ * compatibility, class files with annotations of type T or of
+ * type TC (or with other kinds of uses of type T or of
+ * type TC) will link against the modified version of T
+ * if they linked against the earlier version.
+ *
+ * (An annotation type TC may informally serve as an acting
+ * containing annotation type before T is modified to be
+ * formally repeatable. Alternatively, when T is made
+ * repeatable, TC can be introduced as a new type.)
+ *
+ * 
        • If an annotation type TC is present on an element, and
+ * T is modified to be repeatable with TC as its
+ * containing annotation type then:
+ *
+ * 
            
+ *
+ * 
          • The change to T is behaviorally compatible with respect
+ * to the {@code get[Declared]Annotation(Class)} (called with an
+ * argument of T or TC) and {@code
+ * get[Declared]Annotations()} methods because the results of the
+ * methods will not change due to TC becoming the containing
+ * annotation type for T.
+ *
+ * 
          • The change to T is not behaviorally compatible
+ * with respect to the {@code
+ * get[Declared]AnnotationsByType(Class)} methods, because those
+ * methods will now recognize an annotation of type TC as a
+ * container annotation and will "look through" it to expose
+ * annotations of type T.
+ *
+ * 
          
+ *
+ * 
        • If an annotation of type T is present on an
+ * element and T is made repeatable and more annotations of
+ * type T are added to the element:
+ *
+ * 
            
+ *
+ * 
          •  The addition of the additional annotations is both source
+ * compatible and binary compatible.
+ *
+ * 
          • The addition of the additional annotations changes the results
+ * of the {@code get[Declared]Annotation(Class)} methods and {@code
+ * get[Declared]Annotations()} methods, because those methods will now
+ * only see a container annotation on the element and not see an
+ * annotation of type T.
+ *
+ * 
          • The addition of the additional annotations changes the results
+ * of the {@code get[Declared]AnnotationsByType(Class)} methods,
+ * because their results will expose the additional annotations of
+ * type T whereas previously they exposed only a single
+ * annotation of type T.
+ *
+ * 
          
+ *
+ * 
        
+ *
   * 
        If an annotation returned by a method in this interface contains
   * (directly or indirectly) a {@link Class}-valued member referring to
   * a class that is not accessible in this VM, attempting to read the class




From eliasen at mindspring.com  Thu Dec  5 02:20:24 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Wed, 04 Dec 2013 19:20:24 -0700
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <529FC671.2020704@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>
	<529FC671.2020704@oracle.com>
Message-ID: <529FE2E8.5010506@mindspring.com>

> On 12/4/2013 1:34 PM, Brian Burkhalter wrote:
>> Hello,
>>
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8029514
>> Webrev:    http://cr.openjdk.java.net/~bpb/8029514/webrev/
>>
>> The problem causing this failure is that the method getLower() used by
>> Karatsuba multiplication is expected to return an unsigned value but
>> instead returns 'this' if the parameter 'n' is not greater than the
>> int-length of the BigInteger on which it is invoked. For
>> multiplications in which there is a negative factor this could result
>> in an incorrect product being obtained.
>>
>> The BigIntegerTest is also updated to reflect the modified thresholds
>> (should have been in the patch for 8022181 but was not ?).

   Hmmm... it looks like that patch is correct and necessary if
getLower() is receiving negative numbers.  I'm not quite sure what
happened there.  My vague recollection was that at one point the
arguments to Karatsuba multiply were conditioned to always be positive
in the multiply() dispatching function, but that's apparently not the
case in the current code.

   Thanks for letting me know about this.  I didn't see the earlier bug
report or the report that the thresholds were being changed.  It would
seem to me that the new thresholds are quite a bit higher than is
optimal for the architectures I tested on (Linux 64-bit and Windows 32
bit, and a bit of Raspberry Pi Arm); I intentionally set my thresholds
to be quite high and conservative.  Is there a particular architecture
that requires the thresholds to be set that high?  What performance
effect do those higher thresholds have on the most common architectures?

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From brian.burkhalter at oracle.com  Thu Dec  5 02:50:38 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 4 Dec 2013 18:50:38 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <529FE2E8.5010506@mindspring.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>
	<529FC671.2020704@oracle.com> <529FE2E8.5010506@mindspring.com>
Message-ID: <1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>


On Dec 4, 2013, at 6:20 PM, Alan Eliasen wrote:

>   Hmmm... it looks like that patch is correct and necessary if
> getLower() is receiving negative numbers.  I'm not quite sure what
> happened there.  My vague recollection was that at one point the
> arguments to Karatsuba multiply were conditioned to always be positive
> in the multiply() dispatching function, but that's apparently not the
> case in the current code.

Thanks for the comments. There is no guarantee that the factors will not be negative. The main thing is that it got caught before the release of 8.

>   Thanks for letting me know about this.  I didn't see the earlier bug
> report or the report that the thresholds were being changed.  It would
> seem to me that the new thresholds are quite a bit higher than is
> optimal for the architectures I tested on (Linux 64-bit and Windows 32
> bit, and a bit of Raspberry Pi Arm); I intentionally set my thresholds
> to be quite high and conservative.  Is there a particular architecture
> that requires the thresholds to be set that high?  What performance
> effect do those higher thresholds have on the most common architectures?

These thresholds are based on quite a few benchmark test runs on various architectures. I don't recall that there was any one particular architecture that was behind raising the thresholds. There was a lot of variability in the test runs and these values represent a best guess at retaining performance improvements afforded by the newer algorithms without provoking serious regressions. We intend to perform more testing on these thresholds on various platforms and to tune the thresholds as the data suggest. If you have any suggestion as to which are the most common architectures for these sorts of computations in your experience that would be welcome.

Thanks,

Brian

From joe.darcy at oracle.com  Thu Dec  5 02:56:58 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 04 Dec 2013 18:56:58 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>	<529FC671.2020704@oracle.com>
	<529FE2E8.5010506@mindspring.com>
	<1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
Message-ID: <529FEB7A.40708@oracle.com>

On 12/04/2013 06:50 PM, Brian Burkhalter wrote:
> On Dec 4, 2013, at 6:20 PM, Alan Eliasen wrote:
>
>>    Hmmm... it looks like that patch is correct and necessary if
>> getLower() is receiving negative numbers.  I'm not quite sure what
>> happened there.  My vague recollection was that at one point the
>> arguments to Karatsuba multiply were conditioned to always be positive
>> in the multiply() dispatching function, but that's apparently not the
>> case in the current code.
> Thanks for the comments. There is no guarantee that the factors will not be negative. The main thing is that it got caught before the release of 8.
>
>

Brian,

As a double-check, can you run the now failing regression test against 
the earlier versions of java.math.* between when Karatsuba and friends 
went in and the current version of the code?

Thanks,

-Joe


From brian.burkhalter at oracle.com  Thu Dec  5 03:32:20 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 4 Dec 2013 19:32:20 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <529FEB7A.40708@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>	<529FC671.2020704@oracle.com>
	<529FE2E8.5010506@mindspring.com>
	<1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
	<529FEB7A.40708@oracle.com>
Message-ID: <785DD2E0-4C5F-4237-A924-7C49E2F00BC1@oracle.com>

On Dec 4, 2013, at 6:56 PM, Joe Darcy wrote:

> As a double-check, can you run the now failing regression test against the earlier versions of java.math.* between when Karatsuba and friends went in and the current version of the code?

If I go back to rev 7466

changeset:   7466:9b802d99cb52
user:        bpb
date:        Wed Jun 19 08:59:39 2013 -0700
summary:     4837946: Faster multiplication and exponentiation of large integers

changeset:   4554:2a8072c7cf99
user:        darcy
date:        Wed Sep 14 11:32:11 2011 -0700
summary:     6879143: java.math.BigInteger misses the xxxValueExact methods

which is when Karatsuba, et. al., were introduced, then the code as-is in 7466 passes the test in question, but if I change the two multiplication thresholds to the current values without modifying anything else, the test fails with similar errors to what was observed for the current tip. It seems the threshold change exposes a different profile of numbers to the algorithm which reveals the problem. I highly doubt any intervening changes are behind this.

Brian

From joe.darcy at oracle.com  Thu Dec  5 04:02:19 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 04 Dec 2013 20:02:19 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <785DD2E0-4C5F-4237-A924-7C49E2F00BC1@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>	<529FC671.2020704@oracle.com>
	<529FE2E8.5010506@mindspring.com>
	<1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
	<529FEB7A.40708@oracle.com>
	<785DD2E0-4C5F-4237-A924-7C49E2F00BC1@oracle.com>
Message-ID: <529FFACB.5010206@oracle.com>

On 12/04/2013 07:32 PM, Brian Burkhalter wrote:
> On Dec 4, 2013, at 6:56 PM, Joe Darcy wrote:
>
>> As a double-check, can you run the now failing regression test 
>> against the earlier versions of java.math.* between when Karatsuba 
>> and friends went in and the current version of the code?
>
> If I go back to rev 7466
>
> changeset:   7466:9b802d99cb52
> user:        bpb
> date:        Wed Jun 19 08:59:39 2013 -0700
> summary:     4837946: Faster multiplication and exponentiation of 
> large integers
>
> changeset:   4554:2a8072c7cf99
> user:        darcy
> date:        Wed Sep 14 11:32:11 2011 -0700
> summary:     6879143: java.math.BigInteger misses the xxxValueExact 
> methods
>
> which is when Karatsuba, et. al., were introduced, then the code as-is 
> in 7466 passes the test in question, but if I change the two 
> multiplication thresholds to the current values without modifying 
> anything else, the test fails with similar errors to what was observed 
> for the current tip. It seems the threshold change exposes a different 
> profile of numbers to the algorithm which reveals the problem. I 
> highly doubt any intervening changes are behind this.
>
>


Thanks for going the experiment Brian. I'll approve the proposed change 
to BigInteger as long as the regression test includes a case which will 
fail when run against the uncorrected version of the code.

Alan, IIRC when you first sent the Karatsuba patch in you had a set of 
long-running validation tests. Could you rerun those tests on the 
version of BigInteger with the new thresholds and Brian's fix?

Thanks,

-Joe


From brian.burkhalter at oracle.com  Thu Dec  5 04:06:41 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 4 Dec 2013 20:06:41 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <529FFACB.5010206@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>	<529FC671.2020704@oracle.com>
	<529FE2E8.5010506@mindspring.com>
	<1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
	<529FEB7A.40708@oracle.com>
	<785DD2E0-4C5F-4237-A924-7C49E2F00BC1@oracle.com>
	<529FFACB.5010206@oracle.com>
Message-ID: <1742AABC-661E-4467-9EAC-4EAC47D44749@oracle.com>


On Dec 4, 2013, at 8:02 PM, Joe Darcy wrote:

> Thanks for going the experiment Brian. I'll approve the proposed change to BigInteger as long as the regression test includes a case which will fail when run against the uncorrected version of the code.

Joe, the regression test in the webrev satisfies the stated criterion.

Thanks,

Brian

From joe.darcy at oracle.com  Thu Dec  5 05:26:00 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 04 Dec 2013 21:26:00 -0800
Subject: JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java
	failing since thresholds adjusted in 8022181
In-Reply-To: <1742AABC-661E-4467-9EAC-4EAC47D44749@oracle.com>
References: <414FFC72-B80E-40B5-BBEE-EE86D123A892@oracle.com>	<529FC671.2020704@oracle.com>
	<529FE2E8.5010506@mindspring.com>
	<1EB1167F-4D8D-483E-9071-64B5A016AAF2@oracle.com>
	<529FEB7A.40708@oracle.com>
	<785DD2E0-4C5F-4237-A924-7C49E2F00BC1@oracle.com>
	<529FFACB.5010206@oracle.com>
	<1742AABC-661E-4467-9EAC-4EAC47D44749@oracle.com>
Message-ID: <52A00E68.5060701@oracle.com>

On 12/04/2013 08:06 PM, Brian Burkhalter wrote:
>
> On Dec 4, 2013, at 8:02 PM, Joe Darcy wrote:
>
>> Thanks for going the experiment Brian. I'll approve the proposed 
>> change to BigInteger as long as the regression test includes a case 
>> which will fail when run against the uncorrected version of the code.
>
> Joe, the regression test in the webrev satisfies the stated criterion.
>
>


Okay; then I approve the change in its current state.

Thanks,

-Joe


From zhangshj at linux.vnet.ibm.com  Thu Dec  5 06:54:13 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Thu, 05 Dec 2013 14:54:13 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <5298BB49.9040506@oracle.com>
References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com>
	<52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com>
	<52985D7C.8080703@oracle.com> <5298632C.5070701@linux.vnet.ibm.com>
	<52986791.5040306@oracle.com> <5298B919.6000909@oracle.com>
	<5298BB49.9040506@oracle.com>
Message-ID: <52A02315.3000605@linux.vnet.ibm.com>

On 11/30/2013 12:05 AM, Daniel Fuchs wrote:
> On 11/29/13 4:56 PM, Alan Bateman wrote:
>> On 29/11/2013 10:08, Daniel Fuchs wrote:
>>>
>>> However, removing or just moving the lock around might well 
>>> introduce new
>>> unknown issues - so it will need to be carefully anaIyzed, and I am
>>> not sure
>>> it can/should be attempted in a minor JDK release.
>>>
>> Yes, we have to be very careful as the logging code has a history of
>> biting the hand of those that try to improve it. For various reasons, it
>> seems there is a lot of code that has subtle dependencies on the
>> implementation, on the initialization in particular. In any case, you
>> are to be applauded for tackling the synchronization issues and it would
>> be a good project to re-examine all of this in JDK 9 to see how it would
>> be simplified.
>>
>> On documenting the locking details in an @implNote (which seems to be
>> one of the suggestions here) then we also need to be careful as I think
>> we need some flexibility to change some of this going forward.
>
> Yes - that's a two edged sword indeed. We certainly don't want to set
> that in stone... On the other hand I empathizes with developers who
> struggle to find out what they can - and can't do - when extending
> j.u.l APIs...
>
> Anyway, if usage of the 'synchronized' keyword never appears in
> the Javadoc I guess that's for good reasons...
>
> Thanks Alan,
>
> -- daniel
>
>>
>> -Alan
>
Hi Daniel,

This thread is silent for several days, do you have any finding in 
Handler.publish?

-- 
Regards,

Shi Jun Zhang



From paul.sandoz at oracle.com  Thu Dec  5 09:08:33 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 05 Dec 2013 09:08:33 +0000
Subject: hg: jdk8/tl/jdk: 8028564: Concurrent calls to CHM.put can fail to add
	the key/value to the map
Message-ID: <20131205090850.35F7C62AA2@hg.openjdk.java.net>

Changeset: dc2f0c40399a
Author:    psandoz
Date:      2013-12-05 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc2f0c40399a

8028564: Concurrent calls to CHM.put can fail to add the key/value to the map
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea 
        

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java



From peter.levart at gmail.com  Thu Dec  5 09:11:43 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 05 Dec 2013 10:11:43 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A02315.3000605@linux.vnet.ibm.com>
References: <5296F688.1050806@linux.vnet.ibm.com>
	<52973374.4010004@gmail.com>	<52977B91.6030903@oracle.com>
	<529831DD.5080408@linux.vnet.ibm.com>	<52985D7C.8080703@oracle.com>
	<5298632C.5070701@linux.vnet.ibm.com>	<52986791.5040306@oracle.com>
	<5298B919.6000909@oracle.com>	<5298BB49.9040506@oracle.com>
	<52A02315.3000605@linux.vnet.ibm.com>
Message-ID: <52A0434F.5040307@gmail.com>


On 12/05/2013 07:54 AM, Shi Jun Zhang wrote:
> On 11/30/2013 12:05 AM, Daniel Fuchs wrote:
>> On 11/29/13 4:56 PM, Alan Bateman wrote:
>>> On 29/11/2013 10:08, Daniel Fuchs wrote:
>>>>
>>>> However, removing or just moving the lock around might well 
>>>> introduce new
>>>> unknown issues - so it will need to be carefully anaIyzed, and I am
>>>> not sure
>>>> it can/should be attempted in a minor JDK release.
>>>>
>>> Yes, we have to be very careful as the logging code has a history of
>>> biting the hand of those that try to improve it. For various 
>>> reasons, it
>>> seems there is a lot of code that has subtle dependencies on the
>>> implementation, on the initialization in particular. In any case, you
>>> are to be applauded for tackling the synchronization issues and it 
>>> would
>>> be a good project to re-examine all of this in JDK 9 to see how it 
>>> would
>>> be simplified.
>>>
>>> On documenting the locking details in an @implNote (which seems to be
>>> one of the suggestions here) then we also need to be careful as I think
>>> we need some flexibility to change some of this going forward.
>>
>> Yes - that's a two edged sword indeed. We certainly don't want to set
>> that in stone... On the other hand I empathizes with developers who
>> struggle to find out what they can - and can't do - when extending
>> j.u.l APIs...
>>
>> Anyway, if usage of the 'synchronized' keyword never appears in
>> the Javadoc I guess that's for good reasons...
>>
>> Thanks Alan,
>>
>> -- daniel
>>
>>>
>>> -Alan
>>
> Hi Daniel,
>
> This thread is silent for several days, do you have any finding in 
> Handler.publish?
>

Hi Shi Jun Zhang,

I have looked at this, creating a prototype. It re-arranged 
synchronization in a way so that all Formatter methods are invoked out 
of synchronized sections. I haven't come forward with this yet, because 
of two issues:
- Formatter implementations would suddenly be called multi-threaded. 
Currently they are invoked from within Handler-instance synchronized 
sections.
- Formatter would have to be invoked optimistically to obtain head and 
tail strings, so it could happen that a head, for example, would be 
requested concurrently multiple times, but only one of returned heads 
would be written to stream then.

The 1st thing seems problematic. I can imagine there exist Formatters 
that are not thread-safe (for example, using single instance of 
MessageFormat, which is not multi-threaded) and now just happen to work 
as a consequence of current StreamHandler implementation detail, but 
would break if called multi-threaded.

One way to remedy this is to add a boolean property to Formatter API, 
say Formatter.isMultiThreaded(), and arrange so that appropriate 
instances return appropriate values also considering 
backwards-compatibility...

So all-in-all this is not a simple patch and I doubt it can be made for 
JDK8. In JDK9, I think, it will be possible to re-visit this issue, so 
It would be good to file it as a BUG or RFI.


Regards, Peter



From sergey.lugovoy at oracle.com  Thu Dec  5 05:30:41 2013
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Thu, 05 Dec 2013 09:30:41 +0400
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <1664385.xpoWiRqfVs@workland>
References: <1664385.xpoWiRqfVs@workland>
Message-ID: <2118617.k6hklsBbE0@workland>

Hi all,
please review the fix
http://cr.openjdk.java.net/~yan/8029451/webrev.01/
for
https://bugs.openjdk.java.net/browse/JDK-8029451

This patch cleanup tidy warnings for generated html documentation, and do
not affect the appearance of the documentation.

Best regards,
Serge V. Lugovoy


From sean.coffey at oracle.com  Thu Dec  5 10:50:41 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 05 Dec 2013 10:50:41 +0000
Subject: RFR : 8029347 : sun/rmi/runtime/Log/checkLogging/CheckLogging.java
	fails in nightly intermittently
In-Reply-To: <529F5BF0.3020403@oracle.com>
References: <529F4DFB.5030508@oracle.com> <529F4F7F.4040305@oracle.com>
	<529F5BF0.3020403@oracle.com>
Message-ID: <52A05A81.1020201@oracle.com>

I've created https://bugs.openjdk.java.net/browse/JDK-8029595 to track 
some clean up in this area.

regards,
Sean.

On 04/12/2013 16:44, Mandy Chung wrote:
>
> On 12/4/2013 7:51 AM, Alan Bateman wrote:
>> On 04/12/2013 15:44, Se?n Coffey wrote:
>>> Recent jdk8 builds seem to be more ambitious on the GC front. It 
>>> turns out that we've no strong reference for the Logger being 
>>> created in this testcase and it's collected before use.
>> Thanks Sean, I've seen this fail many times recently due to the 
>> logger being GC'ed. The change looks good. At some point we should 
>> check to see if there are other tests that might have similar issues.
>
> Agree.  We should probably consider having a test library method 
> creating a logger that hopefully the new tests can avoid running into 
> the same issue.
>
> Mandy



From scolebourne at joda.org  Thu Dec  5 11:04:33 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 5 Dec 2013 11:04:33 +0000
Subject: RFR: Add value-type notice to java.time classes
In-Reply-To: <529F99CA.7010905@oracle.com>
References: <529F89D9.5030103@oracle.com> <529F93AF.4030005@oracle.com>
	<529F99CA.7010905@oracle.com>
Message-ID: 

Pretty much looks good.

However, I notice that the equals, hashCode and toString methods of
the 4 calendar specific date classes are inherited rather than
written. Without additional spec, I'm not sure that they can claim to
be value types. Adding the 12 Javadocs should be relatively easy.

JapaneseEra should also be a value type, but it needs Javadoc and an
implementation of equals and hashCode that check state.

The chronology classes are potential value types, but as they are
generally singletons, perhaps it matters less.

Stephen



On 4 December 2013 21:08, roger riggs  wrote:
> Corrected.
>
> Thanks, Roger
>
>
> On 12/4/2013 3:42 PM, Xueming Shen wrote:
>>
>> On 12/04/2013 12:00 PM, roger riggs wrote:
>>>
>>> Following the lead of the notices added to Optional, the java.time value
>>> based
>>> classes should include the same notice.
>>>
>>> Please review:
>>> http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/
>>>
>>> Thanks, Roger
>>>
>>>
>>
>>
>> http://cr.openjdk.java.net/~rriggs/webrev-time-valuetype-8029551/src/share/classes/java/time/ZonedDateTime.java.sdiff.html
>>
>> LD -> ZDT
>
>


From paul.sandoz at oracle.com  Thu Dec  5 11:22:58 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Dec 2013 12:22:58 +0100
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <2118617.k6hklsBbE0@workland>
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
Message-ID: 


On Dec 5, 2013, at 6:30 AM, Sergey Lugovoy  wrote:

> Hi all,
> please review the fix
> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
> for
> https://bugs.openjdk.java.net/browse/JDK-8029451
> 
> This patch cleanup tidy warnings for generated html documentation, and do
> not affect the appearance of the documentation.
> 

The following:

--- old/src/share/classes/java/util/ArrayList.java	2013-12-04 17:00:04.849173427 +0000
+++ new/src/share/classes/java/util/ArrayList.java	2013-12-04 17:00:04.657173433 +0000
@@ -70,9 +70,9 @@
  * unsynchronized access to the list:
          *   List list = Collections.synchronizedList(new ArrayList(...));
        
  *
- * 
        
+ * 
         
  * The iterators returned by this class's {@link #iterator() iterator} and
- * {@link #listIterator(int) listIterator} methods are fail-fast:
+ * {@link #listIterator(int) listIterator} methods are fail-fast:
  * if the list is structurally modified at any time after the iterator is
  * created, in any way except through the iterator's own
  * {@link ListIterator#remove() remove} or

effectively reverts:

  http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811
  http://hg.openjdk.java.net/jdk8/tl/jdk/diff/94e1a4b10811/src/share/classes/java/util/ArrayList.java

Any reason for that? and similar changes to Vector. I don't know whether the addition of text content that is a space perturbs the formatting.


--- old/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java	2013-12-04 17:00:07.793173340 +0000
+++ new/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java	2013-12-04 17:00:07.637173345 +0000
@@ -80,7 +80,7 @@
  * {@link ReadLock#tryLock()} and {@link WriteLock#tryLock()} methods
  * do not honor this fair setting and will immediately acquire the lock
  * if it is possible, regardless of waiting threads.)
- * 
        
+ * 
        
  * 
        

Just remove 
         instead of replacing?

Paul.

From erik.joelsson at oracle.com  Thu Dec  5 08:25:58 2013
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 05 Dec 2013 08:25:58 +0000
Subject: hg: jdk8/tl/jdk: 8027963: Create unlimited policy jars.
Message-ID: <20131205082612.0435F62A9D@hg.openjdk.java.net>

Changeset: 427c78c88229
Author:    erikj
Date:      2013-12-05 09:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/427c78c88229

8027963: Create unlimited policy jars.
Reviewed-by: wetmore, ihse

! make/CreateSecurityJars.gmk
! make/SignJars.gmk
- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED



From sergey.lugovoy at oracle.com  Thu Dec  5 17:25:02 2013
From: sergey.lugovoy at oracle.com (Serge)
Date: Thu, 05 Dec 2013 17:25:02 +0000
Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
Message-ID: <52A0B6EE.5040207@oracle.com>

Hi all,
please review the fix
http://cr.openjdk.java.net/~yan/8028712/webrev.02/  
for
https://bugs.openjdk.java.net/browse/JDK-8028712

This patch cleanup tidy warnings for generated html documentation, and do
not affect the appearance of the documentation.

Best regards,
Serge V. Lugovoy



From yuri.nesterenko at oracle.com  Thu Dec  5 14:05:08 2013
From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com)
Date: Thu, 05 Dec 2013 14:05:08 +0000
Subject: hg: jdk8/tl/jdk: 8029264: [doclint] more doclint and tidy cleanup
Message-ID: <20131205140525.4445B62ABD@hg.openjdk.java.net>

Changeset: 8534e297484d
Author:    yan
Date:      2013-12-05 18:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8534e297484d

8029264: [doclint] more doclint and tidy cleanup
Reviewed-by: alexsch, serb, malenkov

! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/DefaultComboBoxModel.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/InputVerifier.java
! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JOptionPane.java
! src/share/classes/javax/swing/JScrollBar.java
! src/share/classes/javax/swing/JScrollPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JTextArea.java
! src/share/classes/javax/swing/JTextPane.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/Painter.java
! src/share/classes/javax/swing/RowFilter.java
! src/share/classes/javax/swing/SizeSequence.java
! src/share/classes/javax/swing/Spring.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingWorker.java
! src/share/classes/javax/swing/border/CompoundBorder.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeModelListener.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
! src/share/classes/javax/swing/table/DefaultTableModel.java
! src/share/classes/javax/swing/table/TableModel.java
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/DefaultEditorKit.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/View.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java



From rob.mckenna at oracle.com  Thu Dec  5 14:19:56 2013
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 05 Dec 2013 14:19:56 +0000
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
Message-ID: <52A08B8C.1050705@oracle.com>

This failure cropped up again and Roger Riggs spotted that I was looking 
at it from completely the wrong direction. He contributed the following fix:

http://cr.openjdk.java.net/~robm/8029525/webrev.01/

This is to avoid a race between:

thread.interrupt();
p.destroy();

Hoping to get this reviewed and pushed as soon as possible!

Thanks,

     -Rob



From roger.riggs at oracle.com  Thu Dec  5 14:24:57 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 05 Dec 2013 09:24:57 -0500
Subject: RFR: Add value-type notice to java.time classes
In-Reply-To: 
References: <529F89D9.5030103@oracle.com> <529F93AF.4030005@oracle.com>
	<529F99CA.7010905@oracle.com>
	
Message-ID: <52A08CB9.1040400@oracle.com>

Hi Stephen,

On 12/5/2013 6:04 AM, Stephen Colebourne wrote:
> Pretty much looks good.
>
> However, I notice that the equals, hashCode and toString methods of
> the 4 calendar specific date classes are inherited rather than
> written. Without additional spec, I'm not sure that they can claim to
> be value types. Adding the 12 Javadocs should be relatively easy.
I considered that the behavior of these methods meet the criteria, not 
the existence
or location of the declaration/implementation.
>
> JapaneseEra should also be a value type, but it needs Javadoc and an
> implementation of equals and hashCode that check state.
Could be, but they are considered Singletons, see below.
>
> The chronology classes are potential value types, but as they are
> generally singletons, perhaps it matters less.

I considered the term Singleton implies an identity relationship.
The == operator is commonly used with singletons (not equals).
So unless the language was modified to remove the term singleton I did not
think they qualified as value types; similarly for all of the enums.

Roger




From roger.riggs at oracle.com  Thu Dec  5 14:40:37 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 05 Dec 2013 09:40:37 -0500
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <52A08B8C.1050705@oracle.com>
References: <52A08B8C.1050705@oracle.com>
Message-ID: <52A09065.3000509@oracle.com>

Hi Rob,

Looks fine.  (Not a Reviewer).

Thanks for doing the legwork, Roger

On 12/5/2013 9:19 AM, Rob McKenna wrote:
> This failure cropped up again and Roger Riggs spotted that I was 
> looking at it from completely the wrong direction. He contributed the 
> following fix:
>
> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>
> This is to avoid a race between:
>
> thread.interrupt();
> p.destroy();
>
> Hoping to get this reviewed and pushed as soon as possible!
>
> Thanks,
>
>     -Rob
>



From chris.hegarty at oracle.com  Thu Dec  5 15:04:41 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 5 Dec 2013 15:04:41 +0000
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <52A09065.3000509@oracle.com>
References: <52A08B8C.1050705@oracle.com> <52A09065.3000509@oracle.com>
Message-ID: 

On 5 Dec 2013, at 14:40, roger riggs  wrote:

> Hi Rob,
> 
> Looks fine.  (Not a Reviewer).

+1. Looks ok to me too.

-Chris.

> 
> Thanks for doing the legwork, Roger
> 
> On 12/5/2013 9:19 AM, Rob McKenna wrote:
>> This failure cropped up again and Roger Riggs spotted that I was looking at it from completely the wrong direction. He contributed the following fix:
>> 
>> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>> 
>> This is to avoid a race between:
>> 
>> thread.interrupt();
>> p.destroy();
>> 
>> Hoping to get this reviewed and pushed as soon as possible!
>> 
>> Thanks,
>> 
>>    -Rob
>> 
> 



From roger.riggs at oracle.com  Thu Dec  5 15:04:09 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 05 Dec 2013 10:04:09 -0500
Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
In-Reply-To: <52A0B6EE.5040207@oracle.com>
References: <52A0B6EE.5040207@oracle.com>
Message-ID: <52A095E9.7050402@oracle.com>

Hi Serge,

A fine point but in java/sql/package.html;  the self closing tag "
        "
is not supported in HTML 3.2 (defined in the DOCTYPE)).
Simply 
         is sufficient.

The rest looks fine to me.  (Not a Reviewer)

Roger


On 12/5/2013 12:25 PM, Serge wrote:
> Hi all,
> please review the fix
> http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
> 
> for
> https://bugs.openjdk.java.net/browse/JDK-8028712
>
> This patch cleanup tidy warnings for generated html documentation, and do
> not affect the appearance of the documentation.
>
> Best regards,
> Serge V. Lugovoy
>



From Alan.Bateman at oracle.com  Thu Dec  5 15:13:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Dec 2013 15:13:16 +0000
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <52A08B8C.1050705@oracle.com>
References: <52A08B8C.1050705@oracle.com>
Message-ID: <52A0980C.8000008@oracle.com>

On 05/12/2013 14:19, Rob McKenna wrote:
> This failure cropped up again and Roger Riggs spotted that I was 
> looking at it from completely the wrong direction. He contributed the 
> following fix:
>
> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>
> This is to avoid a race between:
>
> thread.interrupt();
> p.destroy();
>
> Hoping to get this reviewed and pushed as soon as possible!

The change looks okay, I guess I would rename "latch" to something like 
"ready" (as ready+done might be nicer than latch+done).

If you have more time then you might look at using a phaser. It might 
also be a bit simpler if the waitFor is done in the main thread and have 
the background thread do the interrupt.

In any case, it's good to make this part of the test more robust as it 
has been troublesome.

-Alan.




From Alan.Bateman at oracle.com  Thu Dec  5 15:31:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Dec 2013 15:31:22 +0000
Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
In-Reply-To: <52A0B6EE.5040207@oracle.com>
References: <52A0B6EE.5040207@oracle.com>
Message-ID: <52A09C4A.9000902@oracle.com>

On 05/12/2013 17:25, Serge wrote:
> Hi all,
> please review the fix
> http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
> 
> for
> https://bugs.openjdk.java.net/browse/JDK-8028712
>
> This patch cleanup tidy warnings for generated html documentation, and do
> not affect the appearance of the documentation.
The removal of the 
         tags seems okay. The only thing that I'm not sure 
about the addition of 
         to the package docs (is that needed?).

Lance - while scanning this patch then it appears that some of the 
formatting in the javadoc comments is all over the place 
(java.sql.Connection is one example). It might be good to clean that up 
once the jdk9 project is open for business.

-Alan



From brian.burkhalter at oracle.com  Thu Dec  5 15:51:11 2013
From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com)
Date: Thu, 05 Dec 2013 15:51:11 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131205155144.D58E662AC3@hg.openjdk.java.net>

Changeset: d3c4e8fe98c3
Author:    bpb
Date:      2013-12-05 07:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3c4e8fe98c3

8029514: java/math/BigInteger/BigIntegerTest.java failing since thresholds adjusted in 8022181
Summary: Ensure the value returned by getLower() is unsigned.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: 303f4bccfca2
Author:    bpb
Date:      2013-12-05 07:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/303f4bccfca2

8029501: BigInteger division algorithm selection heuristic is incorrect
Summary: Change Burnikel-Ziegler division heuristic to require that the dividend int-length exceed that of the divisor by a minimum amount.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java



From rob.mckenna at oracle.com  Thu Dec  5 16:21:13 2013
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Thu, 05 Dec 2013 16:21:13 +0000
Subject: hg: jdk8/tl/jdk: 8029525: java/lang/ProcessBuilder/Basic.java fails
	intermittently
Message-ID: <20131205162128.607EF62AC4@hg.openjdk.java.net>

Changeset: 72ea199e3e1b
Author:    robm
Date:      2013-12-05 16:19 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72ea199e3e1b

8029525: java/lang/ProcessBuilder/Basic.java fails intermittently
Reviewed-by: alanb, chegar
Contributed-by: roger.riggs at oracle.com

! test/java/lang/ProcessBuilder/Basic.java



From jason_mehrens at hotmail.com  Thu Dec  5 16:53:55 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 5 Dec 2013 10:53:55 -0600
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A0434F.5040307@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,<52973374.4010004@gmail.com>
	<52977B91.6030903@oracle.com>,<529831DD.5080408@linux.vnet.ibm.com>
	<52985D7C.8080703@oracle.com>,<5298632C.5070701@linux.vnet.ibm.com>
	<52986791.5040306@oracle.com>,<5298B919.6000909@oracle.com>
	<5298BB49.9040506@oracle.com>, <52A02315.3000605@linux.vnet.ibm.com>,
	<52A0434F.5040307@gmail.com>
Message-ID: 

Shi Jun Zhang,
 
This problem is like hooking up your sink drain to your sink faucet.  Even if it you can get it to work you still would not want to use it.   In your code example you could just pre-pend the thread name to the formatter string and return it.  
 
However, if you really, really, really, want to attempt this type of trick you have to use JDK8 and create a custom Filter to generate log records.  If you use a filter, you can ditch the thread local in favor of checking the source class of the log record to determine the proper action.  Or if you are using a JDK prior to JDK8 then install the filter on the logger instead of the handler to avoid the locking.
 
Peter, Daniel,
 
An optimistic tail string would break all formatters that write out summary statistics (num of records, min millis, and max mills).  Instead of changing the formatter synchronization, I think a more useful solution would be to create an AsyncHandler that would disconnect user code from the act of publishing log records.  Then all of handler and formatter locking fall rights into the nice biased locking scenario.
 
Jason

> Hi Shi Jun Zhang,
> 
> I have looked at this, creating a prototype. It re-arranged 
> synchronization in a way so that all Formatter methods are invoked out 
> of synchronized sections. I haven't come forward with this yet, because 
> of two issues:
> - Formatter implementations would suddenly be called multi-threaded. 
> Currently they are invoked from within Handler-instance synchronized 
> sections.
> - Formatter would have to be invoked optimistically to obtain head and 
> tail strings, so it could happen that a head, for example, would be 
> requested concurrently multiple times, but only one of returned heads 
> would be written to stream then.
> 
> The 1st thing seems problematic. I can imagine there exist Formatters 
> that are not thread-safe (for example, using single instance of 
> MessageFormat, which is not multi-threaded) and now just happen to work 
> as a consequence of current StreamHandler implementation detail, but 
> would break if called multi-threaded.
> 
> One way to remedy this is to add a boolean property to Formatter API, 
> say Formatter.isMultiThreaded(), and arrange so that appropriate 
> instances return appropriate values also considering 
> backwards-compatibility...
> 
> So all-in-all this is not a simple patch and I doubt it can be made for 
> JDK8. In JDK9, I think, it will be possible to re-visit this issue, so 
> It would be good to file it as a BUG or RFI.
> 
> 
> Regards, Peter
> 

 		 	   		  

From martinrb at google.com  Thu Dec  5 17:44:02 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Dec 2013 09:44:02 -0800
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <52A08B8C.1050705@oracle.com>
References: <52A08B8C.1050705@oracle.com>
Message-ID: 

sorry for leaving so many little problems in this test.

(In my defense, ProcessBuilder is hard to test in a non-flaky way.)

I think we can come up with a cleaner fix.  I'll post a patch later.


On Thu, Dec 5, 2013 at 6:19 AM, Rob McKenna  wrote:

> This failure cropped up again and Roger Riggs spotted that I was looking
> at it from completely the wrong direction. He contributed the following fix:
>
> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>
> This is to avoid a race between:
>
> thread.interrupt();
> p.destroy();
>
> Hoping to get this reviewed and pushed as soon as possible!
>
> Thanks,
>
>     -Rob
>
>


From Lance.Andersen at oracle.com  Thu Dec  5 18:39:28 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 5 Dec 2013 13:39:28 -0500
Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
In-Reply-To: <52A09C4A.9000902@oracle.com>
References: <52A0B6EE.5040207@oracle.com> <52A09C4A.9000902@oracle.com>
Message-ID: <43E97AF9-B53D-44EE-9F28-AD561C51F2D2@oracle.com>

Hi Serge



This looks OK.



For

--- old/src/share/classes/java/sql/package.html	2013-12-05 15:08:50.587885460 +0000
+++ new/src/share/classes/java/sql/package.html	2013-12-05 15:08:50.435885464 +0000

Please remove the following

--------------------
Package Specification

	? Specification of the JDBC 4.0 API
Related Documentation

	? Getting Started--overviews of the major interfaces
	? Chapters on the JDBC API--from the online version of The Java Tutorial Continued
	? JDBCTMAPI Tutorial and Reference, Third Edition-- a complete reference and tutorial for the JDBC 3.0 API

----------------

The above links keep breaking now that we are off of java.sun.com

And I agree with roger, please use 
        


Alan, yes I can look to clean up some of the formatting crud for Java SE 9 once we have access to the workspace

Thank you for doing this Serge.

Best
Lance
On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote:

> On 05/12/2013 17:25, Serge wrote:
>> Hi all,
>> please review the fix
>> http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8028712
>> 
>> This patch cleanup tidy warnings for generated html documentation, and do
>> not affect the appearance of the documentation.
> The removal of the 
         tags seems okay. The only thing that I'm not sure about the addition of 
         to the package docs (is that needed?).
> 
> Lance - while scanning this patch then it appears that some of the formatting in the javadoc comments is all over the place (java.sql.Connection is one example). It might be good to clean that up once the jdk9 project is open for business.
> 
> -Alan
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From martinrb at google.com  Thu Dec  5 19:18:19 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Dec 2013 11:18:19 -0800
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: 
References: <52A08B8C.1050705@oracle.com>
	
Message-ID: 

You guys are way too trigger-happy.

Rob, I propose you add this patch, that seems cleaner to me, and also
covers the previously untested case of interrupt before waitFor (at the
cost of more code duplication).

diff --git a/test/java/lang/ProcessBuilder/Basic.java
b/test/java/lang/ProcessBuilder/Basic.java
--- a/test/java/lang/ProcessBuilder/Basic.java
+++ b/test/java/lang/ProcessBuilder/Basic.java
@@ -58,6 +58,15 @@
     /* used for Mac OS X only */
     static final String cfUserTextEncoding =
System.getenv("__CF_USER_TEXT_ENCODING");

+    /**
+     * Returns the number of milliseconds since time given by
+     * startNanoTime, which must have been previously returned from a
+     * call to {@link System.nanoTime()}.
+     */
+    private static long millisElapsedSince(long startNanoTime) {
+        return TimeUnit.NANOSECONDS.toMillis(System.nanoTime() -
startNanoTime);
+    }
+
     private static String commandOutput(Reader r) throws Throwable {
         StringBuilder sb = new StringBuilder();
         int c;
@@ -2232,40 +2241,66 @@

         //----------------------------------------------------------------
         // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
-        // interrupt works as expected.
+        // interrupt works as expected, if interrupted while waiting.
         //----------------------------------------------------------------
         try {
             List childArgs = new ArrayList(javaChildArgs);
             childArgs.add("sleep");
             final Process p = new ProcessBuilder(childArgs).start();
             final long start = System.nanoTime();
-            final CountDownLatch ready = new CountDownLatch(1);
-            final CountDownLatch done = new CountDownLatch(1);
+            final CountDownLatch aboutToWaitFor = new CountDownLatch(1);

             final Thread thread = new Thread() {
                 public void run() {
                     try {
-                        final boolean result;
-                        try {
-                            ready.countDown();
-                            result = p.waitFor(30000,
TimeUnit.MILLISECONDS);
-                        } catch (InterruptedException e) {
-                            return;
-                        }
+                        aboutToWaitFor.countDown();
+                        boolean result = p.waitFor(30L * 1000L,
TimeUnit.MILLISECONDS);
                         fail("waitFor() wasn't interrupted, its return
value was: " + result);
-                    } catch (Throwable t) {
-                        unexpected(t);
-                    } finally {
-                        done.countDown();
-                    }
+                    } catch (InterruptedException success) {
+                    } catch (Throwable t) { unexpected(t); }
                 }
             };

             thread.start();
-            ready.await();
+            aboutToWaitFor.await();
             Thread.sleep(1000);
             thread.interrupt();
-            done.await();
+            thread.join(10L * 1000L);
+            check(millisElapsedSince(start) < 10L * 1000L);
+            check(!thread.isAlive());
+            p.destroy();
+        } catch (Throwable t) { unexpected(t); }
+
+        //----------------------------------------------------------------
+        // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
+        // interrupt works as expected, if interrupted before waiting.
+        //----------------------------------------------------------------
+        try {
+            List childArgs = new ArrayList(javaChildArgs);
+            childArgs.add("sleep");
+            final Process p = new ProcessBuilder(childArgs).start();
+            final long start = System.nanoTime();
+            final CountDownLatch threadStarted = new CountDownLatch(1);
+
+            final Thread thread = new Thread() {
+                public void run() {
+                    try {
+                        threadStarted.countDown();
+                        do { Thread.yield(); }
+                        while (!Thread.currentThread().isInterrupted());
+                        boolean result = p.waitFor(30L * 1000L,
TimeUnit.MILLISECONDS);
+                        fail("waitFor() wasn't interrupted, its return
value was: " + result);
+                    } catch (InterruptedException success) {
+                    } catch (Throwable t) { unexpected(t); }
+                }
+            };
+
+            thread.start();
+            threadStarted.await();
+            thread.interrupt();
+            thread.join(10L * 1000L);
+            check(millisElapsedSince(start) < 10L * 1000L);
+            check(!thread.isAlive());
             p.destroy();
         } catch (Throwable t) { unexpected(t); }





On Thu, Dec 5, 2013 at 9:44 AM, Martin Buchholz  wrote:

> sorry for leaving so many little problems in this test.
>
> (In my defense, ProcessBuilder is hard to test in a non-flaky way.)
>
> I think we can come up with a cleaner fix.  I'll post a patch later.
>
>
> On Thu, Dec 5, 2013 at 6:19 AM, Rob McKenna wrote:
>
>> This failure cropped up again and Roger Riggs spotted that I was looking
>> at it from completely the wrong direction. He contributed the following fix:
>>
>> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>>
>> This is to avoid a race between:
>>
>> thread.interrupt();
>> p.destroy();
>>
>> Hoping to get this reviewed and pushed as soon as possible!
>>
>> Thanks,
>>
>>     -Rob
>>
>>
>


From chris.hegarty at oracle.com  Thu Dec  5 19:42:46 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 5 Dec 2013 19:42:46 +0000
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: 
References: <52A08B8C.1050705@oracle.com>
	
	
Message-ID: <0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>


> On 5 Dec 2013, at 19:18, Martin Buchholz  wrote:
> 
> You guys are way too trigger-happy.

I guess the reason for this is that there was a deadline today to get changes into tl before the b120 snapshot. This is one of the final chances to get non-showstopper changes into JDK 8.

Your patch will probably have to wait until JDK 9 opens :-(

-Chris.


> 
> Rob, I propose you add this patch, that seems cleaner to me, and also
> covers the previously untested case of interrupt before waitFor (at the
> cost of more code duplication).
> 
> diff --git a/test/java/lang/ProcessBuilder/Basic.java
> b/test/java/lang/ProcessBuilder/Basic.java
> --- a/test/java/lang/ProcessBuilder/Basic.java
> +++ b/test/java/lang/ProcessBuilder/Basic.java
> @@ -58,6 +58,15 @@
>     /* used for Mac OS X only */
>     static final String cfUserTextEncoding =
> System.getenv("__CF_USER_TEXT_ENCODING");
> 
> +    /**
> +     * Returns the number of milliseconds since time given by
> +     * startNanoTime, which must have been previously returned from a
> +     * call to {@link System.nanoTime()}.
> +     */
> +    private static long millisElapsedSince(long startNanoTime) {
> +        return TimeUnit.NANOSECONDS.toMillis(System.nanoTime() -
> startNanoTime);
> +    }
> +
>     private static String commandOutput(Reader r) throws Throwable {
>         StringBuilder sb = new StringBuilder();
>         int c;
> @@ -2232,40 +2241,66 @@
> 
>         //----------------------------------------------------------------
>         // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
> -        // interrupt works as expected.
> +        // interrupt works as expected, if interrupted while waiting.
>         //----------------------------------------------------------------
>         try {
>             List childArgs = new ArrayList(javaChildArgs);
>             childArgs.add("sleep");
>             final Process p = new ProcessBuilder(childArgs).start();
>             final long start = System.nanoTime();
> -            final CountDownLatch ready = new CountDownLatch(1);
> -            final CountDownLatch done = new CountDownLatch(1);
> +            final CountDownLatch aboutToWaitFor = new CountDownLatch(1);
> 
>             final Thread thread = new Thread() {
>                 public void run() {
>                     try {
> -                        final boolean result;
> -                        try {
> -                            ready.countDown();
> -                            result = p.waitFor(30000,
> TimeUnit.MILLISECONDS);
> -                        } catch (InterruptedException e) {
> -                            return;
> -                        }
> +                        aboutToWaitFor.countDown();
> +                        boolean result = p.waitFor(30L * 1000L,
> TimeUnit.MILLISECONDS);
>                         fail("waitFor() wasn't interrupted, its return
> value was: " + result);
> -                    } catch (Throwable t) {
> -                        unexpected(t);
> -                    } finally {
> -                        done.countDown();
> -                    }
> +                    } catch (InterruptedException success) {
> +                    } catch (Throwable t) { unexpected(t); }
>                 }
>             };
> 
>             thread.start();
> -            ready.await();
> +            aboutToWaitFor.await();
>             Thread.sleep(1000);
>             thread.interrupt();
> -            done.await();
> +            thread.join(10L * 1000L);
> +            check(millisElapsedSince(start) < 10L * 1000L);
> +            check(!thread.isAlive());
> +            p.destroy();
> +        } catch (Throwable t) { unexpected(t); }
> +
> +        //----------------------------------------------------------------
> +        // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
> +        // interrupt works as expected, if interrupted before waiting.
> +        //----------------------------------------------------------------
> +        try {
> +            List childArgs = new ArrayList(javaChildArgs);
> +            childArgs.add("sleep");
> +            final Process p = new ProcessBuilder(childArgs).start();
> +            final long start = System.nanoTime();
> +            final CountDownLatch threadStarted = new CountDownLatch(1);
> +
> +            final Thread thread = new Thread() {
> +                public void run() {
> +                    try {
> +                        threadStarted.countDown();
> +                        do { Thread.yield(); }
> +                        while (!Thread.currentThread().isInterrupted());
> +                        boolean result = p.waitFor(30L * 1000L,
> TimeUnit.MILLISECONDS);
> +                        fail("waitFor() wasn't interrupted, its return
> value was: " + result);
> +                    } catch (InterruptedException success) {
> +                    } catch (Throwable t) { unexpected(t); }
> +                }
> +            };
> +
> +            thread.start();
> +            threadStarted.await();
> +            thread.interrupt();
> +            thread.join(10L * 1000L);
> +            check(millisElapsedSince(start) < 10L * 1000L);
> +            check(!thread.isAlive());
>             p.destroy();
>         } catch (Throwable t) { unexpected(t); }
> 
> 
> 
> 
> 
>> On Thu, Dec 5, 2013 at 9:44 AM, Martin Buchholz  wrote:
>> 
>> sorry for leaving so many little problems in this test.
>> 
>> (In my defense, ProcessBuilder is hard to test in a non-flaky way.)
>> 
>> I think we can come up with a cleaner fix.  I'll post a patch later.
>> 
>> 
>> On Thu, Dec 5, 2013 at 6:19 AM, Rob McKenna wrote:
>> 
>>> This failure cropped up again and Roger Riggs spotted that I was looking
>>> at it from completely the wrong direction. He contributed the following fix:
>>> 
>>> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>>> 
>>> This is to avoid a race between:
>>> 
>>> thread.interrupt();
>>> p.destroy();
>>> 
>>> Hoping to get this reviewed and pushed as soon as possible!
>>> 
>>> Thanks,
>>> 
>>>    -Rob
>> 


From martinrb at google.com  Thu Dec  5 20:12:29 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Dec 2013 12:12:29 -0800
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>
References: <52A08B8C.1050705@oracle.com>
	
	
	<0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>
Message-ID: 

I understand y'all luhv stability, but ... it's ONLY A TEST!

Also, there's Martin's 4th Law of Software Development:
Developers must always have a place to submit-and-forget good changes.


On Thu, Dec 5, 2013 at 11:42 AM, Chris Hegarty wrote:

>
> > On 5 Dec 2013, at 19:18, Martin Buchholz  wrote:
> >
> > You guys are way too trigger-happy.
>
> I guess the reason for this is that there was a deadline today to get
> changes into tl before the b120 snapshot. This is one of the final chances
> to get non-showstopper changes into JDK 8.
>
> Your patch will probably have to wait until JDK 9 opens :-(
>
> -Chris.
>
>
> >
> > Rob, I propose you add this patch, that seems cleaner to me, and also
> > covers the previously untested case of interrupt before waitFor (at the
> > cost of more code duplication).
> >
> > diff --git a/test/java/lang/ProcessBuilder/Basic.java
> > b/test/java/lang/ProcessBuilder/Basic.java
> > --- a/test/java/lang/ProcessBuilder/Basic.java
> > +++ b/test/java/lang/ProcessBuilder/Basic.java
> > @@ -58,6 +58,15 @@
> >     /* used for Mac OS X only */
> >     static final String cfUserTextEncoding =
> > System.getenv("__CF_USER_TEXT_ENCODING");
> >
> > +    /**
> > +     * Returns the number of milliseconds since time given by
> > +     * startNanoTime, which must have been previously returned from a
> > +     * call to {@link System.nanoTime()}.
> > +     */
> > +    private static long millisElapsedSince(long startNanoTime) {
> > +        return TimeUnit.NANOSECONDS.toMillis(System.nanoTime() -
> > startNanoTime);
> > +    }
> > +
> >     private static String commandOutput(Reader r) throws Throwable {
> >         StringBuilder sb = new StringBuilder();
> >         int c;
> > @@ -2232,40 +2241,66 @@
> >
> >
> //----------------------------------------------------------------
> >         // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
> > -        // interrupt works as expected.
> > +        // interrupt works as expected, if interrupted while waiting.
> >
> //----------------------------------------------------------------
> >         try {
> >             List childArgs = new
> ArrayList(javaChildArgs);
> >             childArgs.add("sleep");
> >             final Process p = new ProcessBuilder(childArgs).start();
> >             final long start = System.nanoTime();
> > -            final CountDownLatch ready = new CountDownLatch(1);
> > -            final CountDownLatch done = new CountDownLatch(1);
> > +            final CountDownLatch aboutToWaitFor = new CountDownLatch(1);
> >
> >             final Thread thread = new Thread() {
> >                 public void run() {
> >                     try {
> > -                        final boolean result;
> > -                        try {
> > -                            ready.countDown();
> > -                            result = p.waitFor(30000,
> > TimeUnit.MILLISECONDS);
> > -                        } catch (InterruptedException e) {
> > -                            return;
> > -                        }
> > +                        aboutToWaitFor.countDown();
> > +                        boolean result = p.waitFor(30L * 1000L,
> > TimeUnit.MILLISECONDS);
> >                         fail("waitFor() wasn't interrupted, its return
> > value was: " + result);
> > -                    } catch (Throwable t) {
> > -                        unexpected(t);
> > -                    } finally {
> > -                        done.countDown();
> > -                    }
> > +                    } catch (InterruptedException success) {
> > +                    } catch (Throwable t) { unexpected(t); }
> >                 }
> >             };
> >
> >             thread.start();
> > -            ready.await();
> > +            aboutToWaitFor.await();
> >             Thread.sleep(1000);
> >             thread.interrupt();
> > -            done.await();
> > +            thread.join(10L * 1000L);
> > +            check(millisElapsedSince(start) < 10L * 1000L);
> > +            check(!thread.isAlive());
> > +            p.destroy();
> > +        } catch (Throwable t) { unexpected(t); }
> > +
> > +
>  //----------------------------------------------------------------
> > +        // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
> > +        // interrupt works as expected, if interrupted before waiting.
> > +
>  //----------------------------------------------------------------
> > +        try {
> > +            List childArgs = new
> ArrayList(javaChildArgs);
> > +            childArgs.add("sleep");
> > +            final Process p = new ProcessBuilder(childArgs).start();
> > +            final long start = System.nanoTime();
> > +            final CountDownLatch threadStarted = new CountDownLatch(1);
> > +
> > +            final Thread thread = new Thread() {
> > +                public void run() {
> > +                    try {
> > +                        threadStarted.countDown();
> > +                        do { Thread.yield(); }
> > +                        while (!Thread.currentThread().isInterrupted());
> > +                        boolean result = p.waitFor(30L * 1000L,
> > TimeUnit.MILLISECONDS);
> > +                        fail("waitFor() wasn't interrupted, its return
> > value was: " + result);
> > +                    } catch (InterruptedException success) {
> > +                    } catch (Throwable t) { unexpected(t); }
> > +                }
> > +            };
> > +
> > +            thread.start();
> > +            threadStarted.await();
> > +            thread.interrupt();
> > +            thread.join(10L * 1000L);
> > +            check(millisElapsedSince(start) < 10L * 1000L);
> > +            check(!thread.isAlive());
> >             p.destroy();
> >         } catch (Throwable t) { unexpected(t); }
> >
> >
> >
> >
> >
> >> On Thu, Dec 5, 2013 at 9:44 AM, Martin Buchholz 
> wrote:
> >>
> >> sorry for leaving so many little problems in this test.
> >>
> >> (In my defense, ProcessBuilder is hard to test in a non-flaky way.)
> >>
> >> I think we can come up with a cleaner fix.  I'll post a patch later.
> >>
> >>
> >> On Thu, Dec 5, 2013 at 6:19 AM, Rob McKenna  >wrote:
> >>
> >>> This failure cropped up again and Roger Riggs spotted that I was
> looking
> >>> at it from completely the wrong direction. He contributed the
> following fix:
> >>>
> >>> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
> >>>
> >>> This is to avoid a race between:
> >>>
> >>> thread.interrupt();
> >>> p.destroy();
> >>>
> >>> Hoping to get this reviewed and pushed as soon as possible!
> >>>
> >>> Thanks,
> >>>
> >>>    -Rob
> >>
>


From brent.christian at oracle.com  Thu Dec  5 20:18:35 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 05 Dec 2013 12:18:35 -0800
Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value
	to the map
In-Reply-To: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
Message-ID: <52A0DF9B.7090803@oracle.com>

I'm curious about why this was done:

*** 4452,4462 ****
           public final boolean removeAll(Collection c) {
!             Objects.requireNonNull(c);
               boolean modified = false;
--- 4495,4505 ----
           public final boolean removeAll(Collection c) {
!             if (c == null) throw new NullPointerException();
               boolean modified = false;
*** 4464,4474 ****
           public final boolean retainAll(Collection c) {
!             Objects.requireNonNull(c);
               boolean modified = false;
--- 4507,4517 ----
           public final boolean retainAll(Collection c) {
!             if (c == null) throw new NullPointerException();
               boolean modified = false;


-Brent

On 12/2/13 8:29 AM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/
>
> This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap:
>
>    1) A problem with concurrent resizes; and
>
>    2) The skipping of elements when traversing through bins that are trees of entries.
>
> Both of these issues can result in elements "disappearing" from the map, either because an update operation such as put failed, or because a contains operation failed to find the entry in the map.
>
> Issue 1) was causing stream tests to fail intermittently on systems with many cores (24 to 32) (furthermore the CHM-based JDK test ToArray was also intermittently failing with less frequency).
>
> After some investigation the cause was distilled down to the use of ConcurrentHashMap in the F/J task used by Stream.forEachOrdered.
>
> Issue 2) was serendipitously reported on concurrentcy-interest just yesterday :-)
>
> Both issues have test cases associated with them that have been tuned to reproduce on systems with low cores i.e. my MacBook!
>
> Paul.
>


From dl at cs.oswego.edu  Thu Dec  5 20:29:31 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 05 Dec 2013 15:29:31 -0500
Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value
	to the map
In-Reply-To: <52A0DF9B.7090803@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
	<52A0DF9B.7090803@oracle.com>
Message-ID: <52A0E22B.5030903@cs.oswego.edu>

On 12/05/2013 03:18 PM, Brent Christian wrote:
> I'm curious about why this was done:
>
> *** 4452,4462 ****
>            public final boolean removeAll(Collection c) {
> !             Objects.requireNonNull(c);
>                boolean modified = false;
> --- 4495,4505 ----
>            public final boolean removeAll(Collection c) {
> !             if (c == null) throw new NullPointerException();
>                boolean modified = false;

It wasn't actually done. In part as a way to keep base jsr166
sources for CHM and most other existing classes as JDK7-compatible
as possible, the jsr166 versions always use the explicit form.
For this update, the Oracle-initiated changes that hadn't been in
jsr166 versions don't appear.

-Doug





From Alan.Bateman at oracle.com  Thu Dec  5 20:45:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Dec 2013 20:45:47 +0000
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: <0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>
References: <52A08B8C.1050705@oracle.com>
	
	
	<0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>
Message-ID: <52A0E5FB.90200@oracle.com>

On 05/12/2013 19:42, Chris Hegarty wrote:
>> On 5 Dec 2013, at 19:18, Martin Buchholz  wrote:
>>
>> You guys are way too trigger-happy.
> I guess the reason for this is that there was a deadline today to get changes into tl before the b120 snapshot. This is one of the final chances to get non-showstopper changes into JDK 8.
>
Just to clarify. Only show stopper bugs have been allowed since Nov 21 
when the JDK 8 project went into rampdown phase 2 [1]. There was an 
exception proposed for documentation and test bugs [2] and several 
people have been making use of that exception to fix test issues. This 
is very welcome because tests just don't always get the TLC that they 
deserve.

The exception for documentation and test fixes goes to Dec 12 but the 
rub is that they have to be in the master (jdk8/jdk8) by that date. 
Changes pushed to jdk8/tl are usually integrated into master on a 
Tuesday [3] and even less obvious is that this requires taking a 
snapshot a few days in advance of that to allow for build + integration 
testing (an activity that happens to be getting some air time on 
jdk9-dev list at the moment). I really wish this was more obvious and 
the dates/cut-offs were clearly announced - this is something that we 
have to improve on and fix in JDK 9.

In any case, if Martin's test update has missed the last bus to make the 
Dec 12 deadline then it shouldn't be long before there is a jdk9 forest 
open for business.

-Alan.

[1] http://openjdk.java.net/projects/jdk8/milestones
[2] http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-October/003443.html
[3] http://openjdk.java.net/projects/jdk8/builds


From roger.riggs at oracle.com  Thu Dec  5 20:54:32 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 05 Dec 2013 15:54:32 -0500
Subject: RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails
	intermittently
In-Reply-To: 
References: <52A08B8C.1050705@oracle.com>
	
	
	<0D559D7F-D1FA-4E03-A3B3-F34ACE177405@oracle.com>
	
Message-ID: <52A0E808.9020306@oracle.com>

Created an issue and attached the patch so it doesn't get lost.

https://bugs.openjdk.java.net/browse/JDK-8029629

Roger

On 12/5/2013 3:12 PM, Martin Buchholz wrote:
> I understand y'all luhv stability, but ... it's ONLY A TEST!
>
> Also, there's Martin's 4th Law of Software Development:
> Developers must always have a place to submit-and-forget good changes.
>
>
> On Thu, Dec 5, 2013 at 11:42 AM, Chris Hegarty wrote:
>
>>> On 5 Dec 2013, at 19:18, Martin Buchholz  wrote:
>>>
>>> You guys are way too trigger-happy.
>> I guess the reason for this is that there was a deadline today to get
>> changes into tl before the b120 snapshot. This is one of the final chances
>> to get non-showstopper changes into JDK 8.
>>
>> Your patch will probably have to wait until JDK 9 opens :-(
>>
>> -Chris.
>>
>>
>>> Rob, I propose you add this patch, that seems cleaner to me, and also
>>> covers the previously untested case of interrupt before waitFor (at the
>>> cost of more code duplication).
>>>
>>> diff --git a/test/java/lang/ProcessBuilder/Basic.java
>>> b/test/java/lang/ProcessBuilder/Basic.java
>>> --- a/test/java/lang/ProcessBuilder/Basic.java
>>> +++ b/test/java/lang/ProcessBuilder/Basic.java
>>> @@ -58,6 +58,15 @@
>>>      /* used for Mac OS X only */
>>>      static final String cfUserTextEncoding =
>>> System.getenv("__CF_USER_TEXT_ENCODING");
>>>
>>> +    /**
>>> +     * Returns the number of milliseconds since time given by
>>> +     * startNanoTime, which must have been previously returned from a
>>> +     * call to {@link System.nanoTime()}.
>>> +     */
>>> +    private static long millisElapsedSince(long startNanoTime) {
>>> +        return TimeUnit.NANOSECONDS.toMillis(System.nanoTime() -
>>> startNanoTime);
>>> +    }
>>> +
>>>      private static String commandOutput(Reader r) throws Throwable {
>>>          StringBuilder sb = new StringBuilder();
>>>          int c;
>>> @@ -2232,40 +2241,66 @@
>>>
>>>
>> //----------------------------------------------------------------
>>>          // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
>>> -        // interrupt works as expected.
>>> +        // interrupt works as expected, if interrupted while waiting.
>>>
>> //----------------------------------------------------------------
>>>          try {
>>>              List childArgs = new
>> ArrayList(javaChildArgs);
>>>              childArgs.add("sleep");
>>>              final Process p = new ProcessBuilder(childArgs).start();
>>>              final long start = System.nanoTime();
>>> -            final CountDownLatch ready = new CountDownLatch(1);
>>> -            final CountDownLatch done = new CountDownLatch(1);
>>> +            final CountDownLatch aboutToWaitFor = new CountDownLatch(1);
>>>
>>>              final Thread thread = new Thread() {
>>>                  public void run() {
>>>                      try {
>>> -                        final boolean result;
>>> -                        try {
>>> -                            ready.countDown();
>>> -                            result = p.waitFor(30000,
>>> TimeUnit.MILLISECONDS);
>>> -                        } catch (InterruptedException e) {
>>> -                            return;
>>> -                        }
>>> +                        aboutToWaitFor.countDown();
>>> +                        boolean result = p.waitFor(30L * 1000L,
>>> TimeUnit.MILLISECONDS);
>>>                          fail("waitFor() wasn't interrupted, its return
>>> value was: " + result);
>>> -                    } catch (Throwable t) {
>>> -                        unexpected(t);
>>> -                    } finally {
>>> -                        done.countDown();
>>> -                    }
>>> +                    } catch (InterruptedException success) {
>>> +                    } catch (Throwable t) { unexpected(t); }
>>>                  }
>>>              };
>>>
>>>              thread.start();
>>> -            ready.await();
>>> +            aboutToWaitFor.await();
>>>              Thread.sleep(1000);
>>>              thread.interrupt();
>>> -            done.await();
>>> +            thread.join(10L * 1000L);
>>> +            check(millisElapsedSince(start) < 10L * 1000L);
>>> +            check(!thread.isAlive());
>>> +            p.destroy();
>>> +        } catch (Throwable t) { unexpected(t); }
>>> +
>>> +
>>   //----------------------------------------------------------------
>>> +        // Check that Process.waitFor(timeout, TimeUnit.MILLISECONDS)
>>> +        // interrupt works as expected, if interrupted before waiting.
>>> +
>>   //----------------------------------------------------------------
>>> +        try {
>>> +            List childArgs = new
>> ArrayList(javaChildArgs);
>>> +            childArgs.add("sleep");
>>> +            final Process p = new ProcessBuilder(childArgs).start();
>>> +            final long start = System.nanoTime();
>>> +            final CountDownLatch threadStarted = new CountDownLatch(1);
>>> +
>>> +            final Thread thread = new Thread() {
>>> +                public void run() {
>>> +                    try {
>>> +                        threadStarted.countDown();
>>> +                        do { Thread.yield(); }
>>> +                        while (!Thread.currentThread().isInterrupted());
>>> +                        boolean result = p.waitFor(30L * 1000L,
>>> TimeUnit.MILLISECONDS);
>>> +                        fail("waitFor() wasn't interrupted, its return
>>> value was: " + result);
>>> +                    } catch (InterruptedException success) {
>>> +                    } catch (Throwable t) { unexpected(t); }
>>> +                }
>>> +            };
>>> +
>>> +            thread.start();
>>> +            threadStarted.await();
>>> +            thread.interrupt();
>>> +            thread.join(10L * 1000L);
>>> +            check(millisElapsedSince(start) < 10L * 1000L);
>>> +            check(!thread.isAlive());
>>>              p.destroy();
>>>          } catch (Throwable t) { unexpected(t); }
>>>
>>>
>>>
>>>
>>>
>>>> On Thu, Dec 5, 2013 at 9:44 AM, Martin Buchholz 
>> wrote:
>>>> sorry for leaving so many little problems in this test.
>>>>
>>>> (In my defense, ProcessBuilder is hard to test in a non-flaky way.)
>>>>
>>>> I think we can come up with a cleaner fix.  I'll post a patch later.
>>>>
>>>>
>>>> On Thu, Dec 5, 2013 at 6:19 AM, Rob McKenna >> wrote:
>>>>> This failure cropped up again and Roger Riggs spotted that I was
>> looking
>>>>> at it from completely the wrong direction. He contributed the
>> following fix:
>>>>> http://cr.openjdk.java.net/~robm/8029525/webrev.01/
>>>>>
>>>>> This is to avoid a race between:
>>>>>
>>>>> thread.interrupt();
>>>>> p.destroy();
>>>>>
>>>>> Hoping to get this reviewed and pushed as soon as possible!
>>>>>
>>>>> Thanks,
>>>>>
>>>>>     -Rob



From brian.goetz at oracle.com  Thu Dec  5 21:57:50 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 05 Dec 2013 16:57:50 -0500
Subject: RFR: 8029055: Map.merge must refuse null values
In-Reply-To: 
References: 	<528E568D.8020909@oracle.com>		<528EC28B.6040002@oracle.com>
	<528FF062.9030800@oracle.com>		<52929A59.20204@oracle.com>	<63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com>
	
Message-ID: <52A0F6DE.4060601@oracle.com>

Coming late to the party...

Overall I'll +1 this change, with the following nit:

@throws NullPointerException if the specified key or value is null and
      *         this map does not support null keys or values, or the
      *         remappingFunction is null

This should be:

@throws NullPointerException if the specified key is null and
      *         this map does not support null keys, or if the
      *         value or remappingFunction is null

> See the new thread for the general Javadoc issues. I'll focus on null here.

There is really no choice over the names, or the broad-brush semantics. 
  These methods came from ConcurrentMap; default methods let us pull 
these methods down to all maps (minus atomicity) and have them gain 
atomicity in the context of a ConcurrentMap.

The overall "the docs could be better" arguments are well-taken but 
we're deep in "the perfect is the enemy of the good" territory.  The 
choices at this point are: fix the merge(null) problem, or do nothing; 
doing nothing seems far worse.

> Yes, I get that nulls in collections are a pain, but trying to
> redefine the meaning of "absent" is more of a pain. I'm aware that
> ConcurrentMap makes things interesting, but these two just look wrong.

 > So, my rules would be

OK, but the alternatives look just as wrong from other perspectives, and 
we have an existing 10-year-old set of semantics with which to remain 
compatible.  There's no free lunch here.  This is an uneasy compromise, 
no matter how you slice it.  We can either bring the semantics of these 
ConcurrentMap methods down to Map, or we can not bring them to Map at 
all.  With these semantics, they're imperfect, but still darn useful.


From martinrb at google.com  Fri Dec  6 06:09:54 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Dec 2013 22:09:54 -0800
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: 
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
	
Message-ID: 

In jsr166-land we recently started using 
        , which I recommend,
e.g.

AbstractQueuedSynchronizer.java:122: * 
        Because checks in
acquire are invoked before


On Thu, Dec 5, 2013 at 3:22 AM, Paul Sandoz  wrote:

>
> On Dec 5, 2013, at 6:30 AM, Sergey Lugovoy 
> wrote:
>
> > Hi all,
> > please review the fix
> > http://cr.openjdk.java.net/~yan/8029451/webrev.01/
> > for
> > https://bugs.openjdk.java.net/browse/JDK-8029451
> >
> > This patch cleanup tidy warnings for generated html documentation, and do
> > not affect the appearance of the documentation.
> >
>
> The following:
>
> --- old/src/share/classes/java/util/ArrayList.java      2013-12-04
> 17:00:04.849173427 +0000
> +++ new/src/share/classes/java/util/ArrayList.java      2013-12-04
> 17:00:04.657173433 +0000
> @@ -70,9 +70,9 @@
>   * unsynchronized access to the list:
        >   *   List list = Collections.synchronizedList(new ArrayList(...));
        
>   *
> - * 
        
> + * 
         
>   * The iterators returned by this class's {@link #iterator() iterator} and
> - * {@link #listIterator(int) listIterator} methods are
> fail-fast:
> + * {@link #listIterator(int) listIterator} methods are fail-fast:
>   * if the list is structurally modified at any time after the iterator is
>   * created, in any way except through the iterator's own
>   * {@link ListIterator#remove() remove} or
>
> effectively reverts:
>
>   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/diff/94e1a4b10811/src/share/classes/java/util/ArrayList.java
>
> Any reason for that? and similar changes to Vector. I don't know whether
> the addition of text content that is a space perturbs the formatting.
>
>
> ---
> old/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>        2013-12-04 17:00:07.793173340 +0000
> +++
> new/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>        2013-12-04 17:00:07.637173345 +0000
> @@ -80,7 +80,7 @@
>   * {@link ReadLock#tryLock()} and {@link WriteLock#tryLock()} methods
>   * do not honor this fair setting and will immediately acquire the lock
>   * if it is possible, regardless of waiting threads.)
> - * 
        
> + * 
        
>   * 
>
> Just remove 
         instead of replacing?
>
> Paul.
>


From paul.sandoz at oracle.com  Fri Dec  6 08:38:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 6 Dec 2013 09:38:00 +0100
Subject: 8028564: Concurrent calls to CHM.put can fail to add the
	key/value to the map
In-Reply-To: <52A0E22B.5030903@cs.oswego.edu>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
	<52A0DF9B.7090803@oracle.com> <52A0E22B.5030903@cs.oswego.edu>
Message-ID: <313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>

On Dec 5, 2013, at 9:29 PM, Doug Lea 
         wrote:
> On 12/05/2013 03:18 PM, Brent Christian wrote:
>> I'm curious about why this was done:
>> 
>> *** 4452,4462 ****
>>           public final boolean removeAll(Collection c) {
>> !             Objects.requireNonNull(c);
>>               boolean modified = false;
>> --- 4495,4505 ----
>>           public final boolean removeAll(Collection c) {
>> !             if (c == null) throw new NullPointerException();
>>               boolean modified = false;
> 
> It wasn't actually done. In part as a way to keep base jsr166
> sources for CHM and most other existing classes as JDK7-compatible
> as possible, the jsr166 versions always use the explicit form.
> For this update, the Oracle-initiated changes that hadn't been in
> jsr166 versions don't appear.
> 

My preference is to keep CHM (and other classes) in 8 as close as possible to CHM in 166, otherwise it just makes it harder to apply fixes. So i deliberately took the 166 version of the null checks.

I tend to take sources from 166, copy them into the JDK overwriting the existing sources, and then carefully go through the diffs (via the IDE) selectively applying. We already have one annoying diff related to @Deprecated which is in 166 but not in CHM and that is extremely easy to overlook.

Paul.

From chris.hegarty at oracle.com  Fri Dec  6 10:07:38 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 06 Dec 2013 10:07:38 +0000
Subject: 8028564: Concurrent calls to CHM.put can fail to add the key/value
	to the map
In-Reply-To: <313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>	<52A0DF9B.7090803@oracle.com>
	<52A0E22B.5030903@cs.oswego.edu>
	<313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>
Message-ID: <52A1A1EA.4000200@oracle.com>

On 06/12/13 08:38, Paul Sandoz wrote:
> On Dec 5, 2013, at 9:29 PM, Doug Lea 
         wrote:
>> On 12/05/2013 03:18 PM, Brent Christian wrote:
>>> I'm curious about why this was done:
>>>
>>> *** 4452,4462 ****
>>>            public final boolean removeAll(Collection c) {
>>> !             Objects.requireNonNull(c);
>>>                boolean modified = false;
>>> --- 4495,4505 ----
>>>            public final boolean removeAll(Collection c) {
>>> !             if (c == null) throw new NullPointerException();
>>>                boolean modified = false;
>>
>> It wasn't actually done. In part as a way to keep base jsr166
>> sources for CHM and most other existing classes as JDK7-compatible
>> as possible, the jsr166 versions always use the explicit form.
>> For this update, the Oracle-initiated changes that hadn't been in
>> jsr166 versions don't appear.
>>
>
> My preference is to keep CHM (and other classes) in 8 as close as possible to CHM in 166, otherwise it just makes it harder to apply fixes. So i deliberately took the 166 version of the null checks.

Agreed. It is too easy to miss changes and make mistakes otherwise.

-Chris.

> I tend to take sources from 166, copy them into the JDK overwriting the existing sources, and then carefully go through the diffs (via the IDE) selectively applying. We already have one annoying diff related to @Deprecated which is in 166 but not in CHM and that is extremely easy to overlook.
>
> Paul.
>


From Alan.Bateman at oracle.com  Fri Dec  6 11:44:52 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Dec 2013 11:44:52 +0000
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <2118617.k6hklsBbE0@workland>
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
Message-ID: <52A1B8B4.3000406@oracle.com>

On 05/12/2013 05:30, Sergey Lugovoy wrote:
> Hi all,
> please review the fix
> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
> for
> https://bugs.openjdk.java.net/browse/JDK-8029451
>
> This patch cleanup tidy warnings for generated html documentation, and do
> not affect the appearance of the documentation.
>
In java/util/zip/package.html then I see that the 
         tags have been 
replaced by 
        . Is that okay in HTML 3.2? I just wonder if it might 
be better to just remove the 
         tags. I don't see a problem with 
changing the spacing of the list items.

-Alan


From scolebourne at joda.org  Fri Dec  6 12:30:00 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 6 Dec 2013 12:30:00 +0000
Subject: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge
	must refuse null values]
In-Reply-To: 
References: 
Message-ID: 

See https://bugs.openjdk.java.net/browse/JDK-8029676

Stephen

On 26 November 2013 13:20, Stephen Colebourne  wrote:
> I took a quick look, but jumped back in horror at the start of the
> Javadoc for the new methods in Map. A Javadoc description should start
> with the positive, not the negative. I had to read the code to figure
> out what they are supposed to do. Here are the four poor Javadocs and
> some proposed enhacements:
>
> merge()
> "If the specified key is not already associated with ..."
> should be
> "Updates the value for an existing key merging the existing value with
> the specified value."
> "
        "
> "....more detailed user-level explanation..."
> "
        "
> "....now the more spec/edge case part..."
> ("if" is a terrible way to start the docs. Say what it does!)
>
>
> computeIfAbsent()
> "If the specified key is not already associated with a value (or is mapped..."
> should be
> "Associates the key with a value computed on demand if the key is not
> currently present."
> "
        "
> "....more detailed user-level explanation..."
> "
        "
> "....now the more spec/edge case part..."
>
>
> computeIfPresent()
> "If the value for the specified key is present and non-null,"
> should be
> "Updates the value for an existing key."
> "
        "
> "....more detailed user-level explanation..."
> "
        "
> "....now the more spec/edge case part..."
>
>
> compute()
> "Attempts to compute a mapping for the specified key..."
> should be
> "Updates the value for a key, adding a new mapping if necessary."
> "
        "
> "....more detailed user-level explanation..."
> "
        "
> "....now the more spec/edge case part..."
> (attempts is negative, not positive)
>
> Similar problems seem to exist for "putIfAbsent".
>
> also...
>
> I have to say that I don't overly like the method name.
> "map.merge(...)" sounds like a bulk operation affecting the whole map
> (ie. like putAll). Assuming that the method cannot be renamed, it
> could be improved just by changing the method parameter names.:
>
> default V merge(K key, V valueToMerge,
>     BiFunction mergeFunction) {
>
> "valueToMerge" implies that action will occur to the parameter.
> "mergeFunction" is much more meaningful that "remapping Function".
>
> Similar parameter name change, "mappingFunction" -> "valueCreationFunction"
> default V computeIfAbsent(
>   K key,
>   Function valueCreationFunction) {
>
> Similar parameter name change, "remappingFunction" -> "valueUpdateFunction"
> default V computeIfPresent(
>   K key,
>   BiFunction valueUpdateFunction) {
>
> Similar parameter name change, "remappingFunction" -> "valueUpdateFunction"
> default V compute(
>   K key,
>   BiFunction valueUpdateFunction) {
>
>
> also...
> Can you use HashSet::new in the example code?
>
>
> In general, all these new methods are written in a spec style, rather
> than a user friendly style, and I'm afraid I don't think thats
> sufficient.
> Stephen
>
>
>
> On 26 November 2013 04:32, Mike Duigou  wrote:
>>
>> On Nov 24 2013, at 16:31 , David Holmes  wrote:
>>
>>> Hi Mike,
>>>
>>> There is still no clear spec for what should happen if the param value is null.
>>
>> I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated.
>>
>> Currently:
>>
>> - The provided value may be either null or non-null. Is null a legal value? It depends upon:
>>         - Is there an existing value?
>>         - Does the Map allow null values?
>>         - Does the function allow null values?
>> - Existing null values are treated as absent.
>>         - If a null value is passed should we remove this mapping or add it to the map?
>>               - null might not be accepted by the map
>>               - The associated value would still be regarded as absent for future operations.
>> - The function may return null to signal "remove".
>>
>> In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse.
>>
>> So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly.
>>
>>> The parenthesized part is wrong.
>>
>> I think that's overzealous copying from compute(). I have removed it.
>>
>>>
>>> Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading.
>>
>> I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param"
>>
>> I have updated the webrev.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/
>>
>> Thanks,
>>
>> Mike
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 23/11/2013 10:25 AM, Mike Duigou wrote:
>>>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue.
>>>>
>>>> I've posted a webrev here:
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/
>>>>
>>>> There is an identical change in ConcurrentMap's merge().
>>>>
>>>> Mike
>>>>
>>>> On Nov 22 2013, at 16:01 , Henry Jen  wrote:
>>>>
>>>>>
>>>>> On 11/21/2013 06:33 PM, David Holmes wrote:
>>>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote:
>>>>>>> While I agree that case should be specified, I'm not certain I follow why
>>>>>>> that's what's going on here.
>>>>>>>
>>>>>>> The weird condition is that if oldValue is null, not value; oldValue
>>>>>>> is the
>>>>>>> old result of map.get(key).  The Javadoc seems not just unspecified, but
>>>>>>> actively wrong.  Here's a worked example:
>>>>>>>
>>>>>>> Map map = new HashMap<>();
>>>>>>> map.merge("foo", 3, Integer::plus);
>>>>>>> Integer fooValue = map.get("foo");
>>>>>>>
>>>>>>> Going through the Javadoc-specified default implementation:
>>>>>>>
>>>>>>>   V oldValue = map.get(key); // oldValue is null
>>>>>>>   V newValue = (oldValue == null) ? value :
>>>>>>>                remappingFunction.apply(oldValue, value);
>>>>>>>      // newValue is set to value, which is 3
>>>>>>>   if (newValue == null) // newValue is nonnull, branch not taken
>>>>>>>       map.remove(key);
>>>>>>>   else if (oldValue == null) // oldValue is null, branch taken
>>>>>>>       map.remove(key); // removes the entry from the map
>>>>>>>   else // else if was already triggered, branch not taken
>>>>>>>       map.put(key, newValue);
>>>>>>>
>>>>>
>>>>> Seems like a document bug to me, we should fix this @implSpec.
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>
>>


From roger.riggs at oracle.com  Fri Dec  6 13:56:56 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 06 Dec 2013 08:56:56 -0500
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: 
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
	
	
Message-ID: <52A1D7A8.5060700@oracle.com>

+1,

It can be used with any tag (not just 
        , including 
        , 
          , 
        • , 

          , etc.)



On 12/6/2013 1:09 AM, Martin Buchholz wrote:
> In jsr166-land we recently started using 
          , which I recommend,
> e.g.
>
> AbstractQueuedSynchronizer.java:122: * 
          Because checks in
> acquire are invoked before
>
>
> On Thu, Dec 5, 2013 at 3:22 AM, Paul Sandoz  wrote:
>
>> On Dec 5, 2013, at 6:30 AM, Sergey Lugovoy 
>> wrote:
>>
>>> Hi all,
>>> please review the fix
>>> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8029451
>>>
>>> This patch cleanup tidy warnings for generated html documentation, and do
>>> not affect the appearance of the documentation.
>>>
>> The following:
>>
>> --- old/src/share/classes/java/util/ArrayList.java      2013-12-04
>> 17:00:04.849173427 +0000
>> +++ new/src/share/classes/java/util/ArrayList.java      2013-12-04
>> 17:00:04.657173433 +0000
>> @@ -70,9 +70,9 @@
>>    * unsynchronized access to the list:
          >>    *   List list = Collections.synchronizedList(new ArrayList(...));
          
>>    *
>> - * 
          
>> + * 
           
>>    * The iterators returned by this class's {@link #iterator() iterator} and
>> - * {@link #listIterator(int) listIterator} methods are
>> fail-fast:
>> + * {@link #listIterator(int) listIterator} methods are fail-fast:
>>    * if the list is structurally modified at any time after the iterator is
>>    * created, in any way except through the iterator's own
>>    * {@link ListIterator#remove() remove} or
>>
>> effectively reverts:
>>
>>    http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/diff/94e1a4b10811/src/share/classes/java/util/ArrayList.java
>>
>> Any reason for that? and similar changes to Vector. I don't know whether
>> the addition of text content that is a space perturbs the formatting.
>>
>>
>> ---
>> old/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>>         2013-12-04 17:00:07.793173340 +0000
>> +++
>> new/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>>         2013-12-04 17:00:07.637173345 +0000
>> @@ -80,7 +80,7 @@
>>    * {@link ReadLock#tryLock()} and {@link WriteLock#tryLock()} methods
>>    * do not honor this fair setting and will immediately acquire the lock
>>    * if it is possible, regardless of waiting threads.)
>> - * 
          
>> + * 
          
>>    * 
        
>>
>> Just remove 
         instead of replacing?
>>
>> Paul.
>>



From michael.x.mcmahon at oracle.com  Fri Dec  6 15:44:27 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 06 Dec 2013 15:44:27 +0000
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <52A1B8B4.3000406@oracle.com>
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
	<52A1B8B4.3000406@oracle.com>
Message-ID: <52A1F0DB.7020605@oracle.com>

On 06/12/13 11:44, Alan Bateman wrote:
> On 05/12/2013 05:30, Sergey Lugovoy wrote:
>> Hi all,
>> please review the fix
>> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8029451
>>
>> This patch cleanup tidy warnings for generated html documentation, 
>> and do
>> not affect the appearance of the documentation.
>>
> In java/util/zip/package.html then I see that the 
         tags have been 
> replaced by 
        . Is that okay in HTML 3.2? I just wonder if it might 
> be better to just remove the 
         tags. I don't see a problem with 
> changing the spacing of the list items.
>
> -Alan

I just noticed some broken link fragments in the java.util.stream package.
Would it be worthwhile including the fix in this change, or should I 
file a separate bug?

Michael


From martinrb at google.com  Fri Dec  6 17:00:46 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Dec 2013 09:00:46 -0800
Subject: 8028564: Concurrent calls to CHM.put can fail to add the
	key/value to the map
In-Reply-To: <313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
	<52A0DF9B.7090803@oracle.com> <52A0E22B.5030903@cs.oswego.edu>
	<313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>
Message-ID: 

Doug and I would prefer that there were ZERO differences between jsr166 CVS
and openjdk, but that seems unachievable.  At least try to treat jsr166 CVS
as canonical upstream sources and minimize any divergence.


On Fri, Dec 6, 2013 at 12:38 AM, Paul Sandoz  wrote:

> On Dec 5, 2013, at 9:29 PM, Doug Lea 
         wrote:
> > On 12/05/2013 03:18 PM, Brent Christian wrote:
> >> I'm curious about why this was done:
> >>
> >> *** 4452,4462 ****
> >>           public final boolean removeAll(Collection c) {
> >> !             Objects.requireNonNull(c);
> >>               boolean modified = false;
> >> --- 4495,4505 ----
> >>           public final boolean removeAll(Collection c) {
> >> !             if (c == null) throw new NullPointerException();
> >>               boolean modified = false;
> >
> > It wasn't actually done. In part as a way to keep base jsr166
> > sources for CHM and most other existing classes as JDK7-compatible
> > as possible, the jsr166 versions always use the explicit form.
> > For this update, the Oracle-initiated changes that hadn't been in
> > jsr166 versions don't appear.
> >
>
> My preference is to keep CHM (and other classes) in 8 as close as possible
> to CHM in 166, otherwise it just makes it harder to apply fixes. So i
> deliberately took the 166 version of the null checks.
>
> I tend to take sources from 166, copy them into the JDK overwriting the
> existing sources, and then carefully go through the diffs (via the IDE)
> selectively applying. We already have one annoying diff related to
> @Deprecated which is in 166 but not in CHM and that is extremely easy to
> overlook.
>
> Paul.
>


From martinrb at google.com  Fri Dec  6 17:09:32 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Dec 2013 09:09:32 -0800
Subject: 8028564: Concurrent calls to CHM.put can fail to add the
	key/value to the map
In-Reply-To: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>
Message-ID: 

Paul,

Your testing efforts are appreciated.  It's always good to have tests
written by non-maintainers, especially when written in a novel style.


From martinrb at google.com  Fri Dec  6 17:20:53 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Dec 2013 09:20:53 -0800
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <52A1F0DB.7020605@oracle.com>
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
	<52A1B8B4.3000406@oracle.com> <52A1F0DB.7020605@oracle.com>
Message-ID: 

FYI: When I run javadoc on jsr166 CVS (it's not too hard for y'all to do
this as well), I still see many warnings inherited from openjdk8 source:

 $ ant docs
...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0-ea
  [javadoc] Building tree for all the packages and classes...
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:759:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:759:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:759:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:736:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:736:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/BitSet.java:1140:
warning: no @param for s
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/BitSet.java:1140:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/BitSet.java:1140:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/BitSet.java:1123:
warning: no @param for s
  [javadoc]     private void writeObject(ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/BitSet.java:1123:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Calendar.java:3509:
warning: no @param for stream
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Calendar.java:3509:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Calendar.java:3509:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Calendar.java:3455:
warning: no @param for stream
  [javadoc]     private synchronized void writeObject(ObjectOutputStream
stream)
  [javadoc]                               ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Calendar.java:3455:
warning: no @throws for java.io.IOException
  [javadoc]     private synchronized void writeObject(ObjectOutputStream
stream)
  [javadoc]                               ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Collections.java:2536:
warning: no @return
  [javadoc]         private Object readResolve() {
  [javadoc]                        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Collections.java:2573:
warning: no @return
  [javadoc]         private Object writeReplace() {
  [javadoc]                        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Collections.java:1441:
warning: no @return
  [javadoc]         private Object readResolve() {
  [javadoc]                        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Collections.java:1471:
warning: no @return
  [javadoc]         private Object writeReplace() {
  [javadoc]                        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Currency.java:595:
warning: no @return
  [javadoc]     private Object readResolve() {
  [javadoc]                    ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Date.java:1329:
warning: no @param for s
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Date.java:1329:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Date.java:1329:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Date.java:1320:
warning: no @param for s
  [javadoc]     private void writeObject(ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Date.java:1320:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/EnumMap.java:791:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/EnumMap.java:791:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/EnumMap.java:791:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/EnumMap.java:766:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/EnumMap.java:766:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/GregorianCalendar.java:3235:
warning: no @param for stream
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/GregorianCalendar.java:3235:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/GregorianCalendar.java:3235:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashMap.java:1359:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashMap.java:1359:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashMap.java:1359:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashMap.java:1345:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashMap.java:1345:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashSet.java:294:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashSet.java:294:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashSet.java:294:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashSet.java:273:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/HashSet.java:273:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Hashtable.java:1165:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Hashtable.java:1165:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Hashtable.java:1165:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Hashtable.java:1130:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Hashtable.java:1130:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/IdentityHashMap.java:1301:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/IdentityHashMap.java:1301:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/IdentityHashMap.java:1301:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/IdentityHashMap.java:1278:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/IdentityHashMap.java:1278:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/LinkedList.java:1139:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/LinkedList.java:1139:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/LinkedList.java:1139:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/LinkedList.java:1121:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/LinkedList.java:1121:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Locale.java:2169:
warning: no description for @throws
  [javadoc]      * @throws IOException
  [javadoc]        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Locale.java:2170:
warning: no description for @throws
  [javadoc]      * @throws ClassNotFoundException
  [javadoc]        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Locale.java:2171:
warning: no description for @throws
  [javadoc]      * @throws IllformedLocaleException
  [javadoc]        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Locale.java:2152:
warning: no description for @throws
  [javadoc]      * @throws IOException
  [javadoc]        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Locale.java:2207:
warning: no description for @throws
  [javadoc]      * @throws java.io.ObjectStreamException
  [javadoc]        ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/PropertyPermission.java:618:
warning: no @param for out
  [javadoc]     private void writeObject(ObjectOutputStream out) throws
IOException {
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/PropertyPermission.java:618:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(ObjectOutputStream out) throws
IOException {
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Random.java:1181:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Random.java:1181:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Random.java:1181:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Random.java:1200:
warning: no @param for s
  [javadoc]     synchronized private void writeObject(ObjectOutputStream s)
  [javadoc]                               ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Random.java:1200:
warning: no @throws for java.io.IOException
  [javadoc]     synchronized private void writeObject(ObjectOutputStream s)
  [javadoc]                               ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/SimpleTimeZone.java:1669:
warning: no @param for stream
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/SimpleTimeZone.java:1669:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/SimpleTimeZone.java:1669:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(ObjectInputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/SimpleTimeZone.java:1639:
warning: no @param for stream
  [javadoc]     private void writeObject(ObjectOutputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/SimpleTimeZone.java:1639:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(ObjectOutputStream stream)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeMap.java:2441:
warning: no @param for s
  [javadoc]     private void readObject(final java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeMap.java:2441:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(final java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeMap.java:2441:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(final java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeMap.java:2421:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeMap.java:2421:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeSet.java:517:
warning: no @param for s
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeSet.java:517:
warning: no @throws for java.io.IOException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeSet.java:517:
warning: no @throws for java.lang.ClassNotFoundException
  [javadoc]     private void readObject(java.io.ObjectInputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeSet.java:497:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/TreeSet.java:497:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Vector.java:1067:
warning: no @param for s
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^
  [javadoc]
/home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/Vector.java:1067:
warning: no @throws for java.io.IOException
  [javadoc]     private void writeObject(java.io.ObjectOutputStream s)
  [javadoc]                  ^



On Fri, Dec 6, 2013 at 7:44 AM, Michael McMahon <
michael.x.mcmahon at oracle.com> wrote:

> On 06/12/13 11:44, Alan Bateman wrote:
>
>> On 05/12/2013 05:30, Sergey Lugovoy wrote:
>>
>>> Hi all,
>>> please review the fix
>>> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8029451
>>>
>>> This patch cleanup tidy warnings for generated html documentation, and do
>>> not affect the appearance of the documentation.
>>>
>>>  In java/util/zip/package.html then I see that the 
         tags have been
>> replaced by 
        . Is that okay in HTML 3.2? I just wonder if it might be
>> better to just remove the 
         tags. I don't see a problem with changing the
>> spacing of the list items.
>>
>> -Alan
>>
>
> I just noticed some broken link fragments in the java.util.stream package.
> Would it be worthwhile including the fix in this change, or should I file
> a separate bug?
>
> Michael
>


From joe.darcy at oracle.com  Fri Dec  6 17:56:17 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 06 Dec 2013 09:56:17 -0800
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: 
References: <1664385.xpoWiRqfVs@workland>
	<2118617.k6hklsBbE0@workland>	<52A1B8B4.3000406@oracle.com>
	<52A1F0DB.7020605@oracle.com>
	
Message-ID: <52A20FC1.1020201@oracle.com>

On 12/06/2013 09:20 AM, Martin Buchholz wrote:
> FYI: When I run javadoc on jsr166 CVS (it's not too hard for y'all to do
> this as well), I still see many warnings inherited from openjdk8 source:
>
>   $ ant docs
> ...
>    [javadoc] Constructing Javadoc information...
>    [javadoc] Standard Doclet version 1.8.0-ea
>    [javadoc] Building tree for all the packages and classes...
>    [javadoc]
> /home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/ArrayList.java:759:
> warning: no @param for s
>    [javadoc]     private void readObject(java.io.ObjectInputStream s)
>    [javadoc]                  ^
>    [javadoc]

We have been working to address doclint issues against public and 
protected elements, which is not to say readObject and writeObject 
methods shouldn't have javadoc.

-Joe



From mike.duigou at oracle.com  Fri Dec  6 17:56:37 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 6 Dec 2013 09:56:37 -0800
Subject: 8028564: Concurrent calls to CHM.put can fail to add the
	key/value to the map
In-Reply-To: <52A1A1EA.4000200@oracle.com>
References: <94463E32-04CD-4BF7-AD03-06534F08C493@oracle.com>	<52A0DF9B.7090803@oracle.com>
	<52A0E22B.5030903@cs.oswego.edu>
	<313AB206-DFE0-444B-A57B-7583475D78CA@oracle.com>
	<52A1A1EA.4000200@oracle.com>
Message-ID: 


On Dec 6 2013, at 02:07 , Chris Hegarty  wrote:

> On 06/12/13 08:38, Paul Sandoz wrote:
>> On Dec 5, 2013, at 9:29 PM, Doug Lea 
         wrote:
>>> On 12/05/2013 03:18 PM, Brent Christian wrote:
>>>> I'm curious about why this was done:
>>>> 
>>>> *** 4452,4462 ****
>>>>           public final boolean removeAll(Collection c) {
>>>> !             Objects.requireNonNull(c);
>>>>               boolean modified = false;
>>>> --- 4495,4505 ----
>>>>           public final boolean removeAll(Collection c) {
>>>> !             if (c == null) throw new NullPointerException();
>>>>               boolean modified = false;
>>> 
>>> It wasn't actually done. In part as a way to keep base jsr166
>>> sources for CHM and most other existing classes as JDK7-compatible
>>> as possible, the jsr166 versions always use the explicit form.
>>> For this update, the Oracle-initiated changes that hadn't been in
>>> jsr166 versions don't appear.
>>> 
>> 
>> My preference is to keep CHM (and other classes) in 8 as close as possible to CHM in 166, otherwise it just makes it harder to apply fixes. So i deliberately took the 166 version of the null checks.
> 
> Agreed. It is too easy to miss changes and make mistakes otherwise.


Agreed here as well.

Mike

> 
> -Chris.
> 
>> I tend to take sources from 166, copy them into the JDK overwriting the existing sources, and then carefully go through the diffs (via the IDE) selectively applying. We already have one annoying diff related to @Deprecated which is in 166 but not in CHM and that is extremely easy to overlook.
>> 
>> Paul.
>> 



From martinrb at google.com  Fri Dec  6 19:14:36 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Dec 2013 11:14:36 -0800
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <52A20FC1.1020201@oracle.com>
References: <1664385.xpoWiRqfVs@workland> <2118617.k6hklsBbE0@workland>
	<52A1B8B4.3000406@oracle.com> <52A1F0DB.7020605@oracle.com>
	
	<52A20FC1.1020201@oracle.com>
Message-ID: 

Hi Joe,

You and I know that readObject and writeObject are very special private
methods, since they are effectively part of the public API.  Apparently,
the unexpectedly clever javadoc tool knows this as well, so even with
default flags, it will report warnings for these methods.

Notice the "Generating /tmp/t8/serialized-form.html..." below.

src/share/classes/java/util $ (mkdir -p /tmp/t8 && ~/jdk/jdk8/bin/javadoc
-d /tmp/t8 ArrayList.java)
Loading source file ArrayList.java...
Constructing Javadoc information...
Standard Doclet version 1.8.0-ea
Building tree for all the packages and classes...
Generating /tmp/t8/java/util/ArrayList.html...
Generating /tmp/t8/java/util/package-frame.html...
Generating /tmp/t8/java/util/package-summary.html...
Generating /tmp/t8/java/util/package-tree.html...
Generating /tmp/t8/constant-values.html...
Generating /tmp/t8/serialized-form.html...
ArrayList.java:759: warning: no @param for s
    private void readObject(java.io.ObjectInputStream s)
                 ^
ArrayList.java:759: warning: no @throws for java.io.IOException
    private void readObject(java.io.ObjectInputStream s)
                 ^
ArrayList.java:759: warning: no @throws for java.lang.ClassNotFoundException
    private void readObject(java.io.ObjectInputStream s)
                 ^
ArrayList.java:736: warning: no @param for s
    private void writeObject(java.io.ObjectOutputStream s)
                 ^
ArrayList.java:736: warning: no @throws for java.io.IOException
    private void writeObject(java.io.ObjectOutputStream s)
                 ^
Building index for all the packages and classes...


On Fri, Dec 6, 2013 at 9:56 AM, Joe Darcy  wrote:

> On 12/06/2013 09:20 AM, Martin Buchholz wrote:
>
>> FYI: When I run javadoc on jsr166 CVS (it's not too hard for y'all to do
>> this as well), I still see many warnings inherited from openjdk8 source:
>>
>>   $ ant docs
>> ...
>>    [javadoc] Constructing Javadoc information...
>>    [javadoc] Standard Doclet version 1.8.0-ea
>>    [javadoc] Building tree for all the packages and classes...
>>    [javadoc]
>> /home/martin/jdk/src/jdk8/jdk/src/share/classes/java/util/
>> ArrayList.java:759:
>> warning: no @param for s
>>    [javadoc]     private void readObject(java.io.ObjectInputStream s)
>>    [javadoc]                  ^
>>    [javadoc]
>>
>
> We have been working to address doclint issues against public and
> protected elements, which is not to say readObject and writeObject methods
> shouldn't have javadoc.
>
> -Joe
>
>


From joe.darcy at oracle.com  Fri Dec  6 19:28:48 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 06 Dec 2013 19:28:48 +0000
Subject: hg: jdk8/tl/jdk: 8023471: Add compatibility note to AnnotatedElement
Message-ID: <20131206192903.32E4F62B47@hg.openjdk.java.net>

Changeset: f8da1f34c65c
Author:    darcy
Date:      2013-12-06 11:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8da1f34c65c

8023471: Add compatibility note to AnnotatedElement
Reviewed-by: smarks, jfranck, abuckley

! src/share/classes/java/lang/annotation/Annotation.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java



From mike.duigou at oracle.com  Fri Dec  6 19:59:35 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 6 Dec 2013 11:59:35 -0800
Subject: RFR: 8029696 : (xs) Broken doc links to
	package-summary.html#NonInterference in java.util.stream
Message-ID: 

Hello all;

https://bugs.openjdk.java.net/browse/JDK-8029696

Michael McMahon noticed that some links to the anchor #NonInterference were not using the correct name for the anchor. He prepared a patch which I reviewed, tested. I also checked to make sure there were no other broken instances.

I've prepared a webrev of the patch for anyone else who wishes to review.

http://cr.openjdk.java.net/~mduigou/JDK-8029696/0/webrev/

Mike

From kumar.x.srinivasan at oracle.com  Fri Dec  6 21:10:04 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 06 Dec 2013 21:10:04 +0000
Subject: hg: jdk8/tl/langtools: 8029504: Regression: TestDocRootLink test
	fails on Windows
Message-ID: <20131206211011.2C5A962B51@hg.openjdk.java.net>

Changeset: 2d0a0ae7fa9c
Author:    ksrini
Date:      2013-12-06 09:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d0a0ae7fa9c

8029504: Regression: TestDocRootLink test fails on Windows
Reviewed-by: bpatel, jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java



From jason.uh at oracle.com  Fri Dec  6 19:36:30 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Fri, 06 Dec 2013 19:36:30 +0000
Subject: hg: jdk8/tl/jdk: 8007967: Infinite loop can happen in
	sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward()
Message-ID: <20131206193643.3C80662B48@hg.openjdk.java.net>

Changeset: d6c4ae56c079
Author:    juh
Date:      2013-12-06 11:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6c4ae56c079

8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward()
Reviewed-by: mullan

! 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/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java



From mike.duigou at oracle.com  Fri Dec  6 22:18:55 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 6 Dec 2013 14:18:55 -0800
Subject: RFR: 8029055: Map.merge must refuse null values
In-Reply-To: <63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com>
References: 	<528E568D.8020909@oracle.com>	
	<528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com>
	
	<52929A59.20204@oracle.com>
	<63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com>
Message-ID: 

Hello all. I have updated the webrev with a final correction from Brian Goetz, the @throws NPE didn't reflect that it was thrown unconditionally if value is null.

http://cr.openjdk.java.net/~mduigou/JDK-8029055/2/webrev/

Mike


On Nov 25 2013, at 20:32 , Mike Duigou  wrote:

> 
> On Nov 24 2013, at 16:31 , David Holmes  wrote:
> 
>> Hi Mike,
>> 
>> There is still no clear spec for what should happen if the param value is null.
> 
> I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated.
> 
> Currently:
> 
> - The provided value may be either null or non-null. Is null a legal value? It depends upon:
> 	- Is there an existing value?
> 	- Does the Map allow null values?
> 	- Does the function allow null values?
> - Existing null values are treated as absent. 
>        - If a null value is passed should we remove this mapping or add it to the map?
>              - null might not be accepted by the map
>              - The associated value would still be regarded as absent for future operations.
> - The function may return null to signal "remove".
> 
> In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse. 
> 
> So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly.
> 
>> The parenthesized part is wrong. 
> 
> I think that's overzealous copying from compute(). I have removed it.
> 
>> 
>> Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading.
> 
> I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param"
> 
> I have updated the webrev.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/
> 
> Thanks,
> 
> Mike
> 
>> 
>> Thanks,
>> David
>> 
>> On 23/11/2013 10:25 AM, Mike Duigou wrote:
>>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue.
>>> 
>>> I've posted a webrev here:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/
>>> 
>>> There is an identical change in ConcurrentMap's merge().
>>> 
>>> Mike
>>> 
>>> On Nov 22 2013, at 16:01 , Henry Jen  wrote:
>>> 
>>>> 
>>>> On 11/21/2013 06:33 PM, David Holmes wrote:
>>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote:
>>>>>> While I agree that case should be specified, I'm not certain I follow why
>>>>>> that's what's going on here.
>>>>>> 
>>>>>> The weird condition is that if oldValue is null, not value; oldValue
>>>>>> is the
>>>>>> old result of map.get(key).  The Javadoc seems not just unspecified, but
>>>>>> actively wrong.  Here's a worked example:
>>>>>> 
>>>>>> Map map = new HashMap<>();
>>>>>> map.merge("foo", 3, Integer::plus);
>>>>>> Integer fooValue = map.get("foo");
>>>>>> 
>>>>>> Going through the Javadoc-specified default implementation:
>>>>>> 
>>>>>>  V oldValue = map.get(key); // oldValue is null
>>>>>>  V newValue = (oldValue == null) ? value :
>>>>>>               remappingFunction.apply(oldValue, value);
>>>>>>     // newValue is set to value, which is 3
>>>>>>  if (newValue == null) // newValue is nonnull, branch not taken
>>>>>>      map.remove(key);
>>>>>>  else if (oldValue == null) // oldValue is null, branch taken
>>>>>>      map.remove(key); // removes the entry from the map
>>>>>>  else // else if was already triggered, branch not taken
>>>>>>      map.put(key, newValue);
>>>>>> 
>>>> 
>>>> Seems like a document bug to me, we should fix this @implSpec.
>>>> 
>>>> Cheers,
>>>> Henry
>>>> 
>>> 
> 



From dl at cs.oswego.edu  Sat Dec  7 12:24:04 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 07 Dec 2013 07:24:04 -0500
Subject: RFR: 8029055: Map.merge must refuse null values
In-Reply-To: 
References: 	<528E568D.8020909@oracle.com>	
	<528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com>
	
	<52929A59.20204@oracle.com>
	<63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com>
	
Message-ID: <52A31364.1070801@cs.oswego.edu>

On 12/06/2013 05:18 PM, Mike Duigou wrote:
> Hello all. I have updated the webrev
>
> http://cr.openjdk.java.net/~mduigou/JDK-8029055/2/webrev/
>

In light of all the churn on merge and related methods, I did
an editorial pass on jsr166 version of ConcurrentMap. I added
a couple of paragraphs at top-level trying to clue users in
about the issues. And then removed some now-unneeded wording
in some of the per-method specs.
Could you integrate into this webrev?
(http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentMap.java?view=log)

Here's the top-level addition:

  * 
        To support atomic usages, ConcurrentMaps are expected not to
  * allow {@code null} as a legal value (and to throw exceptions upon
  * attempted insertions). This enables a return value of {@code null}
  * to unambiguously indicate the absence of a mapping. This interface
  * does not strictly forbid implementations that may hold {@code null}
  * values. However, in any that do so, a {@code null} value must bear
  * the same interpretation as the absence of a mapping in order to
  * conform to method atomicity requirements.  Further, any that do so
  * must override all default method implementations.
  *
  * 
        Several methods (for example {@link #putIfAbsent}) inherited
  * from {@link Map} do not have default implementations, and so must
  * be provided by implementations of this interface, even though they
  * have (non-atomic) default implementations in the {@link Map}
  * interface.
  *

Maybe there is some way to adapt a weaker form of the first paragraph
in Map proper? (Replacing "atomic" with "reliable" :-) When worded
in the above way, the only sanctioned user-level difference
between a map allowing nulls vs one that doesn't is that the
former may have entries explicitly recording absent mappings
rather than omitting them. (Note that this means their size()'s
iterators, etc may differ.) It strikes me that this is the only
allowable difference given all of the Map method specs,
so it may be worth saying so explicitly.

-Doug



From dan.xu at oracle.com  Sun Dec  8 17:29:52 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Sun, 08 Dec 2013 09:29:52 -0800
Subject: RFR: JDK-8022219,Intermittent test failures in java/util/zip/ZipFile
Message-ID: <52A4AC90.1020102@oracle.com>

Hi All,

Please review the fix towards the intermittent test failure in 
java/util/zip/ZipFile. It is a similar failure that I encountered 
before, due to the interferences from other software or daemon services 
in Windows platforms. The fix is to use the method from FileUtils test 
library to handle the problem at its best effort. Thanks!

Bug: https://bugs.openjdk.java.net/browse/JDK-8022219
Webrev: http://cr.openjdk.java.net/~dxu/8022219/webrev/ 


-Dan


From peter.levart at gmail.com  Sun Dec  8 19:19:53 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 08 Dec 2013 20:19:53 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <529E68E5.7000103@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com>
Message-ID: <52A4C659.4020406@gmail.com>


On 12/04/2013 12:27 AM, Mandy Chung wrote:
>
> On 12/3/2013 1:44 AM, Peter Levart wrote:
>> On 12/03/2013 09:51 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> While browsing the code of java.util.logging.Handler, I noticed a 
>>> theoretical possibility that a security check in a 
>>> j.u.l.StreamHandler be circumvented using a data race.
>>>
>>> There is a plain boolean instance field 'sealed' in j.u.l.Handler 
>>> that is pre-initialized to 'true' in field initializer. 
>>> StreamHandler sublcass' constructors overwrite this value with 
>>> 'false' at the beginning, then issue some operations which 
>>> circumvent security checks, and finally they reset the 'sealed' 
>>> value back to 'true' at the end.
>>>
>>> If a reference to an instance of StreamHandler or subclass is passed 
>>> to some thread without synchronization via data-race, this thread 
>>> can see 'true' or 'false' as the possible values of 'sealed' 
>>> variable, thus it is possible to circumvent security checks.
>>>
>>> One possibility to fix this is moving the field to StreamHandler and 
>>> making it final:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/ 
>>>
>>>
>>> Just making the field volatile might not work. There is an ongoing 
>>> debate on concurrency-interest which suggests that volatile fields 
>>> are not exceptional in constructors like final fields are...
>>>
>>>
>>> Regards, Peter
>>>
>>
>> The proposed patch is not complete. There are several subclasses of 
>> StreamHandler in the java.util.logging package that also need a way 
>> to bypass security checks for some operations in their constructors. 
>> So here's the updated webrev which updates them with the same code as 
>> StreamHandler. This means that there are two copies of 'sealed' flag 
>> in object of type ConsoleHandler, for example, but only the one 
>> declared in ConsoleHandler is relevant for governing access checks:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.02/ 
>>
>>
>> Before filing the bug, I'm asking the list whether this can be 
>> considered a bug...
>>
>
> This does look a possible data race that might return a partially 
> constructed object with sealed = false.  I am not sure how likely we 
> will run into this race though.
>
> W.r.t. the patch, it might be better to get rid of the sealed field 
> and wrap the calls with doPrivileged with limited privilege (just 
> LoggingPermission("control"))
>
> Mandy

H Mandy,

I created an issue for it nevertheless:

     https://bugs.openjdk.java.net/browse/JDK-8029781

You're right, doPrivileged() is a more straight-forward approach than 
'sealed' variable. Since this might only be considered for inclusion in 
JDK9 when lambdas are already a tried technology, how do you feel about 
using them for platform code like logging? As far as I know (just 
checked), lambda meta-factory is not using any j.u.logging, so there is 
no danger of initialization loops or similar:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/


Regards, Peter



From zhangshj at linux.vnet.ibm.com  Mon Dec  9 07:02:17 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Mon, 09 Dec 2013 15:02:17 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: 
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
Message-ID: <52A56AF9.7050801@linux.vnet.ibm.com>

On 12/6/2013 12:53 AM, Jason Mehrens wrote:
> Shi Jun Zhang,
>
> This problem is like hooking up your sink drain to your sink faucet.  
> Even if it you can get it to work you still would not want to use 
> it.   In your code example you could just pre-pend the thread name to 
> the formatter string and return it.

Hi Jason,

This would work and we already have several workarounds including this one.

>
> However, if you really, really, really, want to attempt this type of 
> trick you have to use JDK8 and create a custom Filter to generate log 
> records.  If you use a filter, you can ditch the thread local in favor 
> of checking the source class of the log record to determine the proper 
> action.  Or if you are using a JDK prior to JDK8 then install the 
> filter on the logger instead of the handler to avoid the locking.

I don't see how Filter can avoid the deadlock, Handler.isLoggable() is 
still called inside Handler.publish(). As long as we call Logger.log 
inside itself with 2 or more handlers in root logger, the deadlock would 
happen.

>
> Peter, Daniel,
>
> An optimistic tail string would break all formatters that write out 
> summary statistics (num of records, min millis, and max 
> mills).  Instead of changing the formatter synchronization, I think a 
> more useful solution would be to create an AsyncHandler that would 
> disconnect user code from the act of publishing log records.  Then all 
> of handler and formatter locking fall rights into the nice biased 
> locking scenario.

Peter,

I think you are misunderstanding this problem. This deadlock is not 
related to the formatter synchronization, we can make 
CustomerFormatter.format not synchronized and not call super.format, the 
deadlock still happens.

>
> Jason
>
> > Hi Shi Jun Zhang,
> >
> > I have looked at this, creating a prototype. It re-arranged
> > synchronization in a way so that all Formatter methods are invoked out
> > of synchronized sections. I haven't come forward with this yet, because
> > of two issues:
> > - Formatter implementations would suddenly be called multi-threaded.
> > Currently they are invoked from within Handler-instance synchronized
> > sections.
> > - Formatter would have to be invoked optimistically to obtain head and
> > tail strings, so it could happen that a head, for example, would be
> > requested concurrently multiple times, but only one of returned heads
> > would be written to stream then.
> >
> > The 1st thing seems problematic. I can imagine there exist Formatters
> > that are not thread-safe (for example, using single instance of
> > MessageFormat, which is not multi-threaded) and now just happen to work
> > as a consequence of current StreamHandler implementation detail, but
> > would break if called multi-threaded.
> >
> > One way to remedy this is to add a boolean property to Formatter API,
> > say Formatter.isMultiThreaded(), and arrange so that appropriate
> > instances return appropriate values also considering
> > backwards-compatibility...
> >
> > So all-in-all this is not a simple patch and I doubt it can be made for
> > JDK8. In JDK9, I think, it will be possible to re-visit this issue, so
> > It would be good to file it as a BUG or RFI.
> >
> >
> > Regards, Peter
> >
>


-- 
Regards,

Shi Jun Zhang



From sundararajan.athijegannathan at oracle.com  Mon Dec  9 07:10:43 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 09 Dec 2013 07:10:43 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20131209071045.B70B062B7F@hg.openjdk.java.net>

Changeset: 752554d45a07
Author:    sundar
Date:      2013-12-09 09:48 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/752554d45a07

8029612: the typeErrorThrower field in ScriptFunctionImpl cannot be static and common to all Globals
Reviewed-by: attila, hannesw

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java

Changeset: 739f3abdfa55
Author:    sundar
Date:      2013-12-09 09:53 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/739f3abdfa55

Merge




From peter.levart at gmail.com  Mon Dec  9 08:28:55 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Dec 2013 09:28:55 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A56AF9.7050801@linux.vnet.ibm.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com>
Message-ID: <52A57F47.8070503@gmail.com>

On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
> Peter,
>
> I think you are misunderstanding this problem. This deadlock is not 
> related to the formatter synchronization, we can make 
> CustomerFormatter.format not synchronized and not call super.format, 
> the deadlock still happens.

I'm not saying that your formatters are explicitly synchronized - all 
formatters are currently effectively synchronized by LogHandlers. The 
Formatter is invoked from within LogHandler's publish() method which is 
synchronized (on LogHandler.this). If formatters were invoked out of 
this synchronized section, there would be no danger of deadlocks when 
using Logger.log from within custom formatters. But then other issues 
would arise as a consequence of non-multithreaded formatters being 
invoked concurrently...

Regards, Peter



From paul.sandoz at oracle.com  Mon Dec  9 08:37:24 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Dec 2013 09:37:24 +0100
Subject: RFR: 8029696 : (xs) Broken doc links to
	package-summary.html#NonInterference in java.util.stream
In-Reply-To: 
References: 
Message-ID: <40EBB1E4-4204-463D-87E9-722E57C8967E@oracle.com>


On Dec 6, 2013, at 8:59 PM, Mike Duigou  wrote:

> Hello all;
> 
> https://bugs.openjdk.java.net/browse/JDK-8029696
> 
> Michael McMahon noticed that some links to the anchor #NonInterference were not using the correct name for the anchor. He prepared a patch which I reviewed, tested. I also checked to make sure there were no other broken instances.
> 
> I've prepared a webrev of the patch for anyone else who wishes to review.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8029696/0/webrev/
> 

+1

Paul.

From peter.levart at gmail.com  Mon Dec  9 08:40:15 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Dec 2013 09:40:15 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A57F47.8070503@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
Message-ID: <52A581EF.3020700@gmail.com>

On 12/09/2013 09:28 AM, Peter Levart wrote:
> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>> Peter,
>>
>> I think you are misunderstanding this problem. This deadlock is not 
>> related to the formatter synchronization, we can make 
>> CustomerFormatter.format not synchronized and not call super.format, 
>> the deadlock still happens.
>
> I'm not saying that your formatters are explicitly synchronized - all 
> formatters are currently effectively synchronized by LogHandlers. The 
> Formatter is invoked from within LogHandler's publish() method which 
> is synchronized (on LogHandler.this). If formatters were invoked out 
> of this synchronized section, there would be no danger of deadlocks 
> when using Logger.log from within custom formatters. But then other 
> issues would arise as a consequence of non-multithreaded formatters 
> being invoked concurrently...
>
> Regards, Peter
>

I think the best solution to your problem (or a work-around if you say 
so) was suggested by Jason Mehrens few messages ago - decoupling of user 
code from publishing of log records - by creating an AsyncLogHandler 
that is just feeding a FIFO queue with log records which are processed 
by a background thread by pop-ing them out of queue and sticking them in 
the actual LogHandler.publish(). If the queue is unbouded or large 
enough so that it never fills up, there's no danger of dead-locks even 
if you invoke Logger.log from custom formatters in such background 
publishing thread.

Regards, Peter



From zhangshj at linux.vnet.ibm.com  Mon Dec  9 08:51:49 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Mon, 09 Dec 2013 16:51:49 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A57F47.8070503@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
Message-ID: <52A584A5.4080208@linux.vnet.ibm.com>

On 12/9/2013 4:28 PM, Peter Levart wrote:
> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>> Peter,
>>
>> I think you are misunderstanding this problem. This deadlock is not 
>> related to the formatter synchronization, we can make 
>> CustomerFormatter.format not synchronized and not call super.format, 
>> the deadlock still happens.
>
> I'm not saying that your formatters are explicitly synchronized - all 
> formatters are currently effectively synchronized by LogHandlers. The 
> Formatter is invoked from within LogHandler's publish() method which 
> is synchronized (on LogHandler.this). If formatters were invoked out 
> of this synchronized section, there would be no danger of deadlocks 
> when using Logger.log from within custom formatters. But then other 
> issues would arise as a consequence of non-multithreaded formatters 
> being invoked concurrently...
>
> Regards, Peter
>
Hi Peter,

We have thought about moving formatter out of the synchronized section 
of Handler.publish(), it can avoid the deadlock. However, we can 
reproduce the similar deadlock by extending the Writer in Handler and 
using logger in the customized Writer.

-- 
Regards,

Shi Jun Zhang



From peter.levart at gmail.com  Mon Dec  9 08:58:18 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Dec 2013 09:58:18 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A584A5.4080208@linux.vnet.ibm.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
	<52A584A5.4080208@linux.vnet.ibm.com>
Message-ID: <52A5862A.5040306@gmail.com>

On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
> On 12/9/2013 4:28 PM, Peter Levart wrote:
>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>> Peter,
>>>
>>> I think you are misunderstanding this problem. This deadlock is not 
>>> related to the formatter synchronization, we can make 
>>> CustomerFormatter.format not synchronized and not call super.format, 
>>> the deadlock still happens.
>>
>> I'm not saying that your formatters are explicitly synchronized - all 
>> formatters are currently effectively synchronized by LogHandlers. The 
>> Formatter is invoked from within LogHandler's publish() method which 
>> is synchronized (on LogHandler.this). If formatters were invoked out 
>> of this synchronized section, there would be no danger of deadlocks 
>> when using Logger.log from within custom formatters. But then other 
>> issues would arise as a consequence of non-multithreaded formatters 
>> being invoked concurrently...
>>
>> Regards, Peter
>>
> Hi Peter,
>
> We have thought about moving formatter out of the synchronized section 
> of Handler.publish(), it can avoid the deadlock. However, we can 
> reproduce the similar deadlock by extending the Writer in Handler and 
> using logger in the customized Writer.
>

That's right. And the remedy for that situation would also be what Jason 
Mehrens suggested - asynchronous publishing.

Regards, Peter


From zhangshj at linux.vnet.ibm.com  Mon Dec  9 09:50:54 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Mon, 09 Dec 2013 17:50:54 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A581EF.3020700@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com>
	<52A57F47.8070503@gmail.com> <52A581EF.3020700@gmail.com>
Message-ID: <52A5927E.9020200@linux.vnet.ibm.com>

On 12/9/2013 4:40 PM, Peter Levart wrote:
> On 12/09/2013 09:28 AM, Peter Levart wrote:
>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>> Peter,
>>>
>>> I think you are misunderstanding this problem. This deadlock is not 
>>> related to the formatter synchronization, we can make 
>>> CustomerFormatter.format not synchronized and not call super.format, 
>>> the deadlock still happens.
>>
>> I'm not saying that your formatters are explicitly synchronized - all 
>> formatters are currently effectively synchronized by LogHandlers. The 
>> Formatter is invoked from within LogHandler's publish() method which 
>> is synchronized (on LogHandler.this). If formatters were invoked out 
>> of this synchronized section, there would be no danger of deadlocks 
>> when using Logger.log from within custom formatters. But then other 
>> issues would arise as a consequence of non-multithreaded formatters 
>> being invoked concurrently...
>>
>> Regards, Peter
>>
>
> I think the best solution to your problem (or a work-around if you say 
> so) was suggested by Jason Mehrens few messages ago - decoupling of 
> user code from publishing of log records - by creating an 
> AsyncLogHandler that is just feeding a FIFO queue with log records 
> which are processed by a background thread by pop-ing them out of 
> queue and sticking them in the actual LogHandler.publish(). If the 
> queue is unbouded or large enough so that it never fills up, there's 
> no danger of dead-locks even if you invoke Logger.log from custom 
> formatters in such background publishing thread.
>
> Regards, Peter
>
Hi Peter,

Would the following situation happen if we use AsyncLogHandler? Some 
error happens and it causes the jvm crashes or System.exit() is called, 
however the related log record which contains important message is still 
in the queue and not printed. If so, I think it's unacceptable.

-- 
Regards,

Shi Jun Zhang



From daniel.fuchs at oracle.com  Mon Dec  9 10:12:27 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 09 Dec 2013 11:12:27 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A5862A.5040306@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
	<52A584A5.4080208@linux.vnet.ibm.com> <52A5862A.5040306@gmail.com>
Message-ID: <52A5978B.2050604@oracle.com>

On 12/9/13 9:58 AM, Peter Levart wrote:
> On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
>> On 12/9/2013 4:28 PM, Peter Levart wrote:
>>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>>> Peter,
>>>>
>>>> I think you are misunderstanding this problem. This deadlock is not
>>>> related to the formatter synchronization, we can make
>>>> CustomerFormatter.format not synchronized and not call super.format,
>>>> the deadlock still happens.
>>>
>>> I'm not saying that your formatters are explicitly synchronized - all
>>> formatters are currently effectively synchronized by LogHandlers. The
>>> Formatter is invoked from within LogHandler's publish() method which
>>> is synchronized (on LogHandler.this). If formatters were invoked out
>>> of this synchronized section, there would be no danger of deadlocks
>>> when using Logger.log from within custom formatters. But then other
>>> issues would arise as a consequence of non-multithreaded formatters
>>> being invoked concurrently...
>>>
>>> Regards, Peter
>>>
>> Hi Peter,
>>
>> We have thought about moving formatter out of the synchronized section
>> of Handler.publish(), it can avoid the deadlock. However, we can
>> reproduce the similar deadlock by extending the Writer in Handler and
>> using logger in the customized Writer.
>>
>
> That's right. And the remedy for that situation would also be what Jason
> Mehrens suggested - asynchronous publishing.

Hi,

I agree with Peter & Jason - asynchronous publishing seems like a good
solution. I believe the LogManager will close all handlers on exiting,
so you might want to make sure that your asynchronous handler flushes
the queue before quitting - which could still be tricky if flushing
the queue produces new log messages for the queue - and also because
you will want Handler.close() to wait until the queue is empty.

Anyway - the best advice still is IMHO - don't call Logger.log while
publishing a log message. This should save you from a lot of issues,
like the one you encountered - but also possible stack overflows etc...

best regards,

-- daniel


>
> Regards, Peter



From daniel.fuchs at oracle.com  Mon Dec  9 11:48:11 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 09 Dec 2013 12:48:11 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52A4C659.4020406@gmail.com>
References: <529D9BAC.1020904@gmail.com>
	<529DA808.7070009@gmail.com>	<529E68E5.7000103@oracle.com>
	<52A4C659.4020406@gmail.com>
Message-ID: <52A5ADFB.7070107@oracle.com>

Hi Peter,

I had a look at your later webrev 03 and it looks like a good
solution to fix the issue. I am glad to see the sealed
variable removed.

About using lambda I don't know whether we have guidelines
for that - in this case it certainly makes the code more
concise. It is good to remember that it might mean more
work in backporting fixes though - for those fixes that will
need to be backported.

It will be good to hear about Mandy's opinion...

best regards,

-- daniel

On 12/8/13 8:19 PM, Peter Levart wrote:
>
> On 12/04/2013 12:27 AM, Mandy Chung wrote:
>>
>> On 12/3/2013 1:44 AM, Peter Levart wrote:
>>> On 12/03/2013 09:51 AM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> While browsing the code of java.util.logging.Handler, I noticed a
>>>> theoretical possibility that a security check in a
>>>> j.u.l.StreamHandler be circumvented using a data race.
>>>>
>>>> There is a plain boolean instance field 'sealed' in j.u.l.Handler
>>>> that is pre-initialized to 'true' in field initializer.
>>>> StreamHandler sublcass' constructors overwrite this value with
>>>> 'false' at the beginning, then issue some operations which
>>>> circumvent security checks, and finally they reset the 'sealed'
>>>> value back to 'true' at the end.
>>>>
>>>> If a reference to an instance of StreamHandler or subclass is passed
>>>> to some thread without synchronization via data-race, this thread
>>>> can see 'true' or 'false' as the possible values of 'sealed'
>>>> variable, thus it is possible to circumvent security checks.
>>>>
>>>> One possibility to fix this is moving the field to StreamHandler and
>>>> making it final:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/
>>>>
>>>>
>>>> Just making the field volatile might not work. There is an ongoing
>>>> debate on concurrency-interest which suggests that volatile fields
>>>> are not exceptional in constructors like final fields are...
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>
>>> The proposed patch is not complete. There are several subclasses of
>>> StreamHandler in the java.util.logging package that also need a way
>>> to bypass security checks for some operations in their constructors.
>>> So here's the updated webrev which updates them with the same code as
>>> StreamHandler. This means that there are two copies of 'sealed' flag
>>> in object of type ConsoleHandler, for example, but only the one
>>> declared in ConsoleHandler is relevant for governing access checks:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.02/
>>>
>>>
>>> Before filing the bug, I'm asking the list whether this can be
>>> considered a bug...
>>>
>>
>> This does look a possible data race that might return a partially
>> constructed object with sealed = false.  I am not sure how likely we
>> will run into this race though.
>>
>> W.r.t. the patch, it might be better to get rid of the sealed field
>> and wrap the calls with doPrivileged with limited privilege (just
>> LoggingPermission("control"))
>>
>> Mandy
>
> H Mandy,
>
> I created an issue for it nevertheless:
>
>      https://bugs.openjdk.java.net/browse/JDK-8029781
>
> You're right, doPrivileged() is a more straight-forward approach than
> 'sealed' variable. Since this might only be considered for inclusion in
> JDK9 when lambdas are already a tried technology, how do you feel about
> using them for platform code like logging? As far as I know (just
> checked), lambda meta-factory is not using any j.u.logging, so there is
> no danger of initialization loops or similar:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
>
>
> Regards, Peter
>



From peter.levart at gmail.com  Mon Dec  9 12:04:00 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Dec 2013 13:04:00 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A5927E.9020200@linux.vnet.ibm.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com>
	<52A57F47.8070503@gmail.com> <52A581EF.3020700@gmail.com>
	<52A5927E.9020200@linux.vnet.ibm.com>
Message-ID: <52A5B1B0.6090707@gmail.com>

On 12/09/2013 10:50 AM, Shi Jun Zhang wrote:
> On 12/9/2013 4:40 PM, Peter Levart wrote:
>> On 12/09/2013 09:28 AM, Peter Levart wrote:
>>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>>> Peter,
>>>>
>>>> I think you are misunderstanding this problem. This deadlock is not 
>>>> related to the formatter synchronization, we can make 
>>>> CustomerFormatter.format not synchronized and not call 
>>>> super.format, the deadlock still happens.
>>>
>>> I'm not saying that your formatters are explicitly synchronized - 
>>> all formatters are currently effectively synchronized by 
>>> LogHandlers. The Formatter is invoked from within LogHandler's 
>>> publish() method which is synchronized (on LogHandler.this). If 
>>> formatters were invoked out of this synchronized section, there 
>>> would be no danger of deadlocks when using Logger.log from within 
>>> custom formatters. But then other issues would arise as a 
>>> consequence of non-multithreaded formatters being invoked 
>>> concurrently...
>>>
>>> Regards, Peter
>>>
>>
>> I think the best solution to your problem (or a work-around if you 
>> say so) was suggested by Jason Mehrens few messages ago - decoupling 
>> of user code from publishing of log records - by creating an 
>> AsyncLogHandler that is just feeding a FIFO queue with log records 
>> which are processed by a background thread by pop-ing them out of 
>> queue and sticking them in the actual LogHandler.publish(). If the 
>> queue is unbouded or large enough so that it never fills up, there's 
>> no danger of dead-locks even if you invoke Logger.log from custom 
>> formatters in such background publishing thread.
>>
>> Regards, Peter
>>
> Hi Peter,
>
> Would the following situation happen if we use AsyncLogHandler? Some 
> error happens and it causes the jvm crashes or System.exit() is 
> called, however the related log record which contains important 
> message is still in the queue and not printed. If so, I think it's 
> unacceptable.
>

You could install a shutdown-hook that would make sure the remaining 
queue is flushed before completing the VM exit...

Regards, Peter



From michael.x.mcmahon at oracle.com  Mon Dec  9 13:07:33 2013
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Mon, 09 Dec 2013 13:07:33 +0000
Subject: hg: jdk8/tl/jdk: 8029354: URLPermission. throws
	llegalArgumentException: Invalid characters in hostname
Message-ID: <20131209130819.6C78262B88@hg.openjdk.java.net>

Changeset: 9e579a2329c0
Author:    michaelm
Date:      2013-12-09 13:05 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e579a2329c0

8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URLPermission.java
+ test/java/net/URLPermission/OpenURL.java
! test/java/net/URLPermission/URLPermissionTest.java



From peter.levart at gmail.com  Mon Dec  9 14:01:39 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Dec 2013 15:01:39 +0100
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A5978B.2050604@oracle.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
	<52A584A5.4080208@linux.vnet.ibm.com>
	<52A5862A.5040306@gmail.com> <52A5978B.2050604@oracle.com>
Message-ID: <52A5CD43.40105@gmail.com>

On 12/09/2013 11:12 AM, Daniel Fuchs wrote:
> On 12/9/13 9:58 AM, Peter Levart wrote:
>> On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
>>> On 12/9/2013 4:28 PM, Peter Levart wrote:
>>>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>>>> Peter,
>>>>>
>>>>> I think you are misunderstanding this problem. This deadlock is not
>>>>> related to the formatter synchronization, we can make
>>>>> CustomerFormatter.format not synchronized and not call super.format,
>>>>> the deadlock still happens.
>>>>
>>>> I'm not saying that your formatters are explicitly synchronized - all
>>>> formatters are currently effectively synchronized by LogHandlers. The
>>>> Formatter is invoked from within LogHandler's publish() method which
>>>> is synchronized (on LogHandler.this). If formatters were invoked out
>>>> of this synchronized section, there would be no danger of deadlocks
>>>> when using Logger.log from within custom formatters. But then other
>>>> issues would arise as a consequence of non-multithreaded formatters
>>>> being invoked concurrently...
>>>>
>>>> Regards, Peter
>>>>
>>> Hi Peter,
>>>
>>> We have thought about moving formatter out of the synchronized section
>>> of Handler.publish(), it can avoid the deadlock. However, we can
>>> reproduce the similar deadlock by extending the Writer in Handler and
>>> using logger in the customized Writer.
>>>
>>
>> That's right. And the remedy for that situation would also be what Jason
>> Mehrens suggested - asynchronous publishing.
>
> Hi,
>
> I agree with Peter & Jason - asynchronous publishing seems like a good
> solution. I believe the LogManager will close all handlers on exiting,
> so you might want to make sure that your asynchronous handler flushes
> the queue before quitting - which could still be tricky if flushing
> the queue produces new log messages for the queue - and also because
> you will want Handler.close() to wait until the queue is empty.

You're right, Daniel. There already is a global shut-down hook installed 
in LogManager that close()s all
active handlers when VM is shutting down.

Shi Jun Zhang, here's a quick mock-up of a prototype AsyncHandler that 
might work for you:

http://cr.openjdk.java.net/~plevart/misc/jul.AsyncHandler/AsyncHandler.java

Regards, Peter

>
> Anyway - the best advice still is IMHO - don't call Logger.log while
> publishing a log message. This should save you from a lot of issues,
> like the one you encountered - but also possible stack overflows etc...
>
> best regards,
>
> -- daniel
>
>
>>
>> Regards, Peter
>



From bourges.laurent at gmail.com  Mon Dec  9 17:59:26 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 9 Dec 2013 18:59:26 +0100
Subject: Conflicts between JVM application and j.u.l logging shutdown hooks
Message-ID: 

Anybody wants to look at this logging issue I reported several months ago?

Le 27 juin 2013 11:57, "Laurent Bourg?s"  a
?crit :
>
> Dear members,
>
> I have a problem within an external library using one JVM Shutdown hook
to perform resource cleanup (socket, lock file deletion ...) that seems
buggy in java web start environment: sometimes the JVM reports an
IllegalStateException happenning during that shutdown hook.
>
> This library uses java.util.logging to log warnings and exceptions but
none is logged (console or java trace files).
>
> The 'lost' log messages is related to the LogManager's shutdown hook:
>     // This private class is used as a shutdown hook.
>     // It does a "reset" to close all open handlers.
>     private class Cleaner extends Thread {
>
>         private Cleaner() {
>             /* Set context class loader to null in order to avoid
>              * keeping a strong reference to an application classloader.
>              */
>             this.setContextClassLoader(null);
>         }
>
>         public void run() {
>             // This is to ensure the LogManager. is completed
>             // before synchronized block. Otherwise deadlocks are
possible.
>             LogManager mgr = manager;
>
>             // If the global handlers haven't been initialized yet, we
>             // don't want to initialize them just so we can close them!
>             synchronized (LogManager.this) {
>                 // Note that death is imminent.
>                 deathImminent = true;
>                 initializedGlobalHandlers = true;
>             }
>
>             // Do a reset to close all active handlers.
>             reset();
>         }
>     }
>
> Without any log handler, the log messages are lost during shutdown !
> I think it is annoying as it avoids me getting log and exceptions ...
>
> FYI, the ApplicationShutdownHooks class executes all 'application' hooks
concurrently:
>     static void runHooks() {
>         Collection threads;
>         synchronized(ApplicationShutdownHooks.class) {
>             threads = hooks.keySet();
>             hooks = null;
>         }
>
>         for (Thread hook : threads) {
>             hook.start();
>         }
>         for (Thread hook : threads) {
>             try {
>                 hook.join();
>             } catch (InterruptedException x) { }
>         }
>     }
> So it is not possible to define hook priorities ...
>
> However, I looked at the JVM Shutdown class which supports hook
priorities and I think that the J.U.L Cleaner hook should run after all
application hooks.
> Here are the current Shutdown priorities:
>     // The system shutdown hooks are registered with a predefined slot.
>     // The list of shutdown hooks is as follows:
>     // (0) Console restore hook
>     // (1) Application hooks
>     // (2) DeleteOnExit hook
>
> Moreover, as a RFE, it could be useful for applications to be able to
define hook priorities within an application:
> I did that several times registering only 1 shutdown hook and handling
correct ordering on my own ... but could be supported by the JDK itself.
>
> Finally, here are (below) the Open JDK8 usages of Runtime.addShutdownHook
[19 occurrences] which are more system hooks than application hooks:
> com.sun.imageio.stream
> StreamCloser.java
> StreamCloser
> addToQueue
> 
> run
>   101:  Runtime.getRuntime().addShutdownHook(streamCloser);
> java.util.logging
> LogManager.java
> LogManager
> LogManager
>   255:  Runtime.getRuntime().addShutdownHook(new Cleaner());
> sun.font
> SunFontManager.java
> SunFontManager
> createFont2D
> 
> run
> 2538:  Runtime.getRuntime().addShutdownHook(fileCloser);
> sun.rmi.server
> Activation.java
> Activation
> init
>   240:  Runtime.getRuntime().addShutdownHook(shutdownHook);
> sun.tools.jstat
>
> sun.awt.shell
> Win32ShellFolderManager2.java
> Win32ShellFolderManager2
> ComInvoker
> ComInvoker
> >
> run
>   493:  Runtime.getRuntime().addShutdownHook(
> sun.awt.windows
> WToolkit.java
> WToolkit
> registerShutdownHook
> >
> run
>   285:  Runtime.getRuntime().addShutdownHook(shutdown);
> sun.java2d.d3d
> D3DScreenUpdateManager.java
> D3DScreenUpdateManager
> D3DScreenUpdateManager
> 
> run
>   112:  Runtime.getRuntime().addShutdownHook(shutdown);
> java.util.prefs
> FileSystemPreferences.java
> FileSystemPreferences
> >
> run
>   439:  Runtime.getRuntime().addShutdownHook(new Thread() {
> sun.awt.X11
> XToolkit.java
> XToolkit
> init
> >
> run
>   350:  Runtime.getRuntime().addShutdownHook(shutdownThread);
> sun.awt
> X11GraphicsDevice.java
> X11GraphicsDevice
> setDisplayMode
> >
> run
>   445:  Runtime.getRuntime().addShutdownHook(t);
> java.util.prefs
> MacOSXPreferencesFile.java
> MacOSXPreferencesFile
> timer
>   356:  Runtime.getRuntime().addShutdownHook(flushThread);
> sun.font
> CFontManager.java
> CFontManager
> createFont2D
> >
> run
>   232:  Runtime.getRuntime().addShutdownHook(fileCloser);
> sun.lwawt
> LWToolkit.java
> LWToolkit
> init
>     83:  Runtime.getRuntime().addShutdownHook(
>
> I hope that these hooks are already supporting concurrency execution (awt
?) but someone should check if there is no dependencies between them (like
systemd or rc scripts does).
>
> PS: As shutdown hooks are given by the application as Thread class
instances, I suspect also a possible classloader leak ? In Java web start
environment, it may be the cause of my problems as I do not know if the
hook thread is still within the application class loader ...
>
> Laurent Bourg?s


From david.lloyd at redhat.com  Mon Dec  9 18:22:32 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 09 Dec 2013 12:22:32 -0600
Subject: Conflicts between JVM application and j.u.l logging shutdown hooks
In-Reply-To: 
References: 
Message-ID: <52A60A68.2060401@redhat.com>

Given that this issue has existed (and been known) since 1.4, I doubt 
anyone is particularly inclined to fix it.  The most common workaround I 
know of is to simply use or create a LogManager that implements reset() 
as a no-op.  Just subclassing the built-in LogManager is sufficient to 
do this.

On 12/09/2013 11:59 AM, Laurent Bourg?s wrote:
> Anybody wants to look at this logging issue I reported several months ago?
>
> Le 27 juin 2013 11:57, "Laurent Bourg?s"  a
> ?crit :
>>
>> Dear members,
>>
>> I have a problem within an external library using one JVM Shutdown hook
> to perform resource cleanup (socket, lock file deletion ...) that seems
> buggy in java web start environment: sometimes the JVM reports an
> IllegalStateException happenning during that shutdown hook.
>>
>> This library uses java.util.logging to log warnings and exceptions but
> none is logged (console or java trace files).
>>
>> The 'lost' log messages is related to the LogManager's shutdown hook:
>>      // This private class is used as a shutdown hook.
>>      // It does a "reset" to close all open handlers.
>>      private class Cleaner extends Thread {
>>
>>          private Cleaner() {
>>              /* Set context class loader to null in order to avoid
>>               * keeping a strong reference to an application classloader.
>>               */
>>              this.setContextClassLoader(null);
>>          }
>>
>>          public void run() {
>>              // This is to ensure the LogManager. is completed
>>              // before synchronized block. Otherwise deadlocks are
> possible.
>>              LogManager mgr = manager;
>>
>>              // If the global handlers haven't been initialized yet, we
>>              // don't want to initialize them just so we can close them!
>>              synchronized (LogManager.this) {
>>                  // Note that death is imminent.
>>                  deathImminent = true;
>>                  initializedGlobalHandlers = true;
>>              }
>>
>>              // Do a reset to close all active handlers.
>>              reset();
>>          }
>>      }
>>
>> Without any log handler, the log messages are lost during shutdown !
>> I think it is annoying as it avoids me getting log and exceptions ...
>>
>> FYI, the ApplicationShutdownHooks class executes all 'application' hooks
> concurrently:
>>      static void runHooks() {
>>          Collection threads;
>>          synchronized(ApplicationShutdownHooks.class) {
>>              threads = hooks.keySet();
>>              hooks = null;
>>          }
>>
>>          for (Thread hook : threads) {
>>              hook.start();
>>          }
>>          for (Thread hook : threads) {
>>              try {
>>                  hook.join();
>>              } catch (InterruptedException x) { }
>>          }
>>      }
>> So it is not possible to define hook priorities ...
>>
>> However, I looked at the JVM Shutdown class which supports hook
> priorities and I think that the J.U.L Cleaner hook should run after all
> application hooks.
>> Here are the current Shutdown priorities:
>>      // The system shutdown hooks are registered with a predefined slot.
>>      // The list of shutdown hooks is as follows:
>>      // (0) Console restore hook
>>      // (1) Application hooks
>>      // (2) DeleteOnExit hook
>>
>> Moreover, as a RFE, it could be useful for applications to be able to
> define hook priorities within an application:
>> I did that several times registering only 1 shutdown hook and handling
> correct ordering on my own ... but could be supported by the JDK itself.
>>
>> Finally, here are (below) the Open JDK8 usages of Runtime.addShutdownHook
> [19 occurrences] which are more system hooks than application hooks:
>> com.sun.imageio.stream
>> StreamCloser.java
>> StreamCloser
>> addToQueue
>> 
>> run
>>    101:  Runtime.getRuntime().addShutdownHook(streamCloser);
>> java.util.logging
>> LogManager.java
>> LogManager
>> LogManager
>>    255:  Runtime.getRuntime().addShutdownHook(new Cleaner());
>> sun.font
>> SunFontManager.java
>> SunFontManager
>> createFont2D
>> 
>> run
>> 2538:  Runtime.getRuntime().addShutdownHook(fileCloser);
>> sun.rmi.server
>> Activation.java
>> Activation
>> init
>>    240:  Runtime.getRuntime().addShutdownHook(shutdownHook);
>> sun.tools.jstat
>>
>> sun.awt.shell
>> Win32ShellFolderManager2.java
>> Win32ShellFolderManager2
>> ComInvoker
>> ComInvoker
>> >
>> run
>>    493:  Runtime.getRuntime().addShutdownHook(
>> sun.awt.windows
>> WToolkit.java
>> WToolkit
>> registerShutdownHook
>> >
>> run
>>    285:  Runtime.getRuntime().addShutdownHook(shutdown);
>> sun.java2d.d3d
>> D3DScreenUpdateManager.java
>> D3DScreenUpdateManager
>> D3DScreenUpdateManager
>> 
>> run
>>    112:  Runtime.getRuntime().addShutdownHook(shutdown);
>> java.util.prefs
>> FileSystemPreferences.java
>> FileSystemPreferences
>> >
>> run
>>    439:  Runtime.getRuntime().addShutdownHook(new Thread() {
>> sun.awt.X11
>> XToolkit.java
>> XToolkit
>> init
>> >
>> run
>>    350:  Runtime.getRuntime().addShutdownHook(shutdownThread);
>> sun.awt
>> X11GraphicsDevice.java
>> X11GraphicsDevice
>> setDisplayMode
>> >
>> run
>>    445:  Runtime.getRuntime().addShutdownHook(t);
>> java.util.prefs
>> MacOSXPreferencesFile.java
>> MacOSXPreferencesFile
>> timer
>>    356:  Runtime.getRuntime().addShutdownHook(flushThread);
>> sun.font
>> CFontManager.java
>> CFontManager
>> createFont2D
>> >
>> run
>>    232:  Runtime.getRuntime().addShutdownHook(fileCloser);
>> sun.lwawt
>> LWToolkit.java
>> LWToolkit
>> init
>>      83:  Runtime.getRuntime().addShutdownHook(
>>
>> I hope that these hooks are already supporting concurrency execution (awt
> ?) but someone should check if there is no dependencies between them (like
> systemd or rc scripts does).
>>
>> PS: As shutdown hooks are given by the application as Thread class
> instances, I suspect also a possible classloader leak ? In Java web start
> environment, it may be the cause of my problems as I do not know if the
> hook thread is still within the application class loader ...
>>
>> Laurent Bourg?s


-- 
- DML


From martinrb at google.com  Mon Dec  9 19:23:17 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Dec 2013 11:23:17 -0800
Subject: Map doc bugs
Message-ID: 

Mike: Map.foreach and Map.replaceAll says:

 for ((Map.Entry entry : map.entrySet())


but there are stray left parens there.  Please fix.


From vicente.romero at oracle.com  Mon Dec  9 19:30:50 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 09 Dec 2013 19:30:50 +0000
Subject: hg: jdk8/tl/langtools: 8029569: internal javac cast exception when
	resolving varargs ambiguity
Message-ID: <20131209193054.2952562B8D@hg.openjdk.java.net>

Changeset: 5bf0af735c61
Author:    vromero
Date:      2013-12-09 19:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5bf0af735c61

8029569: internal javac cast exception when resolving varargs ambiguity
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out



From martinrb at google.com  Mon Dec  9 19:49:07 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Dec 2013 11:49:07 -0800
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
Message-ID: 

On Wed, Apr 17, 2013 at 4:51 PM, Mike Duigou  wrote:

>
> @apiNote : Non-normative notes about the API. Usually used for examples.
> @implSpec : Describes required behaviour of conforming implementations.
> Key is that the description is not inherited.
> @implNote : Non-normative notes about the implementation. Typically used
> for descriptions of the behaviour. Also not inherited.
>
> The tags are used primarily by default method implementations but will be
> used elsewhere as well.
>

Although I have often wished for tags such as these, (and in the distant
past held back from working on this myself due to difficulty), as currently
implemented I fear they will only increase the confusion about subtle
distinctions of normative vs. non-normative and documenting this class vs.
all subclasses.

There does not appear to be any documentation in the jdk itself about these
tags.  This email thread is the only documentation I can find.  Even when
only used internally, there needs to be clear documentation somewhere.
 Unfortunately, there is no obvious place to look for documentation on
non-standard javadoc tags.

The tags should be made public, since correct documentation is a need
everyone has.

While the tags themselves are private, their output is not.  When users
read:

Implementation Requirements:


in the javadoc, it's not at all clear what is meant - i.e. it is
requirements on implementers of *this* class in any JDK, but not
necessarily subclasses.  We should not use the word "Requirements" unless
speaking about things required of "users".  Other JDK implementers are not
the primary target of this documentation.

It's not at all easy to do this better.  Perhaps we should do away with the
one-size-fits-all @implSpec expansion.  It would be clearer if the spec
read:

The default method forEach in class Map (but not necessarily subinterfaces
or subclasses) shall behave ...


Perhaps there should be a lower-level @noInheritDoc tag to allow people to
write such prose.


From Alan.Bateman at oracle.com  Mon Dec  9 19:49:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Dec 2013 19:49:50 +0000
Subject: Conflicts between JVM application and j.u.l logging shutdown hooks
In-Reply-To: 
References: 
Message-ID: <52A61EDE.5030106@oracle.com>

On 09/12/2013 17:59, Laurent Bourg?s wrote:
> Anybody wants to look at this logging issue I reported several months ago?
>
Your previous mail mentioned 9005822, this seems to be an incident 
submitted to Java Web Start rather than java.util.logging.

I couldn't a specific bug on the topic so I've created a new one:
  8029834: LogManager's shutdown hook resets handlers before application 
shutdown hooks have completed

There are a few other issues with how this cleaner work so it looks like 
a number of issues could be looked at together.

-Alan





From srikalyan.chandrashekar at oracle.com  Mon Dec  9 20:14:46 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan)
Date: Mon, 09 Dec 2013 12:14:46 -0800
Subject: RFR for JDK-6963118 Intermittent test failure:
	test/java/nio/channels/Selector/Wakeup.java fail intermittently (win)
In-Reply-To: <529D4473.8060909@oracle.com>
References: <529D4473.8060909@oracle.com>
Message-ID: <52A624B6.9010909@oracle.com>

Hi all, a gentle reminder for review.

--
Thanks
kalyan
Ph: (408)-585-8040


On 12/2/13, 6:39 PM, srikalyan chandrashekar wrote:
> Hi all, I am working on bug JDK-6963118 
>  .
> Root Cause:
> - Sensitive timing dependency between events in Main and Sleeper 
> threads are causes for test failure.
>
> Suggested Fix:
>   1) Main thread should wait for more than 1sec(made it 3sec) and 
> check more often than 50ms(made it 1ms) intervals , sleeper thread may 
> be still waiting for interrupt/wakeup hence main thread waiting for 
> just 1sec to flag a failure is premature . The reason is especially on 
> windows high priority virus scanners etc run(we faced it when 
> simulating failures) and kept the system busy.
>   2) The test is essentially a sequence of 2 events
>   a)Firing up wakeups/interrupts followed by a
>   b)Check
>  Check the sleeper.entries value and yield the main thread as required 
> so that the above 2 events step in tandem.
>
> The webrev is hosted at 
> http://cr.openjdk.java.net/~cl/host_for_kal/6963118-Wakeup/ .
> Please let me know if you have any comments or suggestions.
> -- 
>
> --
> Thanks
> kalyan


From srikalyan.chandrashekar at oracle.com  Mon Dec  9 20:15:19 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan)
Date: Mon, 09 Dec 2013 12:15:19 -0800
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
	test failed with 'Completed != 2'
In-Reply-To: <529CDDCF.6070807@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
Message-ID: <52A624D7.9090405@oracle.com>

Hi David/Martin a gentle reminder for review.

--
Thanks
kalyan
Ph: (408)-585-8040


On 12/2/13, 11:21 AM, srikalyan wrote:
> Hi David, Thanks for the review, the new webrev is hosted at 
> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ 
> . Please see inline text.
>
> On 11/20/13, 6:35 PM, David Holmes wrote:
>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>> I again tried and failed to reproduce a failure.  Even if I go whole 
>>> hog
>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test 
>>> continues to
>>> PASS.  Is it just me?!
>>
>> I think you are going the wrong way Martin - you want the timeout to 
>> be smaller than the time it takes to execute ITERS.
>>
>>> I don't think there's any reason to make result long.  It's not even 
>>> used
>>> except to inhibit hotspot optimizations.
>>>
>>> +        private volatile long result = 17;//Can get int overflow,so 
>>> using long
>>
>> Further the subsequent use of += is incorrect as it is not an atomic 
>> operation. Even if we don't care about the value, it looks bad.
> Made the necessary changes for atomic update.
>>
>> I'm not sure result must be updated if we get a 
>> BrokenBarrierException either. Probably harmless, but necessary?
> I retained it in the fix for completeness in updating the numbers, 
> please let me know if you still think otherwise.
>>
>>> need to fix spelling and spacing below.
>>>
>>> +                barrier.await();//If a BrokeBarrierException happens
>>> here(due to
>>
>> There are a number of style issues with spacing around comments.
> Fixed the spelling error and styling issues.
>>
>> And I don't think this change is sufficient to claim co-author status 
>> with Doug either ;-)
> Removed the claim :)
>>
>> The additional tracing may be useful but seems stylistically 
>> different from the rest of the code.
> Retained the tracking to understand if it is again the timing issue 
> which is the cause in an event of a failure, however i can remove it 
> if you think it is not necessary (OR) include an alternate solution as 
> you may want to suggest.
>>
>> Overall I'm suspicious that the changed timeout actually fixes 
>> anything - normally we need to add longer timeouts not shorter ones. 
>> Does this fail on a range of machines or only specific ones? Have we 
>> verified that the clocks/timers are behaving properly on those systems?
> Here the time out is not about waiting for threads to complete 
> something but to "be interrupted" before being considered done, so we 
> decreased the timeout. However we now chose to increase the number of 
> iterations to 5000000 from 1000000(thanks to tristan for the 
> suggestion) instead of decreasing the timeout as done earlier because 
> the increasing iterations ensures the threads are busy for long time 
> curtailing the need to touch the timeout.
>
>>
>> Thanks,
>> David
>
> -- 
> Thanks
> kalyan
> Ph: (408)-585-8040
>
>>
>>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>
>>>>   Hi Martin , apologies for the delay , was trying to get help for 
>>>> hosting
>>>> my webrev.  .  Please see inline text.
>>>>
>>>>
>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>
>>>> Hi Kalyan,
>>>>
>>>>   None of us can review your changes yet because you haven't given 
>>>> us a
>>>> URL of your webrev.
>>>>
>>>> It is located here
>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ 
>>>>
>>>>
>>>>
>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>> adjusting ITERS and TIMEOUT radically up and down, but the test 
>>>> just keeps
>>>> on passing for me.  Hints appreciated.
>>>>
>>>> Bump up the timeout to 500ms and you will see a failure (i can see it
>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8
>>>> latest any promoted build).
>>>>
>>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>
>>>>>     Suggested Fix:
>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that 
>>>>>> the test
>>>>>> will pass even on faster machines
>>>>>>
>>>>>
>>>>   This doesn't look like a permanent fix - it just makes the 
>>>> failing case
>>>> rarer.
>>>>
>>>> Thats true , the other way is to make the main thread wait on TIMEOUT
>>>> after firing the interrupts instead of other way round, but that 
>>>> would be
>>>> over-optimization which probably is not desirable as well.  The 50 
>>>> ms was
>>>> arrived at empirically after running several 100 times on multiple
>>>> configurations and did not cause failures.
>>>>
>>>> -- 
>>>> Thanks
>>>> kalyan
>>>> Ph: (408)-585-8040
>>>>
>>>>
>>>>


From michael.fang at oracle.com  Mon Dec  9 23:03:27 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Mon, 09 Dec 2013 23:03:27 +0000
Subject: hg: jdk8/tl/jdk: 8025974: l10n for policytool
Message-ID: <20131209230343.0FD3262B98@hg.openjdk.java.net>

Changeset: 23a7524d930c
Author:    mfang
Date:      2013-12-09 15:01 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23a7524d930c

8025974: l10n for policytool
Reviewed-by: naoto, leifs, yhuang

! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java



From mike.duigou at oracle.com  Mon Dec  9 23:58:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 9 Dec 2013 15:58:15 -0800
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: 
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	
Message-ID: 


On Dec 9 2013, at 11:49 , Martin Buchholz  wrote:

> On Wed, Apr 17, 2013 at 4:51 PM, Mike Duigou  wrote:
> 
> @apiNote : Non-normative notes about the API. Usually used for examples.
> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
> 
> The tags are used primarily by default method implementations but will be used elsewhere as well.
> 
> Although I have often wished for tags such as these, (and in the distant past held back from working on this myself due to difficulty), as currently implemented I fear they will only increase the confusion about subtle distinctions of normative vs. non-normative and documenting this class vs. all subclasses.

If this is the case then we need to tighten up the usage

> There does not appear to be any documentation in the jdk itself about these tags.  This email thread is the only documentation I can find.  Even when only used internally, there needs to be clear documentation somewhere.  Unfortunately, there is no obvious place to look for documentation on non-standard javadoc tags.  

Writing up a doc page on these tags has been on my TO-DO list for quite some time. Unfortunately it hasn't bubbled to the top yet. As we get closer to Java 8 release the priority will certainly increase. 

> The tags should be made public, since correct documentation is a need everyone has.

There are no plans to attempt to popularize these particular tags outside of use by JDK documentation. 

> While the tags themselves are private, their output is not.  When users read:
> 
> Implementation Requirements:
> 

This is still changeable. "Required behaviour of all implementations:" perhaps?

> in the javadoc, it's not at all clear what is meant - i.e. it is requirements on implementers of *this* class in any JDK, but not necessarily subclasses.  We should not use the word "Requirements" unless speaking about things required of "users".  Other JDK implementers are not the primary target of this documentation.
> 
> It's not at all easy to do this better.  Perhaps we should do away with the one-size-fits-all @implSpec expansion.  It would be clearer if the spec read:
> 
> The default method forEach in class Map (but not necessarily subinterfaces or subclasses) shall behave ...

In part the tags were added to avoid the unfortunate inclusion of implementation specifics into the functional description.

> Perhaps there should be a lower-level @noInheritDoc tag to allow people to write such prose.

That is how these are effectively being used.

Mike




From fuyou001 at gmail.com  Tue Dec 10 00:05:13 2013
From: fuyou001 at gmail.com (fuyou)
Date: Tue, 10 Dec 2013 08:05:13 +0800
Subject: MappedFile call sync occur Cannot allocate memory
Message-ID: 

I write a MappedFile ,and a task call sync write to disk.
but occur :

java.io.IOException: Cannot allocate memory
     at java.nio.MappedByteBuffer.force0(Native Method)
     at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:154)

the os is Red Hat Enterprise Linux Server release 5.4
java is java version "1.6.0_23"
-- 
   =============================================

  fuyou001
Best Regards


From martinrb at google.com  Tue Dec 10 01:13:37 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Dec 2013 17:13:37 -0800
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: 
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	
	
Message-ID: 

On Mon, Dec 9, 2013 at 3:58 PM, Mike Duigou  wrote:

>
> While the tags themselves are private, their output is not.  When users
> read:
>
> Implementation Requirements:
>
>
> This is still changeable. "Required behaviour of all implementations:"
> perhaps?
>
>
I think this is not moving us towards clarity.   "Required behaviour of all
implementations:" actually applies more to the "regular" unlabelled
documentation, since that applies to subclasses as well.  Perhaps we want
to get rid of words like "requirements" because they apply equally to the
part not labelled "requirements"?!  The key difference is that we are
documenting the behavior of THIS method on THIS class.  Maybe:

Behavior of the default method Map.forEach:

When I was musing about doing this myself years ago, I was not motivated by
default methods (they didn't exist yet!) but instead by the "skeletal"
implementation classes like AbstractMap.  Hopefully we can @implSpec them
for jdk8?


From martinrb at google.com  Tue Dec 10 01:50:25 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Dec 2013 17:50:25 -0800
Subject: Map.forEach
Message-ID: 

Current ConcurrentMap.forEach
http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/ConcurrentMap.html#replaceAll-java.util.function.BiFunction-
has two different "specs" for the default method:

*Implementation Requirements:* The default implementation is equivalent to,
for this map:


 for (Map.Entry entry : map.entrySet())
   action.accept(entry.getKey(), entry.getValue());


*Implementation Note:* The default implementation assumes that
IllegalStateException thrown by getKey() or getValue() indicates that the
entry no longer exists. Operation continues for subsequent entries.
But these are contradictory!  Furthermore, given that any Map might end up
giving us ISE, shouldn't we be using the ConcurrentMap implementation in
Map (and specifying the ISE-skipping behavior?)  Whether or not to skip ISE
should not be an Implementation Note, I think - it should be "spec".


From mike.duigou at oracle.com  Tue Dec 10 03:49:28 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 9 Dec 2013 19:49:28 -0800
Subject: Map.forEach
In-Reply-To: 
References: 
Message-ID: <75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>


On Dec 9 2013, at 17:50 , Martin Buchholz  wrote:

> Current ConcurrentMap.forEach
> http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/ConcurrentMap.html#replaceAll-java.util.function.BiFunction-
> has two different "specs" for the default method:
> 
> Implementation Requirements:
> The default implementation is equivalent to, for this map:
>  
>  for (Map.Entry entry : map.entrySet())
>    action.accept(entry.getKey(), entry.getValue());
>  
> Implementation Note:
> The default implementation assumes that IllegalStateException thrown by getKey() or getValue() indicates that the entry no longer exists. Operation continues for subsequent entries.
> 
> But these are contradictory!

I intentionally omitted the exception handling from the pseudo code to make it more readable. Barring entries being removed, the pseudo-code is accurately describes what happens. This is true for both the ConcurrentMap and Map implementations.

I'd prefer to change pseudo-code, if that's what's wanted, than the implementations.

>  Furthermore, given that any Map might end up giving us ISE, shouldn't we be using the ConcurrentMap implementation in Map (and specifying the ISE-skipping behavior?)  Whether or not to skip ISE should not be an Implementation Note, I think - it should be "spec".

Skipping removed entries makes sense for ConcurrentMap. For the basic Map it's assumed that it's not concurrent and thus an ISE is actually a sign that a CME should be thrown (which is what it does)

Mike

From mandy.chung at oracle.com  Tue Dec 10 04:13:05 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 09 Dec 2013 20:13:05 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52A4C659.4020406@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
Message-ID: <52A694D1.7090808@oracle.com>


On 12/8/2013 11:19 AM, Peter Levart wrote:
>
> H Mandy,
>
> I created an issue for it nevertheless:
>
> https://bugs.openjdk.java.net/browse/JDK-8029781
>
> You're right, doPrivileged() is a more straight-forward approach than 
> 'sealed' variable. Since this might only be considered for inclusion 
> in JDK9 when lambdas are already a tried technology, how do you feel 
> about using them for platform code like logging?

I'm in favor of more platform code using lambda when appropriate. 
logging is a module separated from the base module in Jigsaw.   I don't 
see any issue with that while the only thing is that when we backport it 
to 8u, the backport would be different - not an issue either.

> As far as I know (just checked), lambda meta-factory is not using any 
> j.u.logging, so there is no danger of initialization loops or similar:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03

I only skim with the change.  I will review it tomorrow.

Mandy


From martinrb at google.com  Tue Dec 10 04:14:52 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Dec 2013 20:14:52 -0800
Subject: Map.forEach
In-Reply-To: <75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
Message-ID: 

On Mon, Dec 9, 2013 at 7:49 PM, Mike Duigou  wrote:

>
> On Dec 9 2013, at 17:50 , Martin Buchholz  wrote:
>
> Current ConcurrentMap.forEach
>
> http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/ConcurrentMap.html#replaceAll-java.util.function.BiFunction-
> has two different "specs" for the default method:
>
> *Implementation Requirements:* The default implementation is equivalent
> to, for this map:
>
>
>  for (Map.Entry entry : map.entrySet())
>    action.accept(entry.getKey(), entry.getValue());
>
>
> *Implementation Note:* The default implementation assumes that
> IllegalStateException thrown by getKey() or getValue() indicates that the
> entry no longer exists. Operation continues for subsequent entries.
> But these are contradictory!
>
>
> I intentionally omitted the exception handling from the pseudo code to
> make it more readable. Barring entries being removed, the pseudo-code is
> accurately describes what happens. This is true for both the ConcurrentMap
> and Map implementations.
>
> I'd prefer to change pseudo-code, if that's what's wanted, than the
> implementations.
>
>  Furthermore, given that any Map might end up giving us ISE, shouldn't we
> be using the ConcurrentMap implementation in Map (and specifying the
> ISE-skipping behavior?)  Whether or not to skip ISE should not be an
> Implementation Note, I think - it should be "spec".
>
>
> Skipping removed entries makes sense for ConcurrentMap. For the basic Map
> it's assumed that it's not concurrent and thus an ISE is actually a sign
> that a CME should be thrown (which is what it does)
>

 Hmmm... it was time that I studied Map.forEach....  I see you convert to
ISE to CME ...

(Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
that a bug?)

Imagine a third party implementation of a synchronized map (again, like
Hashtable).  Its existing methods are synchronized, but in jdk8 it inherits
Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does not
implement ConcurrentMap) and so might throw CME even though its
implementation may never throw this and its entrySet may be designed for
concurrent traversal.

Another argument - before jdk8, whether a Map also implemented
ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
could add "implements ConcurrentMap" purely for its documentation value.
 Where possible, we should try to preserve that property.

Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
appears to implement all of its methods in a thread-safe way.


From zhangshj at linux.vnet.ibm.com  Tue Dec 10 07:15:30 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Tue, 10 Dec 2013 15:15:30 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A5B1B0.6090707@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com>
	<52A57F47.8070503@gmail.com> <52A581EF.3020700@gmail.com>
	<52A5927E.9020200@linux.vnet.ibm.com> <52A5B1B0.6090707@gmail.com>
Message-ID: <52A6BF92.4090208@linux.vnet.ibm.com>

On 12/9/2013 8:04 PM, Peter Levart wrote:
> On 12/09/2013 10:50 AM, Shi Jun Zhang wrote:
>> On 12/9/2013 4:40 PM, Peter Levart wrote:
>>> On 12/09/2013 09:28 AM, Peter Levart wrote:
>>>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>>>> Peter,
>>>>>
>>>>> I think you are misunderstanding this problem. This deadlock is 
>>>>> not related to the formatter synchronization, we can make 
>>>>> CustomerFormatter.format not synchronized and not call 
>>>>> super.format, the deadlock still happens.
>>>>
>>>> I'm not saying that your formatters are explicitly synchronized - 
>>>> all formatters are currently effectively synchronized by 
>>>> LogHandlers. The Formatter is invoked from within LogHandler's 
>>>> publish() method which is synchronized (on LogHandler.this). If 
>>>> formatters were invoked out of this synchronized section, there 
>>>> would be no danger of deadlocks when using Logger.log from within 
>>>> custom formatters. But then other issues would arise as a 
>>>> consequence of non-multithreaded formatters being invoked 
>>>> concurrently...
>>>>
>>>> Regards, Peter
>>>>
>>>
>>> I think the best solution to your problem (or a work-around if you 
>>> say so) was suggested by Jason Mehrens few messages ago - decoupling 
>>> of user code from publishing of log records - by creating an 
>>> AsyncLogHandler that is just feeding a FIFO queue with log records 
>>> which are processed by a background thread by pop-ing them out of 
>>> queue and sticking them in the actual LogHandler.publish(). If the 
>>> queue is unbouded or large enough so that it never fills up, there's 
>>> no danger of dead-locks even if you invoke Logger.log from custom 
>>> formatters in such background publishing thread.
>>>
>>> Regards, Peter
>>>
>> Hi Peter,
>>
>> Would the following situation happen if we use AsyncLogHandler? Some 
>> error happens and it causes the jvm crashes or System.exit() is 
>> called, however the related log record which contains important 
>> message is still in the queue and not printed. If so, I think it's 
>> unacceptable.
>>
>
> You could install a shutdown-hook that would make sure the remaining 
> queue is flushed before completing the VM exit...
>
> Regards, Peter
>
But shutdown hook will not be executed if VM crashes or exit abnormally.

-- 
Regards,

Shi Jun Zhang



From zhangshj at linux.vnet.ibm.com  Tue Dec 10 07:34:30 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Tue, 10 Dec 2013 15:34:30 +0800
Subject: Deadlock between FileHandler and ConsoleHandler when using
	customized formatter
In-Reply-To: <52A5CD43.40105@gmail.com>
References: <5296F688.1050806@linux.vnet.ibm.com>,
	<52973374.4010004@gmail.com> <52977B91.6030903@oracle.com>,
	<529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com>,
	<5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com>,
	<5298B919.6000909@oracle.com> <5298BB49.9040506@oracle.com>,
	<52A02315.3000605@linux.vnet.ibm.com>, <52A0434F.5040307@gmail.com>
	
	<52A56AF9.7050801@linux.vnet.ibm.com> <52A57F47.8070503@gmail.com>
	<52A584A5.4080208@linux.vnet.ibm.com>
	<52A5862A.5040306@gmail.com> <52A5978B.2050604@oracle.com>
	<52A5CD43.40105@gmail.com>
Message-ID: <52A6C406.7020405@linux.vnet.ibm.com>

On 12/9/2013 10:01 PM, Peter Levart wrote:
> On 12/09/2013 11:12 AM, Daniel Fuchs wrote:
>> On 12/9/13 9:58 AM, Peter Levart wrote:
>>> On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
>>>> On 12/9/2013 4:28 PM, Peter Levart wrote:
>>>>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>>>>> Peter,
>>>>>>
>>>>>> I think you are misunderstanding this problem. This deadlock is not
>>>>>> related to the formatter synchronization, we can make
>>>>>> CustomerFormatter.format not synchronized and not call super.format,
>>>>>> the deadlock still happens.
>>>>>
>>>>> I'm not saying that your formatters are explicitly synchronized - all
>>>>> formatters are currently effectively synchronized by LogHandlers. The
>>>>> Formatter is invoked from within LogHandler's publish() method which
>>>>> is synchronized (on LogHandler.this). If formatters were invoked out
>>>>> of this synchronized section, there would be no danger of deadlocks
>>>>> when using Logger.log from within custom formatters. But then other
>>>>> issues would arise as a consequence of non-multithreaded formatters
>>>>> being invoked concurrently...
>>>>>
>>>>> Regards, Peter
>>>>>
>>>> Hi Peter,
>>>>
>>>> We have thought about moving formatter out of the synchronized section
>>>> of Handler.publish(), it can avoid the deadlock. However, we can
>>>> reproduce the similar deadlock by extending the Writer in Handler and
>>>> using logger in the customized Writer.
>>>>
>>>
>>> That's right. And the remedy for that situation would also be what 
>>> Jason
>>> Mehrens suggested - asynchronous publishing.
>>
>> Hi,
>>
>> I agree with Peter & Jason - asynchronous publishing seems like a good
>> solution. I believe the LogManager will close all handlers on exiting,
>> so you might want to make sure that your asynchronous handler flushes
>> the queue before quitting - which could still be tricky if flushing
>> the queue produces new log messages for the queue - and also because
>> you will want Handler.close() to wait until the queue is empty.
>
> You're right, Daniel. There already is a global shut-down hook 
> installed in LogManager that close()s all
> active handlers when VM is shutting down.
>
> Shi Jun Zhang, here's a quick mock-up of a prototype AsyncHandler that 
> might work for you:
>
> http://cr.openjdk.java.net/~plevart/misc/jul.AsyncHandler/AsyncHandler.java 
>
>
> Regards, Peter
>

Thanks Peter for your prototype. I would like to see this AsyncHandler 
to be added into Java 8 or 9. However we will not use this in our stable 
product as we already have several other low risk workarounds.
>>
>> Anyway - the best advice still is IMHO - don't call Logger.log while
>> publishing a log message. This should save you from a lot of issues,
>> like the one you encountered - but also possible stack overflows etc...
>>
Yes, I totally agree this, so I suggest documenting this and let other 
Java developers not face this problem again.

>> best regards,
>>
>> -- daniel
>>
>>
>>>
>>> Regards, Peter
>>
>


-- 
Regards,

Shi Jun Zhang



From Alan.Bateman at oracle.com  Tue Dec 10 08:34:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 08:34:37 +0000
Subject: MappedFile call sync occur Cannot allocate memory
In-Reply-To: 
References: 
Message-ID: <52A6D21D.6080304@oracle.com>

On 10/12/2013 00:05, fuyou wrote:
> I write a MappedFile ,and a task call sync write to disk.
> but occur :
>
> java.io.IOException: Cannot allocate memory
>       at java.nio.MappedByteBuffer.force0(Native Method)
>       at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:154)
>
> the os is Red Hat Enterprise Linux Server release 5.4
> java is java version "1.6.0_23"
It means that the underlying msync has failed but it's not clear why. I 
suspect you'll need to poke around on the system to see if this is 
resource related.

-Alan.


From Alan.Bateman at oracle.com  Tue Dec 10 08:48:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 08:48:47 +0000
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52A694D1.7090808@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52A694D1.7090808@oracle.com>
Message-ID: <52A6D56F.9050602@oracle.com>

On 10/12/2013 04:13, Mandy Chung wrote:
>
> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>
>> :
>>
>> You're right, doPrivileged() is a more straight-forward approach than 
>> 'sealed' variable. Since this might only be considered for inclusion 
>> in JDK9 when lambdas are already a tried technology, how do you feel 
>> about using them for platform code like logging?
>
> I'm in favor of more platform code using lambda when appropriate. 
> logging is a module separated from the base module in Jigsaw.   I 
> don't see any issue with that while the only thing is that when we 
> backport it to 8u, the backport would be different - not an issue either.
I'm less sure on this about this (or rather just concerned there might 
be code paths that lead to recursive initialization issues when linking 
call sites). I see there are still cases where String.format is used 
when generating proxy classes and that will trigger the loading of 
locale-specific service providers. There is also exception handling in 
the proxy class dumping code that use the PlatformLogger. It might not 
be an issue with this specific patch as the compiler will (I think) 
generate the lambda method but just a general worry about anything that 
might run early in the startup.

-Alan.


From paul.sandoz at oracle.com  Tue Dec 10 09:06:26 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Dec 2013 10:06:26 +0100
Subject: Map.forEach
In-Reply-To: 
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
	
Message-ID: <928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>

On Dec 10, 2013, at 5:14 AM, Martin Buchholz  wrote:
> 
> Hmmm... it was time that I studied Map.forEach....  I see you convert to
> ISE to CME ...
> 
> (Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
> that a bug?)
> 
> Imagine a third party implementation of a synchronized map (again, like
> Hashtable).  Its existing methods are synchronized, but in jdk8 it inherits
> Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does not
> implement ConcurrentMap) and so might throw CME even though its
> implementation may never throw this and its entrySet may be designed for
> concurrent traversal.
> 

Are you assuming the iterators of the collection views of the third party implementation would be weakly consistent? if so would expect that implementation to implement ConcurrentMap.


> Another argument - before jdk8, whether a Map also implemented
> ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
> could add "implements ConcurrentMap" purely for its documentation value.
> Where possible, we should try to preserve that property.
> 
> Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
> appears to implement all of its methods in a thread-safe way.

Not sure Hashtable should implement ConcurrentMap. 

While the Hashtable methods are synchronized the collection views will fail fast on modification (one of the few cases where CME is explicitly used with concurrent access in mind :-) ). Although it is not explicitly called out I think the likely expectation is (well, my expectation is) that a ConcurrentMap provides weakly consistent iterators.
 
Paul.

From Alan.Bateman at oracle.com  Tue Dec 10 09:10:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 09:10:15 +0000
Subject: RFR: JDK-8022219,
	Intermittent test failures in java/util/zip/ZipFile
In-Reply-To: <52A4AC90.1020102@oracle.com>
References: <52A4AC90.1020102@oracle.com>
Message-ID: <52A6DA77.10605@oracle.com>

On 08/12/2013 17:29, Dan Xu wrote:
> Hi All,
>
> Please review the fix towards the intermittent test failure in 
> java/util/zip/ZipFile. It is a similar failure that I encountered 
> before, due to the interferences from other software or daemon 
> services in Windows platforms. The fix is to use the method from 
> FileUtils test library to handle the problem at its best effort. Thanks!
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8022219
> Webrev: http://cr.openjdk.java.net/~dxu/8022219/webrev/ 
> 
>
> -Dan
This looks okay to me although I think you should be able to use 
"/lib/testlibrary" as the @library value (assuming your jtreg is 
somewhat recent).

-Alan.


From chris.hegarty at oracle.com  Tue Dec 10 11:04:36 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Dec 2013 11:04:36 +0000
Subject: RFR: JDK-8022219,
	Intermittent test failures in java/util/zip/ZipFile
In-Reply-To: <52A6DA77.10605@oracle.com>
References: <52A4AC90.1020102@oracle.com> <52A6DA77.10605@oracle.com>
Message-ID: <76309B7F-4E97-49AA-B694-25CA4EBEE5F6@oracle.com>


On 10 Dec 2013, at 09:10, Alan Bateman  wrote:

> On 08/12/2013 17:29, Dan Xu wrote:
>> Hi All,
>> 
>> Please review the fix towards the intermittent test failure in java/util/zip/ZipFile. It is a similar failure that I encountered before, due to the interferences from other software or daemon services in Windows platforms. The fix is to use the method from FileUtils test library to handle the problem at its best effort. Thanks!
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8022219
>> Webrev: http://cr.openjdk.java.net/~dxu/8022219/webrev/ 
>> 
>> -Dan
> This looks okay to me although I think you should be able to use "/lib/testlibrary" as the @library value (assuming your jtreg is somewhat recent).

+1. 

-Chris.

> 
> -Alan.



From Alan.Bateman at oracle.com  Tue Dec 10 11:06:48 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 11:06:48 +0000
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
Message-ID: <52A6F5C8.6000400@oracle.com>


(This one is for the jdk9-dev forest once it is created)

The addPropertyChangeListener and removePropertyChangeListener methods 
defined by Pack200.{Packer,Unpacker} and LogManager methods are 
deprecated and flagged with a warning that they "will be removed in a 
future release". This is highlighted in the EDR and Public Review of JSR 
337 and also flagged in JEP 162.

I'd like to swing the axe early in JDK 9 so as to give every opportunity 
for anything that might have a dependency. There are a few other 
modularity related changes that need to go in early too but this is the 
only one that involves the removal of methods.

The webrev with the changes is here:

http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/

I've cc'ed build-dev as there are make file changes to remove the 
de-beaning rules (these methods do not exist in subset Profiles of Java 
SE and were removed as part of the build).

-Alan.


From daniel.fuchs at oracle.com  Tue Dec 10 11:30:20 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Dec 2013 12:30:20 +0100
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
In-Reply-To: <52A6F5C8.6000400@oracle.com>
References: <52A6F5C8.6000400@oracle.com>
Message-ID: <52A6FB4C.7080807@oracle.com>

On 12/10/13 12:06 PM, Alan Bateman wrote:
>
> (This one is for the jdk9-dev forest once it is created)
>
> The addPropertyChangeListener and removePropertyChangeListener methods
> defined by Pack200.{Packer,Unpacker} and LogManager methods are
> deprecated and flagged with a warning that they "will be removed in a
> future release". This is highlighted in the EDR and Public Review of JSR
> 337 and also flagged in JEP 162.
>
> I'd like to swing the axe early in JDK 9 so as to give every opportunity
> for anything that might have a dependency. There are a few other
> modularity related changes that need to go in early too but this is the
> only one that involves the removal of methods.
>
> The webrev with the changes is here:
>
> http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/

Hi Alan

I had a look at the j.u.l part of the fix - test included, and that
looks fine. I am glad to see these go :-)

I applaud at doing this early in JDK 9 - hopefully we will get feedback
early if some kind of replacement appears to be needed.

>
> I've cc'ed build-dev as there are make file changes to remove the
> de-beaning rules (these methods do not exist in subset Profiles of Java
> SE and were removed as part of the build).

Wahou. Debeaning - I didn't know about that :-) - don't count me as
reviewer for these :-)

-- daniel

>
> -Alan.



From Alan.Bateman at oracle.com  Tue Dec 10 13:51:54 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 13:51:54 +0000
Subject: 8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
Message-ID: <52A71C7A.4050404@oracle.com>


In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
checkTopLevelWindow, checkSystemClipboard and 
checkAccessAwtEventQueueAccess with a warning that they would be changed 
in a future release to check AllPermission. At the same time we changed 
the java.awt.Window and Toolkit methods to use checkPermission directly 
so that the legacy methods aren't used. The motive for all this is 
modules of course and the strong desire to remove the dependency on 
java.awt.AWTPermission.

I'd like to get the second phase of this work into JDK 9 early to give 
every opportunity to find any potential issues. The second phase of this 
work changes the SecurityManager methods to check AllPermission and 
updates the implementation to remove the reflection hackery that was 
used to allow this code work without AWT being present (something that 
was needed for the profiles build).

The webrev with the changes is here:
   http://cr.openjdk.java.net/~alanb/8029886/webrev/

The main thing that I'd like to get agreement on is the wording for the 
updated methods and also agreement from the AWT group to move the 
permission constants to a new class sun.awt.AWTPermissions.

-Alan.


From tim.bell at oracle.com  Tue Dec 10 16:14:33 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 10 Dec 2013 08:14:33 -0800
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
In-Reply-To: <52A6F5C8.6000400@oracle.com>
References: <52A6F5C8.6000400@oracle.com>
Message-ID: <52A73DE9.3090803@oracle.com>

Hi Alan:

>
> (This one is for the jdk9-dev forest once it is created)
>
> The addPropertyChangeListener and removePropertyChangeListener methods 
> defined by Pack200.{Packer,Unpacker} and LogManager methods are 
> deprecated and flagged with a warning that they "will be removed in a 
> future release". This is highlighted in the EDR and Public Review of 
> JSR 337 and also flagged in JEP 162.
>
> I'd like to swing the axe early in JDK 9 so as to give every 
> opportunity for anything that might have a dependency. There are a few 
> other modularity related changes that need to go in early too but this 
> is the only one that involves the removal of methods.
>
> The webrev with the changes is here:
>
> http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/
>
> I've cc'ed build-dev as there are make file changes to remove the 
> de-beaning rules (these methods do not exist in subset Profiles of 
> Java SE and were removed as part of the build).

The code deletions in the make files look good.


Tim



From mike.duigou at oracle.com  Tue Dec 10 16:43:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Dec 2013 08:43:24 -0800
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: 
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
Message-ID: <82F22121-4AEE-475D-ABE5-EDA90C913D20@oracle.com>

I considered it but was worried that the combined size would prevent inlining of the method. The getOrDefault method is currently 33 bytes long which is right at the common borderline for inlining. It does seem a shame to duplicate the code but I couldn't be confident I wouldn't degrade performance by reuse. 

(If someone were to write a JMH benchmark to show that get() calling getOrDefault() was no slower than the naive duplication then it would be reasonable to consider switching).

Mike

On Dec 9 2013, at 23:22 , Vitaly Davidovich  wrote:

> Mike,
> 
> Would it make sense to rewrite get() in terms of getOrDefault() to reduce duplication?
> 
> Thanks
> 
> Sent from my phone
> 
> On Dec 9, 2013 10:40 PM, "Mike Duigou"  wrote:
> Hello all;
> 
> I've posted a webrev for review which corrects the problem and adds appropriate tests.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8029795/0/webrev/
> 
> I also updated the documentation to mention that getOrDefault as well as the replace methods generate access events.
> 
> Mike
> 
> On Dec 9 2013, at 02:11 , Paul Sandoz  wrote:
> 
> > Hi Roman,
> >
> > On Dec 8, 2013, at 10:29 PM, Roman Leventov  wrote:
> >> Especially getDefault(). Doesn't this violate principle of least astonishment? Details and proof: http://stackoverflow.com/questions/20440136/why-doesnt-new-map-methods-generate-entry-accesses-on-linkedhashmap
> >>
> >
> > Thanks. I believe that all the new (default) Map methods but getOrDefault behave correctly. So i think it is a bug, we need to add something like the following to LinkedHashMap:
> >
> >    public V getOrDefault(Object key, V defaultValue) {
> >        Node e;
> >        if ((e = getNode(hash(key), key)) == null)
> >            return defaultValue;
> >        if (accessOrder)
> >            afterNodeAccess(e);
> >        return e.value;
> >    }
> >
> > and also update the documentation to clarify (via the implementation specification of the default methods it can be inferred what the behaviour is, but that ain't obvious).
> >
> > I have logged this bug:
> >
> >  https://bugs.openjdk.java.net/browse/JDK-8029795
> >
> > Paul.
> >
> >
> >
> 



From mike.duigou at oracle.com  Tue Dec 10 16:51:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Dec 2013 08:51:15 -0800
Subject: Map.forEach
In-Reply-To: <928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
	
	<928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
Message-ID: <77224B73-6BB1-4BE2-84D3-45CDD4498B42@oracle.com>


On Dec 10 2013, at 01:06 , Paul Sandoz  wrote:

> On Dec 10, 2013, at 5:14 AM, Martin Buchholz  wrote:
>> 
>> Hmmm... it was time that I studied Map.forEach....  I see you convert to
>> ISE to CME ...
>> 
>> (Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
>> that a bug?)
>> 
>> Imagine a third party implementation of a synchronized map (again, like
>> Hashtable).  Its existing methods are synchronized, but in jdk8 it inherits
>> Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does not
>> implement ConcurrentMap) and so might throw CME even though its
>> implementation may never throw this and its entrySet may be designed for
>> concurrent traversal.
>> 
> 
> Are you assuming the iterators of the collection views of the third party implementation would be weakly consistent? if so would expect that implementation to implement ConcurrentMap.

This observation suggests that we should describe this characteristic in the ConcurrentMap specification.

> 
> 
>> Another argument - before jdk8, whether a Map also implemented
>> ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
>> could add "implements ConcurrentMap" purely for its documentation value.
>> Where possible, we should try to preserve that property.
>> 
>> Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
>> appears to implement all of its methods in a thread-safe way.
> 
> Not sure Hashtable should implement ConcurrentMap. 
> 
> While the Hashtable methods are synchronized the collection views will fail fast on modification (one of the few cases where CME is explicitly used with concurrent access in mind :-) ). Although it is not explicitly called out I think the likely expectation is (well, my expectation is) that a ConcurrentMap provides weakly consistent iterators.

I agree that the iterator behaviour for Hashtable (and of Collections.synchronizedMap) falls short of what one would expect of a ConcurrentHashMap.

Mike

From dan.xu at oracle.com  Tue Dec 10 16:58:42 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 10 Dec 2013 08:58:42 -0800
Subject: RFR: JDK-8022219,
	Intermittent test failures in java/util/zip/ZipFile
In-Reply-To: <76309B7F-4E97-49AA-B694-25CA4EBEE5F6@oracle.com>
References: <52A4AC90.1020102@oracle.com> <52A6DA77.10605@oracle.com>
	<76309B7F-4E97-49AA-B694-25CA4EBEE5F6@oracle.com>
Message-ID: <52A74842.4020802@oracle.com>

Hi Alan and Chris,

Thanks for your review. Unfortunately, my jtreg is still an old version. 
And when I tried to use /lib/testlibrary, my jprt job also failed.

-Dan


On 12/10/2013 03:04 AM, Chris Hegarty wrote:
> On 10 Dec 2013, at 09:10, Alan Bateman  wrote:
>
>> On 08/12/2013 17:29, Dan Xu wrote:
>>> Hi All,
>>>
>>> Please review the fix towards the intermittent test failure in java/util/zip/ZipFile. It is a similar failure that I encountered before, due to the interferences from other software or daemon services in Windows platforms. The fix is to use the method from FileUtils test library to handle the problem at its best effort. Thanks!
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8022219
>>> Webrev: http://cr.openjdk.java.net/~dxu/8022219/webrev/ 
>>>
>>> -Dan
>> This looks okay to me although I think you should be able to use "/lib/testlibrary" as the @library value (assuming your jtreg is somewhat recent).
> +1.
>
> -Chris.
>
>> -Alan.



From mandy.chung at oracle.com  Tue Dec 10 17:31:19 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Dec 2013 09:31:19 -0800
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
In-Reply-To: <52A6F5C8.6000400@oracle.com>
References: <52A6F5C8.6000400@oracle.com>
Message-ID: <52A74FE7.3010909@oracle.com>

Looks good.  Happy to see these methods finally removed for a clean jdk 
modularization!

Mandy

On 12/10/2013 3:06 AM, Alan Bateman wrote:
>
> (This one is for the jdk9-dev forest once it is created)
>
> The addPropertyChangeListener and removePropertyChangeListener methods 
> defined by Pack200.{Packer,Unpacker} and LogManager methods are 
> deprecated and flagged with a warning that they "will be removed in a 
> future release". This is highlighted in the EDR and Public Review of 
> JSR 337 and also flagged in JEP 162.
>
> I'd like to swing the axe early in JDK 9 so as to give every 
> opportunity for anything that might have a dependency. There are a few 
> other modularity related changes that need to go in early too but this 
> is the only one that involves the removal of methods.
>
> The webrev with the changes is here:
>
> http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/
>
> I've cc'ed build-dev as there are make file changes to remove the 
> de-beaning rules (these methods do not exist in subset Profiles of 
> Java SE and were removed as part of the build).
>
> -Alan.



From mandy.chung at oracle.com  Tue Dec 10 17:49:31 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Dec 2013 09:49:31 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52A6D56F.9050602@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52A694D1.7090808@oracle.com> <52A6D56F.9050602@oracle.com>
Message-ID: <52A7542B.3080302@oracle.com>


On 12/10/2013 12:48 AM, Alan Bateman wrote:
> On 10/12/2013 04:13, Mandy Chung wrote:
>>
>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>
>>> :
>>>
>>> You're right, doPrivileged() is a more straight-forward approach 
>>> than 'sealed' variable. Since this might only be considered for 
>>> inclusion in JDK9 when lambdas are already a tried technology, how 
>>> do you feel about using them for platform code like logging?
>>
>> I'm in favor of more platform code using lambda when appropriate. 
>> logging is a module separated from the base module in Jigsaw.   I 
>> don't see any issue with that while the only thing is that when we 
>> backport it to 8u, the backport would be different - not an issue 
>> either.
> I'm less sure on this about this (or rather just concerned there might 
> be code paths that lead to recursive initialization issues when 
> linking call sites). I see there are still cases where String.format 
> is used when generating proxy classes and that will trigger the 
> loading of locale-specific service providers. There is also exception 
> handling in the proxy class dumping code that use the PlatformLogger. 
> It might not be an issue with this specific patch as the compiler will 
> (I think) generate the lambda method but just a general worry about 
> anything that might run early in the startup.

It is a good point.  I will have to review the patch in details.  In 
general, I think j.u.logging should only be run after startup which was 
fixed in jdk 7 while we should check if any change went in that since 
then.  Also PlatformLogger might need to be changed and only begin 
forwarding to j.u.logging after startup (need to think about that further).

Mandy



From martinrb at google.com  Tue Dec 10 18:15:34 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Dec 2013 10:15:34 -0800
Subject: Map.forEach
In-Reply-To: <928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
	
	<928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
Message-ID: 

Perhaps Doug could provide history on the intent of ConcurrentMap.  But
regardless of that, if I actually READ the (jdk7) spec, it pretty much just
says,

A Map  providing
additional atomic putIfAbsent, remove, and replace methods.

i.e. all it provides is atomic read-modify-write access to individual
entries in the map.  ConcurrentMap (in jdk7) is silent on operations that
access more than one entry - nothing about weak consistency or CME.
 Hashtable fits perfectly.

Which further suggests that default methods on Map and ConcurrentMap that
access multiple entries (like forEach) should behave identically.


On Tue, Dec 10, 2013 at 1:06 AM, Paul Sandoz  wrote:

> On Dec 10, 2013, at 5:14 AM, Martin Buchholz  wrote:
> >
> > Hmmm... it was time that I studied Map.forEach....  I see you convert to
> > ISE to CME ...
> >
> > (Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
> > that a bug?)
> >
> > Imagine a third party implementation of a synchronized map (again, like
> > Hashtable).  Its existing methods are synchronized, but in jdk8 it
> inherits
> > Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does
> not
> > implement ConcurrentMap) and so might throw CME even though its
> > implementation may never throw this and its entrySet may be designed for
> > concurrent traversal.
> >
>
> Are you assuming the iterators of the collection views of the third party
> implementation would be weakly consistent? if so would expect that
> implementation to implement ConcurrentMap.
>
>
> > Another argument - before jdk8, whether a Map also implemented
> > ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
> > could add "implements ConcurrentMap" purely for its documentation value.
> > Where possible, we should try to preserve that property.
> >
> > Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
> > appears to implement all of its methods in a thread-safe way.
>
> Not sure Hashtable should implement ConcurrentMap.
>
> While the Hashtable methods are synchronized the collection views will
> fail fast on modification (one of the few cases where CME is explicitly
> used with concurrent access in mind :-) ). Although it is not explicitly
> called out I think the likely expectation is (well, my expectation is) that
> a ConcurrentMap provides weakly consistent iterators.
>
> Paul.
>


From mandy.chung at oracle.com  Tue Dec 10 18:37:35 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Dec 2013 10:37:35 -0800
Subject: 8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A75F6F.7020800@oracle.com>

Alan,

The change looks good.   A minor one - in the class description of 
java.lang.SecurityManager,  I suggest to remove the references to 
java.awt.AWTPermission line 143 and 214.

Mandy

On 12/10/2013 5:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
> checkTopLevelWindow, checkSystemClipboard and 
> checkAccessAwtEventQueueAccess with a warning that they would be 
> changed in a future release to check AllPermission. At the same time 
> we changed the java.awt.Window and Toolkit methods to use 
> checkPermission directly so that the legacy methods aren't used. The 
> motive for all this is modules of course and the strong desire to 
> remove the dependency on java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give 
> every opportunity to find any potential issues. The second phase of 
> this work changes the SecurityManager methods to check AllPermission 
> and updates the implementation to remove the reflection hackery that 
> was used to allow this code work without AWT being present (something 
> that was needed for the profiles build).
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for 
> the updated methods and also agreement from the AWT group to move the 
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.



From martinrb at google.com  Tue Dec 10 18:59:30 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Dec 2013 10:59:30 -0800
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses on
	LinkedHashMap?)
In-Reply-To: <82F22121-4AEE-475D-ABE5-EDA90C913D20@oracle.com>
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	<82F22121-4AEE-475D-ABE5-EDA90C913D20@oracle.com>
Message-ID: 

In java.util, we're willing to take maintainability hits for the sake of
performance.  OTOH, this is the part of the JDK most likely to be studied
by students everywhere, so exemplary code is also highly desirable.


On Tue, Dec 10, 2013 at 8:43 AM, Mike Duigou  wrote:

> I considered it but was worried that the combined size would prevent
> inlining of the method. The getOrDefault method is currently 33 bytes long
> which is right at the common borderline for inlining. It does seem a shame
> to duplicate the code but I couldn't be confident I wouldn't degrade
> performance by reuse.
>
> (If someone were to write a JMH benchmark to show that get() calling
> getOrDefault() was no slower than the naive duplication then it would be
> reasonable to consider switching).
>
> Mike
>
> On Dec 9 2013, at 23:22 , Vitaly Davidovich  wrote:
>
> > Mike,
> >
> > Would it make sense to rewrite get() in terms of getOrDefault() to
> reduce duplication?
> >
> > Thanks
> >
> > Sent from my phone
> >
> > On Dec 9, 2013 10:40 PM, "Mike Duigou"  wrote:
> > Hello all;
> >
> > I've posted a webrev for review which corrects the problem and adds
> appropriate tests.
> >
> > http://cr.openjdk.java.net/~mduigou/JDK-8029795/0/webrev/
> >
> > I also updated the documentation to mention that getOrDefault as well as
> the replace methods generate access events.
> >
> > Mike
> >
> > On Dec 9 2013, at 02:11 , Paul Sandoz  wrote:
> >
> > > Hi Roman,
> > >
> > > On Dec 8, 2013, at 10:29 PM, Roman Leventov  wrote:
> > >> Especially getDefault(). Doesn't this violate principle of least
> astonishment? Details and proof:
> http://stackoverflow.com/questions/20440136/why-doesnt-new-map-methods-generate-entry-accesses-on-linkedhashmap
> > >>
> > >
> > > Thanks. I believe that all the new (default) Map methods but
> getOrDefault behave correctly. So i think it is a bug, we need to add
> something like the following to LinkedHashMap:
> > >
> > >    public V getOrDefault(Object key, V defaultValue) {
> > >        Node e;
> > >        if ((e = getNode(hash(key), key)) == null)
> > >            return defaultValue;
> > >        if (accessOrder)
> > >            afterNodeAccess(e);
> > >        return e.value;
> > >    }
> > >
> > > and also update the documentation to clarify (via the implementation
> specification of the default methods it can be inferred what the behaviour
> is, but that ain't obvious).
> > >
> > > I have logged this bug:
> > >
> > >  https://bugs.openjdk.java.net/browse/JDK-8029795
> > >
> > > Paul.
> > >
> > >
> > >
> >
>
>


From philip.race at oracle.com  Tue Dec 10 19:20:51 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 10 Dec 2013 11:20:51 -0800
Subject:  8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A76993.3060905@oracle.com>

 > was trusted to bring up a top-level winodw. It no longer has a use

What's a winodw ? :-)

"It no longer has a use" suggests it does nothing so might be better 
phrased as
"no longer the recommended or sole way to perform this check and is 
superseded by .. "


Is there a CCC for this ? It seems that there's a compatibility impact
on permissions required if you don't/can't change your code, and on your
code if you want to keep the same permissions.

-phil.

On 12/10/2013 5:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
> checkTopLevelWindow, checkSystemClipboard and 
> checkAccessAwtEventQueueAccess with a warning that they would be 
> changed in a future release to check AllPermission. At the same time 
> we changed the java.awt.Window and Toolkit methods to use 
> checkPermission directly so that the legacy methods aren't used. The 
> motive for all this is modules of course and the strong desire to 
> remove the dependency on java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give 
> every opportunity to find any potential issues. The second phase of 
> this work changes the SecurityManager methods to check AllPermission 
> and updates the implementation to remove the reflection hackery that 
> was used to allow this code work without AWT being present (something 
> that was needed for the profiles build).
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for 
> the updated methods and also agreement from the AWT group to move the 
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.



From dl at cs.oswego.edu  Tue Dec 10 19:25:46 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 10 Dec 2013 14:25:46 -0500
Subject: Map.forEach
In-Reply-To: 
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
	
	<928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
	
Message-ID: <52A76ABA.7090006@cs.oswego.edu>

On 12/10/2013 01:15 PM, Martin Buchholz wrote:
> Perhaps Doug could provide history on the intent of ConcurrentMap.

See the package-level docs in java.util.concurrent that compare
Hashtable to ConcurrentMap, implying that it might not be a good idea
to now retrospectively declare Hashtable as a ConcurrentMap even though,
through the magic of defaults, they share methods.

Pasting...


The "Concurrent" prefix used with some classes in this package is a shorthand 
indicating several differences from similar "synchronized" classes. For example 
java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are 
synchronized. But ConcurrentHashMap is "concurrent". A concurrent collection is 
thread-safe, but not governed by a single exclusion lock. In the particular case 
of ConcurrentHashMap, it safely permits any number of concurrent reads as well 
as a tunable number of concurrent writes. "Synchronized" classes can be useful 
when you need to prevent all access to a collection via a single lock, at the 
expense of poorer scalability. In other cases in which multiple threads are 
expected to access a common collection, "concurrent" versions are normally 
preferable. And unsynchronized collections are preferable when either 
collections are unshared, or are accessible only when holding other locks.

Most concurrent Collection implementations (including most Queues) also differ 
from the usual java.util conventions in that their Iterators and Spliterators 
provide weakly consistent rather than fast-fail traversal:

     they may proceed concurrently with other operations
     they will never throw ConcurrentModificationException
     they are guaranteed to traverse elements as they existed upon construction 
exactly once, and may (but are not guaranteed to) reflect any modifications 
subsequent to construction.


From vitalyd at gmail.com  Tue Dec 10 19:57:56 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 10 Dec 2013 14:57:56 -0500
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses on
	LinkedHashMap?)
In-Reply-To: 
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	<82F22121-4AEE-475D-ABE5-EDA90C913D20@oracle.com>
	
Message-ID: 

I believe C2 compiler is more aggressive about inlining, and will inline
hot methods over the 35 bytes limit.  I guess interpreter and C1 (and other
JVMs, potentially) may get impacted though.  In this case, the issue may be
more about the fact that getOrDefault() is virtual and not so much about
byte code size; devirtualization will need profiling info.  Also, the
inlining method (I.e. get()) would be tiny since it just calls getOrDefault
- if inlining is halted purely on byte code size, that almost smells of a
compiler bug/quality of implementation issue.

Having said that, it's really a shame that such a seemingly small (and
good, from maintenance standpoint) change risks performance degradation.

Sent from my phone
On Dec 10, 2013 10:44 AM, "Mike Duigou"  wrote:

I considered it but was worried that the combined size would prevent
inlining of the method. The getOrDefault method is currently 33 bytes long
which is right at the common borderline for inlining. It does seem a shame
to duplicate the code but I couldn't be confident I wouldn't degrade
performance by reuse.

(If someone were to write a JMH benchmark to show that get() calling
getOrDefault() was no slower than the naive duplication then it would be
reasonable to consider switching).

Mike


On Dec 9 2013, at 23:22 , Vitaly Davidovich  wrote:

Mike,

Would it make sense to rewrite get() in terms of getOrDefault() to reduce
duplication?

Thanks

Sent from my phone
On Dec 9, 2013 10:40 PM, "Mike Duigou"  wrote:

> Hello all;
>
> I've posted a webrev for review which corrects the problem and adds
> appropriate tests.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8029795/0/webrev/
>
> I also updated the documentation to mention that getOrDefault as well as
> the replace methods generate access events.
>
> Mike
>
> On Dec 9 2013, at 02:11 , Paul Sandoz  wrote:
>
> > Hi Roman,
> >
> > On Dec 8, 2013, at 10:29 PM, Roman Leventov  wrote:
> >> Especially getDefault(). Doesn't this violate principle of least
> astonishment? Details and proof:
> http://stackoverflow.com/questions/20440136/why-doesnt-new-map-methods-generate-entry-accesses-on-linkedhashmap
> >>
> >
> > Thanks. I believe that all the new (default) Map methods but
> getOrDefault behave correctly. So i think it is a bug, we need to add
> something like the following to LinkedHashMap:
> >
> >    public V getOrDefault(Object key, V defaultValue) {
> >        Node e;
> >        if ((e = getNode(hash(key), key)) == null)
> >            return defaultValue;
> >        if (accessOrder)
> >            afterNodeAccess(e);
> >        return e.value;
> >    }
> >
> > and also update the documentation to clarify (via the implementation
> specification of the default methods it can be inferred what the behaviour
> is, but that ain't obvious).
> >
> > I have logged this bug:
> >
> >  https://bugs.openjdk.java.net/browse/JDK-8029795
> >
> > Paul.
> >
> >
> >
>
>


From Alan.Bateman at oracle.com  Tue Dec 10 20:47:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 20:47:27 +0000
Subject:  8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A76993.3060905@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A76993.3060905@oracle.com>
Message-ID: <52A77DDF.1020109@oracle.com>

On 10/12/2013 19:20, Phil Race wrote:
> > was trusted to bring up a top-level winodw. It no longer has a use
>
> What's a winodw ? :-)
Thanks, I'll fix that.

>
> "It no longer has a use" suggests it does nothing so might be better 
> phrased as
> "no longer the recommended or sole way to perform this check and is 
> superseded by .. "
"It" refers to the method as it really doesn't have a use now (these 
methods haven't really been needed since JDK 1.1). However, I see how 
this could be mis-read so I will adjust the wording.

>
>
> Is there a CCC for this ? It seems that there's a compatibility impact
> on permissions required if you don't/can't change your code, and on your
> code if you want to keep the same permissions.
The permissions haven't changed and existing policy files will continue 
to work. Also remember we changed the AWT implementation in JDK 8 to use 
checkPermission directly so the 3 methods aren't used. It's possible 
that there is code somewhere are is invoking these legacy methods 
directly and that was the reason for deprecating it in 8 with the 
wording to make it clear that these methods would be change in the 
future. Also by getting this change done early in JDK 9 then it gives 
every opportunity to flush out issues.

-Alan.


From mike.duigou at oracle.com  Wed Dec 11 00:27:27 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Dec 2013 16:27:27 -0800
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: 
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	
Message-ID: <042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>

I have added tests and documentation for the other methods.

http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/

The documentation for some of the methods is ambiguous about how many access events are generated. For LRU cache is OK but other cases (counting based eviction) may care about the total number of accesses.

Mike

On Dec 10 2013, at 01:52 , Paul Sandoz  wrote:

> 
> On Dec 10, 2013, at 10:47 AM, Paul Sandoz  wrote:
> 
>> 
>> On Dec 10, 2013, at 5:37 AM, Mike Duigou  wrote:
>> 
>>> Hello all;
>>> 
>>> I've posted a webrev for review which corrects the problem and adds appropriate tests.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8029795/0/webrev/
>>> 
>>> I also updated the documentation to mention that getOrDefault as well as the replace methods generate access events. 
>>> 
>> 
>> Looking good. I don't have a strong opinion on sharing code for this method.
>> 
>> We should probably also test the other methods computeIfAbsent, computeIfPresent, compute and merge.
>> 
> 
> Drat hit send too soon... i meant to also add that since the above methods can access entries, see code in HashMap for calls to afterNodeAccess, they need to be mentioned in the docs in addition to being tested.
> 
> Paul.
> 



From mike.duigou at oracle.com  Wed Dec 11 01:05:21 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Dec 2013 17:05:21 -0800
Subject: RFR: 8029944: (xs) Primitive Stream reduce method documentation
	pseudo code misidentifies apply method
Message-ID: <8D95DF8A-4AC1-4E98-BF19-CBDCDE512249@oracle.com>

Hello all;

This is a documentation only fix for a bug reported by Michael McMahon. The reduce methods of the primitive streams classes currently reference an "apply" method rather than the appropriate applyAsInt, applyAsLong or applyAsDouble methods.

http://cr.openjdk.java.net/~mduigou/JDK-8029944/0/

Michael also suggested synchronizing the names accumulator and op but I declined (thus far) to make this change. If there is consensus that this would be helpful I can amend the changeset.

Mike

From joe.darcy at oracle.com  Wed Dec 11 01:23:33 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 10 Dec 2013 17:23:33 -0800
Subject: RFR: 8029944: (xs) Primitive Stream reduce method documentation
	pseudo code misidentifies apply method
In-Reply-To: <8D95DF8A-4AC1-4E98-BF19-CBDCDE512249@oracle.com>
References: <8D95DF8A-4AC1-4E98-BF19-CBDCDE512249@oracle.com>
Message-ID: <52A7BE95.1060308@oracle.com>


On 12/10/2013 5:05 PM, Mike Duigou wrote:
> Hello all;
>
> This is a documentation only fix for a bug reported by Michael McMahon. The reduce methods of the primitive streams classes currently reference an "apply" method rather than the appropriate applyAsInt, applyAsLong or applyAsDouble methods.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8029944/0/
>
>

Looks good; cheers,

-Joe



From tristan.yan at oracle.com  Wed Dec 11 02:10:22 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Wed, 11 Dec 2013 10:10:22 +0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <529FD0A9.9020400@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>
	<529FD0A9.9020400@oracle.com>
Message-ID: <52A7C98E.7000200@oracle.com>

/Hi everyone
I am working on bug JDK-7168267 
 .

Root Cause:
- Per Stuart's comment, this is a clean up bug.

Suggested Fix:
- Will use timeout to replace loop.
- Also I am fixing two test's performance
java/rmi/activation/Activatable/forceLogSnapshot - method waitAllStarted 
is using sleep to poll 50 restartedObject to be true, we can use modern 
CountDownLatch to implement blocking-time wait.
java/rmi/activation/Activatable/checkAnnotations - We can subclass 
ByteArrayOutputStream which support notification when data was written. 
Also use two thread wait output string and error string to be not null.

Please let me know if you have any comments or suggestions.
/ /
Thank you
Tristan

On 12/05/2013 09:02 AM, Stuart Marks wrote:
/
> /On 12/3/13 11:05 PM, Tristan Yan wrote:
> /
>> /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. 
>> This bug is
>> asking performance improvement for RMI test. Because this would involve
>> different RMI tests. I?d like to use this cr as an umbrella bug, 
>> create sub-cr
>> for different test. Then I can make progress on sub-cr. Please let me 
>> know your
>> opinion on this.
>> /
> /
> Actually JDK-7168267 is more about various test cleanups, and 
> JDK-8005436 is more about performance. Both bugs, though, make general 
> statements about "the RMI tests" and don't have much information about 
> specific actions that need to be taken. I've added some notes to 
> JDK-7168267 about some cleanups that could be done.
> / /
> If there are specific actions for either of these bugs, then yes, 
> creating Sub-Tasks of these bugs and fixing them individually is the 
> right thing to do.
> / /
> s'marks
> / 
/
/


From staffan.larsen at oracle.com  Wed Dec 11 07:17:01 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Dec 2013 08:17:01 +0100
Subject: [8] WXP minor fixes for a cleaner compile of c code
In-Reply-To: <52A80759.6030305@orange.fr>
References: <52A35FA1.8080802@orange.fr> <52A80759.6030305@orange.fr>
Message-ID: <0FE6431B-8C3D-4B41-9ED6-63B7590BC575@oracle.com>

I see you were directed here from the build-dev list. Unfortunately these are core library fixes, not hotspot fixes. I?ve added core-libs and bcc:d hotspot-dev.

Thanks,
/Staffan

On 11 dec 2013, at 07:34, Francis ANDRE  wrote:

> 
> Hi
> 
> Below are some warnings produced by the build of jdk8.
> 
> Z:/JDK/jdk8/jdk/src/share/native/java/lang/Throwable.c(48) : warning C4028:
> param?tre formel 3 diff?rent de la d?claration
> Z:/JDK/jdk8/jdk/src/windows/native/java/io/WinNTFileSystem_md.c(363) : warning
> C4101: 'pathlen': variable locale non r?f?renc?e
> Z:/JDK/jdk8/jdk/src/windows/native/common/jdk_util_md.c(45) : warning C4101:
> 'ret': variable locale non r?f?renc?e
> Z:/JDK/jdk8/jdk/src/share/bin/java.c(1253) : warning C4101: 'result': variable
> locale nonr?f?renc?e
> Z:/JDK/jdk8/jdk/src/share/bin/parse_manifest.c(196) : warning C4244: 'fonction':
> conversion de 'jlong' en 'unsigned int', perte possible de donn?es
> 
> 
> 
> And here are the fixes
> 
> diff --git a/src/share/bin/java.c b/src/share/bin/java.c
> --- a/src/share/bin/java.c
> +++ b/src/share/bin/java.c
> @@ -1250,7 +1250,6 @@
> GetApplicationClass(JNIEnv *env)
> {
>     jmethodID mid;
> -    jobject result;
>     jclass cls = GetLauncherHelperClass(env);
>     NULL_CHECK0(cls);
>     NULL_CHECK0(mid = (*env)->GetStaticMethodID(env, cls,
> diff --git a/src/share/bin/parse_manifest.c b/src/share/bin/parse_manifest.c
> --- a/src/share/bin/parse_manifest.c
> +++ b/src/share/bin/parse_manifest.c
> @@ -193,7 +193,7 @@
>         return (-1);
>     if ((buffer = malloc(END_MAXLEN)) == NULL)
>         return (-1);
> -    if ((bytes = read(fd, buffer, len)) < 0) {
> +    if ((bytes = read(fd, buffer, (size_t)len)) < 0) {
>         free(buffer);
>         return (-1);
>     }
> diff --git a/src/share/native/java/lang/Throwable.c
> b/src/share/native/java/lang/Throwable.c
> --- a/src/share/native/java/lang/Throwable.c
> +++ b/src/share/native/java/lang/Throwable.c
> @@ -44,7 +44,7 @@
>  * `this' so you can write 'throw e.fillInStackTrace();'
>  */
> JNIEXPORT jobject JNICALL
> -Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, int
> dummy)
> +Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, jint
> dummy)
> {
>     JVM_FillInStackTrace(env, throwable);
>     return throwable;
> diff --git a/src/windows/native/common/jdk_util_md.c
> b/src/windows/native/common/jdk_util_md.c
> --- a/src/windows/native/common/jdk_util_md.c
> +++ b/src/windows/native/common/jdk_util_md.c
> @@ -42,7 +42,6 @@
> JNIEXPORT HMODULE JDK_LoadSystemLibrary(const char* name) {
>     HMODULE handle = NULL;
>     char path[MAX_PATH];
> -    int ret;
> 
>     if (GetSystemDirectory(path, sizeof(path)) != 0) {
>         strcat(path, "\\");
> diff --git a/src/windows/native/java/io/WinNTFileSystem_md.c
> b/src/windows/native/java/io/WinNTFileSystem_md.c
> --- a/src/windows/native/java/io/WinNTFileSystem_md.c
> +++ b/src/windows/native/java/io/WinNTFileSystem_md.c
> @@ -360,7 +360,6 @@
>                                                   jobject file)
> {
>     jint rv = 0;
> -    jint pathlen;
> 
>     WCHAR *pathbuf = fileToNTPath(env, file, ids.path);
>     if (pathbuf == NULL)
> 
> 
> 



From magnus.ihse.bursie at oracle.com  Wed Dec 11 10:03:14 2013
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2013 11:03:14 +0100
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
In-Reply-To: <52A6F5C8.6000400@oracle.com>
References: <52A6F5C8.6000400@oracle.com>
Message-ID: <52A83862.9090303@oracle.com>

On 2013-12-10 12:06, Alan Bateman wrote:
>
> (This one is for the jdk9-dev forest once it is created)
>
> The addPropertyChangeListener and removePropertyChangeListener methods 
> defined by Pack200.{Packer,Unpacker} and LogManager methods are 
> deprecated and flagged with a warning that they "will be removed in a 
> future release". This is highlighted in the EDR and Public Review of 
> JSR 337 and also flagged in JEP 162.
>
> I'd like to swing the axe early in JDK 9 so as to give every 
> opportunity for anything that might have a dependency. There are a few 
> other modularity related changes that need to go in early too but this 
> is the only one that involves the removal of methods.
>
> The webrev with the changes is here:
>
> http://cr.openjdk.java.net/~alanb/8029805%2b8029806/webrev/

I'm glad to see this hackish stuff go away!

The build changes are mostly fine, however you remove the definition of 
BEANLESS_CLASSES_TARGETS but do not remove it everywhere. While it will 
work (expands to empty), it would be better if you fixed this line as well:
$(IMAGES_OUTPUTDIR)/lib$(PROFILE)/rt.jar: 
$(IMAGES_OUTPUTDIR)/lib$(PROFILE)/_the.rt.jar.contents 
$(RT_JAR_MANIFEST_FILE) $(PROFILE_VERSION_CLASS_TARGETS) 
$(BEANLESS_CLASSES_TARGETS)


/Magnus


From paul.sandoz at oracle.com  Wed Dec 11 10:32:19 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Dec 2013 11:32:19 +0100
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: <042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	
	<042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>
Message-ID: 


On Dec 11, 2013, at 1:27 AM, Mike Duigou  wrote:

> I have added tests and documentation for the other methods.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/
> 
> The documentation for some of the methods is ambiguous about how many access events are generated. For LRU cache is OK but other cases (counting based eviction) may care about the total number of accesses.

+ * invocation completes).  Invoking the {@code replace}, {@code merge},
+ * {@code compute} or {@code computeIfPresent} methods results in one or more
+ * accesses of the corresponding entry. The {@code putAll} method generates one

If i look at the code for say replace it generates *at most one access* in terms of affecting last access order, if the entry exists and if the old/new value constraint holds:

    @Override
    public boolean replace(K key, V oldValue, V newValue) {
        Node e; V v;
        if ((e = getNode(hash(key), key)) != null &&
            ((v = e.value) == oldValue || (v != null && v.equals(oldValue)))) {
            e.value = newValue;
            afterNodeAccess(e);
            return true;
        }
        return false;
    }


I have attempted to categorise the access behaviour of each method:

get:
  access to entry, if it exists

put:
  access to new entry

putIfAbsent
  access to entry, if it exists
  otherwise access to new entry

replace(K key, V value)
  access to entry, if it exists

replace(K key, V oldValue, V newValue)
  access to entry, if it exists and it's value is updated

computeIfAbsent:
  access to entry, if it exists and it's value is non-null, or 
  access to entry, if it exists and it's null value is updated to a non-null value [*], 
  otherwise access to new entry, if created

computeIfPresent
  access to entry, if it exists and it's non-null value is updated to a non-null value

compute
  access to entry, if it exists and it's value is updated to a non-null value,
  otherwise access to new entry, if created

merge
  access to entry, if it exists and it's value is updated to a non-null value,
  otherwise access to new entry, if created


Patterns, to help group for documentation:

get/put/putIfAbsent/replace(K key, V value): access to entry associated with the key, if entry exists after invocation completes

replace(K key, V oldValue, V newValue): access to entry associated with the key, if returns true

computeIfAbsent/computeIfPresent/compute/merge: access to entry associated with the key, if returns a non-null value.


--

[*] There is some ambiguity with computeIfAbsent. When the entry exists, it's value is null, and the value returned from the mapping function is null then, an access to that entry occurs:

        V v = mappingFunction.apply(key);
        if (old != null) {
            old.value = v;
            afterNodeAccess(old);
            return v;
        }
        else if (v == null)
            return null;

Is that a bug? I would have expected the returning of null from the mapping function to signal no-action to be taken. Thus computeIfPresent and computeIfAbsent have no side-effects for an existing entry whose value is null when the function returns null (same applies to merge, if the value parameter is null or the remapping function returns null, and to compute, if the remapping function returns null).

So perhaps that code should be:

        V v = mappingFunction.apply(key);
        if (v == null)
           return null;
        else if (old != null) {
            old.value = v;
            afterNodeAccess(old);
            return v;
        }
 
Paul.

From Alan.Bateman at oracle.com  Wed Dec 11 12:00:03 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 12:00:03 +0000
Subject: 8029805/8029806: Remove XXX addPropertyChangeListener and
	removePropertyChangeListener methods
In-Reply-To: <52A83862.9090303@oracle.com>
References: <52A6F5C8.6000400@oracle.com> <52A83862.9090303@oracle.com>
Message-ID: <52A853C3.1040807@oracle.com>

On 11/12/2013 10:03, Magnus Ihse Bursie wrote:
>
> I'm glad to see this hackish stuff go away!
>
> The build changes are mostly fine, however you remove the definition 
> of BEANLESS_CLASSES_TARGETS but do not remove it everywhere. While it 
> will work (expands to empty), it would be better if you fixed this 
> line as well:
> $(IMAGES_OUTPUTDIR)/lib$(PROFILE)/rt.jar: 
> $(IMAGES_OUTPUTDIR)/lib$(PROFILE)/_the.rt.jar.contents 
> $(RT_JAR_MANIFEST_FILE) $(PROFILE_VERSION_CLASS_TARGETS) 
> $(BEANLESS_CLASSES_TARGETS)
Thanks, I noticed this later too and will make sure to remove all 
vestiges before pushing.

-Alan


From Alan.Bateman at oracle.com  Wed Dec 11 12:01:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 12:01:56 +0000
Subject: 8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A75F6F.7020800@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A75F6F.7020800@oracle.com>
Message-ID: <52A85434.1070704@oracle.com>

On 10/12/2013 18:37, Mandy Chung wrote:
> Alan,
>
> The change looks good.   A minor one - in the class description of 
> java.lang.SecurityManager,  I suggest to remove the references to 
> java.awt.AWTPermission line 143 and 214.
Thanks Mandy. I left in these links as it's just a sample list of 
permissions but I don't have a strong opinion and I'm happy to remove 
them too.

-Alan


From artem.ananiev at oracle.com  Wed Dec 11 13:17:53 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 11 Dec 2013 17:17:53 +0400
Subject:  8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A86601.2010308@oracle.com>

Hi, Alan,

the changes look fine to me.

A short quick question: what is the reason to introduce a new 
AWTPermissions class as a holder for various AWTPermission constants? We 
can have the same fields directly in AWTPermission. The only difference 
is that AWTPermission is in java.awt, while the new class is in sun.awt, 
but such a change seem to require a CCC request anyway...

Thanks,

Artem

On 12/10/2013 5:51 PM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods
> checkTopLevelWindow, checkSystemClipboard and
> checkAccessAwtEventQueueAccess with a warning that they would be changed
> in a future release to check AllPermission. At the same time we changed
> the java.awt.Window and Toolkit methods to use checkPermission directly
> so that the legacy methods aren't used. The motive for all this is
> modules of course and the strong desire to remove the dependency on
> java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give
> every opportunity to find any potential issues. The second phase of this
> work changes the SecurityManager methods to check AllPermission and
> updates the implementation to remove the reflection hackery that was
> used to allow this code work without AWT being present (something that
> was needed for the profiles build).
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for the
> updated methods and also agreement from the AWT group to move the
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.


From Alan.Bateman at oracle.com  Wed Dec 11 13:53:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 13:53:27 +0000
Subject:  8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A86601.2010308@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A86601.2010308@oracle.com>
Message-ID: <52A86E57.1090300@oracle.com>

On 11/12/2013 13:17, Artem Ananiev wrote:
> Hi, Alan,
>
> the changes look fine to me.
>
> A short quick question: what is the reason to introduce a new 
> AWTPermissions class as a holder for various AWTPermission constants? 
> We can have the same fields directly in AWTPermission. The only 
> difference is that AWTPermission is in java.awt, while the new class 
> is in sun.awt, but such a change seem to require a CCC request anyway...
>
Thanks Artem. Adding them to AWTPermission would bring them into Java SE 
/ public API and that doesn't seem to be worth it. The main thing is 
that we move them out of sun.security.util.SecurityConstants so that we 
can finally eliminate the execution-time dependency (what we have in the 
jdk8 forest is okay for profiles but we need to do better with modules).

-Alan.


From sean.mullan at oracle.com  Wed Dec 11 16:16:04 2013
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 11 Dec 2013 11:16:04 -0500
Subject: 8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A88FC4.8030203@oracle.com>

On 12/10/2013 08:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods
> checkTopLevelWindow, checkSystemClipboard and
> checkAccessAwtEventQueueAccess with a warning that they would be changed
> in a future release to check AllPermission. At the same time we changed
> the java.awt.Window and Toolkit methods to use checkPermission directly
> so that the legacy methods aren't used. The motive for all this is
> modules of course and the strong desire to remove the dependency on
> java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give
> every opportunity to find any potential issues. The second phase of this
> work changes the SecurityManager methods to check AllPermission and
> updates the implementation to remove the reflection hackery that was
> used to allow this code work without AWT being present (something that
> was needed for the profiles build).
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for the
> updated methods and also agreement from the AWT group to move the
> permission constants to a new class sun.awt.AWTPermissions.

The code changes and suggested wording for the updated methods look fine 
to me. Please add a release-note=yes label to the issue. The permissions 
security guide will also need to be updated with the new behavior of 
these methods: 
http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods 
-- I suggest adding a comment indicating that so we remember to update 
the docs as part of writing the release notes task.

--Sean




From Alan.Bateman at oracle.com  Wed Dec 11 16:23:55 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 16:23:55 +0000
Subject: 8029886: Change SecurityManager check{TopLevelWindow,
	SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A88FC4.8030203@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A88FC4.8030203@oracle.com>
Message-ID: <52A8919B.8020407@oracle.com>

On 11/12/2013 16:16, Sean Mullan wrote:
>
> The code changes and suggested wording for the updated methods look 
> fine to me. Please add a release-note=yes label to the issue. The 
> permissions security guide will also need to be updated with the new 
> behavior of these methods: 
> http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods 
> -- I suggest adding a comment indicating that so we remember to update 
> the docs as part of writing the release notes task.
Thanks for the pointer to that guide, I wasn't aware for it (and now 
that I read it then I see that it is out of date, the changes that are 
you suggesting we need to remember are required now because those 
methods had their spec changes in 8 to use checkPermission directly).

-Alan


From martinrb at google.com  Wed Dec 11 18:48:36 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Dec 2013 10:48:36 -0800
Subject: Map.forEach
In-Reply-To: <52A76ABA.7090006@cs.oswego.edu>
References: 
	<75A65BCC-BF3F-49FD-BC44-D63D93C63B5A@oracle.com>
	
	<928E862C-F477-4AB7-87DC-9B9BDE8963C7@oracle.com>
	
	<52A76ABA.7090006@cs.oswego.edu>
Message-ID: 

Alright, it's true that the "Concurrent" prefix of ConcurrentMap's name is
a strong hint that implementing classes are expected to be "concurrent" as
defined in the package javadoc.  But if we are serious about that, we
should at least add some guidance to the javadoc for the interface itself,
as we recently did for null handling.  Even the jdk7 version of
ConcurrentMap had methods that access multiple entries, if you count
methods inherited from Map.  But even in jdk8, with the addition of forEach
and replaceAll, there is no discussion of weak consistency and CME.

I see that Hashtable.forEach is synchronized.  This seems obligatory, given
the risk of CME, but it's not reflected in the documentation!  That should
be fixed - users need to know!


On Tue, Dec 10, 2013 at 11:25 AM, Doug Lea 
         wrote:

> On 12/10/2013 01:15 PM, Martin Buchholz wrote:
>
>> Perhaps Doug could provide history on the intent of ConcurrentMap.
>>
>
> See the package-level docs in java.util.concurrent that compare
> Hashtable to ConcurrentMap, implying that it might not be a good idea
> to now retrospectively declare Hashtable as a ConcurrentMap even though,
> through the magic of defaults, they share methods.
>
> Pasting...
>
>
> The "Concurrent" prefix used with some classes in this package is a
> shorthand indicating several differences from similar "synchronized"
> classes. For example java.util.Hashtable and Collections.synchronizedMap(new
> HashMap()) are synchronized. But ConcurrentHashMap is "concurrent". A
> concurrent collection is thread-safe, but not governed by a single
> exclusion lock. In the particular case of ConcurrentHashMap, it safely
> permits any number of concurrent reads as well as a tunable number of
> concurrent writes. "Synchronized" classes can be useful when you need to
> prevent all access to a collection via a single lock, at the expense of
> poorer scalability. In other cases in which multiple threads are expected
> to access a common collection, "concurrent" versions are normally
> preferable. And unsynchronized collections are preferable when either
> collections are unshared, or are accessible only when holding other locks.
>
> Most concurrent Collection implementations (including most Queues) also
> differ from the usual java.util conventions in that their Iterators and
> Spliterators provide weakly consistent rather than fast-fail traversal:
>
>     they may proceed concurrently with other operations
>     they will never throw ConcurrentModificationException
>     they are guaranteed to traverse elements as they existed upon
> construction exactly once, and may (but are not guaranteed to) reflect any
> modifications subsequent to construction.
>


From huizhe.wang at oracle.com  Wed Dec 11 19:52:29 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 11 Dec 2013 11:52:29 -0800
Subject: RFR (JAXP) 8029895 :  XMLOutputFactory.newFactory(String, ClassLoader)
	- incorrect specification
Message-ID: <52A8C27D.40004@oracle.com>

Hi,

This is a quick documentation change to fix an error in 
javax.xml.stream.XMLOutputFactory:

http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/

Thanks,
Joe


From kumar.x.srinivasan at oracle.com  Wed Dec 11 20:08:00 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 11 Dec 2013 12:08:00 -0800
Subject: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
Message-ID: <52A8C620.1050406@oracle.com>

Hello Joe, Martin, et. al.,

In JDK8, solaris 32-bit support was removed entirely, this is the only 
platform that required
  dual-mode support, ie. 32-bit and 64-bit binaries co-located in the 
same binary hierarchy
on the disk. In JDK 8 the DUAL_MODE support was disabled in the 
launcher, using compile
time conditionals, however  in JDK9 we wish to remove the logic 
entirely, this is messy and
makes the launcher cleaner and easier to maintain.

Webrev:
http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/

Thanks
Kumar



From daniel.fuchs at oracle.com  Wed Dec 11 20:15:38 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 11 Dec 2013 21:15:38 +0100
Subject: RFR (JAXP) 8029895 :  XMLOutputFactory.newFactory(String,
	ClassLoader) - incorrect specification
In-Reply-To: <52A8C27D.40004@oracle.com>
References: <52A8C27D.40004@oracle.com>
Message-ID: <52A8C7EA.3010700@oracle.com>

On 12/11/13 8:52 PM, huizhe wang wrote:
> Hi,
>
> This is a quick documentation change to fix an error in
> javax.xml.stream.XMLOutputFactory:
>
> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
>
> Thanks,
> Joe

Hi Joe,

Looks good to me - but I'm not a native English speaker :-)

-- daniel


From Alan.Bateman at oracle.com  Wed Dec 11 20:21:05 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 20:21:05 +0000
Subject: RFR (JAXP) 8029895 :  XMLOutputFactory.newFactory(String,
	ClassLoader) - incorrect specification
In-Reply-To: <52A8C27D.40004@oracle.com>
References: <52A8C27D.40004@oracle.com>
Message-ID: <52A8C931.40401@oracle.com>

On 11/12/2013 19:52, huizhe wang wrote:
> Hi,
>
> This is a quick documentation change to fix an error in 
> javax.xml.stream.XMLOutputFactory:
>
> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
>
> Thanks,
> Joe
It looks okay although I think it could be reduced to something like 
"The original method was incorrectly defined to return XMLInputFactory".

-Alan.


From martinrb at google.com  Wed Dec 11 20:25:54 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Dec 2013 12:25:54 -0800
Subject: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
In-Reply-To: <52A8C620.1050406@oracle.com>
References: <52A8C620.1050406@oracle.com>
Message-ID: 

Although I have a small emotional attachment to the idea of fat binaries,
there doesn't seem to be too much support for this in the larger java
community, and probably the larger unix community will be 64-bit only
relatively soon.  So ... OK.

There's one remaining mention of "LD_LIBRARY_PATH_32".  Maybe you want to
scrub that as well?

 589                 (void)UnsetEnv((wanted == 32) ?
"LD_LIBRARY_PATH_32" : "LD_LIBRARY_PATH_64");




On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan <
kumar.x.srinivasan at oracle.com> wrote:

> Hello Joe, Martin, et. al.,
>
> In JDK8, solaris 32-bit support was removed entirely, this is the only
> platform that required
>  dual-mode support, ie. 32-bit and 64-bit binaries co-located in the same
> binary hierarchy
> on the disk. In JDK 8 the DUAL_MODE support was disabled in the launcher,
> using compile
> time conditionals, however  in JDK9 we wish to remove the logic entirely,
> this is messy and
> makes the launcher cleaner and easier to maintain.
>
> Webrev:
> http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/
>
> Thanks
> Kumar
>
>


From robert.field at oracle.com  Wed Dec 11 19:57:53 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 11 Dec 2013 19:57:53 +0000
Subject: hg: jdk8/tl/langtools: 8029558: java.lang.VerifyError: Bad return
	type when lambda's body is in parentheses
Message-ID: <20131211195758.EB19162C01@hg.openjdk.java.net>

Changeset: 847cc0cccfa1
Author:    rfield
Date:      2013-12-11 11:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/847cc0cccfa1

8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses
Summary: properly type convert the body of a lambda expression
Reviewed-by: vromero

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/LambdaParenGeneric.java
+ test/tools/javac/lambda/LambdaParenGenericOrig.java



From lowasser at google.com  Wed Dec 11 20:51:49 2013
From: lowasser at google.com (Louis Wasserman)
Date: Wed, 11 Dec 2013 12:51:49 -0800
Subject: Collectors factory methods don't check for null
Message-ID: 

For example, Collectors.toMap(Function, Function) does not throw if its
arguments are null; it's only when you actually try to use the Collector
that you get a failure.

This seems to be against established convention for JDK utilities.  Is
there a specific reason?

-- 
Louis Wasserman


From huizhe.wang at oracle.com  Wed Dec 11 21:10:52 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 11 Dec 2013 13:10:52 -0800
Subject: RFR (JAXP) 8029895 :  XMLOutputFactory.newFactory(String,
	ClassLoader) - incorrect specification
In-Reply-To: <52A8C931.40401@oracle.com>
References: <52A8C27D.40004@oracle.com> <52A8C931.40401@oracle.com>
Message-ID: <52A8D4DC.8050104@oracle.com>


On 12/11/2013 12:21 PM, Alan Bateman wrote:
> On 11/12/2013 19:52, huizhe wang wrote:
>> Hi,
>>
>> This is a quick documentation change to fix an error in 
>> javax.xml.stream.XMLOutputFactory:
>>
>> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
>>
>> Thanks,
>> Joe
> It looks okay although I think it could be reduced to something like 
> "The original method was incorrectly defined to return XMLInputFactory".

Updated to use your statement:

http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/

-Joe

>
> -Alan.



From kumar.x.srinivasan at oracle.com  Wed Dec 11 21:12:46 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 11 Dec 2013 13:12:46 -0800
Subject: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
In-Reply-To: 
References: <52A8C620.1050406@oracle.com>
	
Message-ID: <52A8D54E.6040708@oracle.com>


On 12/11/2013 12:25 PM, Martin Buchholz wrote:
> Although I have a small emotional attachment to the idea of fat 
> binaries, there doesn't seem to be too much support for this in the 
> larger java community, and probably the larger unix community will be 
> 64-bit only relatively soon.  So ... OK.
>
> There's one remaining mention of "LD_LIBRARY_PATH_32".  Maybe you want 
> to scrub that as well?
>   589                 (void)UnsetEnv((wanted == 32) ? "LD_LIBRARY_PATH_32" : "LD_LIBRARY_PATH_64");
>
Good catch I will scrub that.
Thanks Martin.

Kumar

>
>
> On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan 
> > 
> wrote:
>
>     Hello Joe, Martin, et. al.,
>
>     In JDK8, solaris 32-bit support was removed entirely, this is the
>     only platform that required
>      dual-mode support, ie. 32-bit and 64-bit binaries co-located in
>     the same binary hierarchy
>     on the disk. In JDK 8 the DUAL_MODE support was disabled in the
>     launcher, using compile
>     time conditionals, however  in JDK9 we wish to remove the logic
>     entirely, this is messy and
>     makes the launcher cleaner and easier to maintain.
>
>     Webrev:
>     http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/
>     
>
>     Thanks
>     Kumar
>
>



From stuart.marks at oracle.com  Wed Dec 11 21:33:53 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Dec 2013 13:33:53 -0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <52A7C98E.7000200@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>	<529FD0A9.9020400@oracle.com>
	<52A7C98E.7000200@oracle.com>
Message-ID: <52A8DA41.1020909@oracle.com>

On 12/10/13 6:10 PM, Tristan Yan wrote:
> /Hi everyone
> I am working on bug JDK-7168267
>  .

Correct link is

https://bugs.openjdk.java.net/browse/JDK-7168267

> Root Cause:
> - Per Stuart's comment, this is a clean up bug.
>
> Suggested Fix:
> - Will use timeout to replace loop.

We should probably look at specific cases for this. There are places where the 
test is waiting for some external service to become ready (e.g., rmiregistry). 
There's no notification for things like this so wait-with-timeout cannot be 
used. Pretty much the only thing that can be done is to poll reasonably often 
until the service is ready, or until the timeout is exceeded.

> - Also I am fixing two test's performance
> java/rmi/activation/Activatable/forceLogSnapshot - method waitAllStarted is
> using sleep to poll 50 restartedObject to be true, we can use modern
> CountDownLatch to implement blocking-time wait.
> java/rmi/activation/Activatable/checkAnnotations - We can subclass
> ByteArrayOutputStream which support notification when data was written. Also use
> two thread wait output string and error string to be not null.

These sound reasonble. Go ahead and file sub-tasks for these and then choose one 
to work on first. (I think it will get too confusing if we try to work on them 
all simultaneously.) Either post a detailed description of what you intend to 
do, or if it's simple enough, just post a webrev.

s'marks

>
> Please let me know if you have any comments or suggestions.
> / /
> Thank you
> Tristan
>
> On 12/05/2013 09:02 AM, Stuart Marks wrote:
> /
>> /On 12/3/13 11:05 PM, Tristan Yan wrote:
>> /
>>> /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is
>>> asking performance improvement for RMI test. Because this would involve
>>> different RMI tests. I?d like to use this cr as an umbrella bug, create sub-cr
>>> for different test. Then I can make progress on sub-cr. Please let me know your
>>> opinion on this.
>>> /
>> /
>> Actually JDK-7168267 is more about various test cleanups, and JDK-8005436 is
>> more about performance. Both bugs, though, make general statements about "the
>> RMI tests" and don't have much information about specific actions that need to
>> be taken. I've added some notes to JDK-7168267 about some cleanups that could
>> be done.
>> / /
>> If there are specific actions for either of these bugs, then yes, creating
>> Sub-Tasks of these bugs and fixing them individually is the right thing to do.
>> / /
>> s'marks
>> /
> /
> /


From Lance.Andersen at oracle.com  Wed Dec 11 21:43:46 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 11 Dec 2013 16:43:46 -0500
Subject: RFR (JAXP) 8029895 :  XMLOutputFactory.newFactory(String,
	ClassLoader) - incorrect specification
In-Reply-To: <52A8D4DC.8050104@oracle.com>
References: <52A8C27D.40004@oracle.com> <52A8C931.40401@oracle.com>
	<52A8D4DC.8050104@oracle.com>
Message-ID: <437A95D5-93C4-48E7-832C-E831F5D1FA99@oracle.com>

looks fine joe
On Dec 11, 2013, at 4:10 PM, huizhe wang wrote:

> 
> On 12/11/2013 12:21 PM, Alan Bateman wrote:
>> On 11/12/2013 19:52, huizhe wang wrote:
>>> Hi,
>>> 
>>> This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory:
>>> 
>>> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
>>> 
>>> Thanks,
>>> Joe
>> It looks okay although I think it could be reduced to something like "The original method was incorrectly defined to return XMLInputFactory".
> 
> Updated to use your statement:
> 
> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
> 
> -Joe
> 
>> 
>> -Alan.
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From mandy.chung at oracle.com  Wed Dec 11 21:48:54 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Dec 2013 13:48:54 -0800
Subject: [8] WXP minor fixes for a cleaner compile of c code
In-Reply-To: <0FE6431B-8C3D-4B41-9ED6-63B7590BC575@oracle.com>
References: <52A35FA1.8080802@orange.fr> <52A80759.6030305@orange.fr>
	<0FE6431B-8C3D-4B41-9ED6-63B7590BC575@oracle.com>
Message-ID: <52A8DDC6.8080403@oracle.com>

I have filed https://bugs.openjdk.java.net/browse/JDK-8030010 to clean 
up these warning and I can sponsor it.

Mandy

On 12/10/2013 11:17 PM, Staffan Larsen wrote:
> I see you were directed here from the build-dev list. Unfortunately these are core library fixes, not hotspot fixes. I?ve added core-libs and bcc:d hotspot-dev.
>
> Thanks,
> /Staffan
>
> On 11 dec 2013, at 07:34, Francis ANDRE  wrote:
>
>> Hi
>>
>> Below are some warnings produced by the build of jdk8.
>>
>> Z:/JDK/jdk8/jdk/src/share/native/java/lang/Throwable.c(48) : warning C4028:
>> param?tre formel 3 diff?rent de la d?claration
>> Z:/JDK/jdk8/jdk/src/windows/native/java/io/WinNTFileSystem_md.c(363) : warning
>> C4101: 'pathlen': variable locale non r?f?renc?e
>> Z:/JDK/jdk8/jdk/src/windows/native/common/jdk_util_md.c(45) : warning C4101:
>> 'ret': variable locale non r?f?renc?e
>> Z:/JDK/jdk8/jdk/src/share/bin/java.c(1253) : warning C4101: 'result': variable
>> locale nonr?f?renc?e
>> Z:/JDK/jdk8/jdk/src/share/bin/parse_manifest.c(196) : warning C4244: 'fonction':
>> conversion de 'jlong' en 'unsigned int', perte possible de donn?es
>>
>>
>>
>> And here are the fixes
>>
>> diff --git a/src/share/bin/java.c b/src/share/bin/java.c
>> --- a/src/share/bin/java.c
>> +++ b/src/share/bin/java.c
>> @@ -1250,7 +1250,6 @@
>> GetApplicationClass(JNIEnv *env)
>> {
>>      jmethodID mid;
>> -    jobject result;
>>      jclass cls = GetLauncherHelperClass(env);
>>      NULL_CHECK0(cls);
>>      NULL_CHECK0(mid = (*env)->GetStaticMethodID(env, cls,
>> diff --git a/src/share/bin/parse_manifest.c b/src/share/bin/parse_manifest.c
>> --- a/src/share/bin/parse_manifest.c
>> +++ b/src/share/bin/parse_manifest.c
>> @@ -193,7 +193,7 @@
>>          return (-1);
>>      if ((buffer = malloc(END_MAXLEN)) == NULL)
>>          return (-1);
>> -    if ((bytes = read(fd, buffer, len)) < 0) {
>> +    if ((bytes = read(fd, buffer, (size_t)len)) < 0) {
>>          free(buffer);
>>          return (-1);
>>      }
>> diff --git a/src/share/native/java/lang/Throwable.c
>> b/src/share/native/java/lang/Throwable.c
>> --- a/src/share/native/java/lang/Throwable.c
>> +++ b/src/share/native/java/lang/Throwable.c
>> @@ -44,7 +44,7 @@
>>   * `this' so you can write 'throw e.fillInStackTrace();'
>>   */
>> JNIEXPORT jobject JNICALL
>> -Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, int
>> dummy)
>> +Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, jint
>> dummy)
>> {
>>      JVM_FillInStackTrace(env, throwable);
>>      return throwable;
>> diff --git a/src/windows/native/common/jdk_util_md.c
>> b/src/windows/native/common/jdk_util_md.c
>> --- a/src/windows/native/common/jdk_util_md.c
>> +++ b/src/windows/native/common/jdk_util_md.c
>> @@ -42,7 +42,6 @@
>> JNIEXPORT HMODULE JDK_LoadSystemLibrary(const char* name) {
>>      HMODULE handle = NULL;
>>      char path[MAX_PATH];
>> -    int ret;
>>
>>      if (GetSystemDirectory(path, sizeof(path)) != 0) {
>>          strcat(path, "\\");
>> diff --git a/src/windows/native/java/io/WinNTFileSystem_md.c
>> b/src/windows/native/java/io/WinNTFileSystem_md.c
>> --- a/src/windows/native/java/io/WinNTFileSystem_md.c
>> +++ b/src/windows/native/java/io/WinNTFileSystem_md.c
>> @@ -360,7 +360,6 @@
>>                                                    jobject file)
>> {
>>      jint rv = 0;
>> -    jint pathlen;
>>
>>      WCHAR *pathbuf = fileToNTPath(env, file, ids.path);
>>      if (pathbuf == NULL)
>>
>>
>>



From stuart.marks at oracle.com  Wed Dec 11 21:53:33 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Dec 2013 13:53:33 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
Message-ID: <52A8DEDD.6060107@oracle.com>

Hi all,

Just one more deprecation task for JDK 8....

Please review the following change to rmic to add a warning message that's 
emitted when static stubs are generated:

http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/

https://bugs.openjdk.java.net/browse/JDK-8027536

Thanks,

s'marks


From roger.riggs at oracle.com  Wed Dec 11 22:09:48 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Wed, 11 Dec 2013 22:09:48 +0000
Subject: hg: jdk8/tl/jdk: 8029551: Add value-type notice to java.time classes
Message-ID: <20131211221007.6C44562C0B@hg.openjdk.java.net>

Changeset: fe3383582427
Author:    rriggs
Date:      2013-12-11 16:52 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe3383582427

8029551: Add value-type notice to java.time classes
Summary: Add warning about identity of value types and reference to ValueBased.html
Reviewed-by: briangoetz, smarks, scolebourne

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java



From mandy.chung at oracle.com  Wed Dec 11 22:25:31 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Dec 2013 14:25:31 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
In-Reply-To: <52A8DEDD.6060107@oracle.com>
References: <52A8DEDD.6060107@oracle.com>
Message-ID: <52A8E65B.5040306@oracle.com>

On 12/11/2013 1:53 PM, Stuart Marks wrote:
> Hi all,
>
> Just one more deprecation task for JDK 8....
>
> Please review the following change to rmic to add a warning message 
> that's emitted when static stubs are generated:
>
> http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
>

The change looks okay.   The error(...) method is called to print 
warnings seems to be confusing.  Perhaps better to call 
output(getText(....)) directly?

Mandy

> https://bugs.openjdk.java.net/browse/JDK-8027536
>
> Thanks,
>
> s'marks



From mandy.chung at oracle.com  Wed Dec 11 22:37:22 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Dec 2013 14:37:22 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
In-Reply-To: <52A8E65B.5040306@oracle.com>
References: <52A8DEDD.6060107@oracle.com> <52A8E65B.5040306@oracle.com>
Message-ID: <52A8E922.1050400@oracle.com>

On 12/11/2013 2:25 PM, Mandy Chung wrote:
> On 12/11/2013 1:53 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Just one more deprecation task for JDK 8....
>>
>> Please review the following change to rmic to add a warning message 
>> that's emitted when static stubs are generated:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
>>
>
> The change looks okay.   The error(...) method is called to print 
> warnings seems to be confusing.  Perhaps better to call 
> output(getText(....)) directly?

One other note:  AFAIK the last message drop for jdk8 localization was 
done.  It means that the Japanese and Chinese version will not be 
updated matching your patch.   It's okay for the new warning message as 
it will fall back to the default English version.   For the existing 
-v1.1, -vcompat, -v1.2 options, the Japanese and Chinese version will 
not have "(deprecated)" word in it.   I suggest to edit the other 
localized versions to update the modified existing messages.

Mandy


From kumar.x.srinivasan at oracle.com  Wed Dec 11 23:21:44 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 11 Dec 2013 15:21:44 -0800
Subject: RFR: JDK9: 8029388: java.exe consumes argument intended for launched
	java class
Message-ID: <52A8F388.6010907@oracle.com>

Hello,

Please review a fix for Windows launcher where it consumes application args
-d32 and -d64, the fix is to stop the scan when it hits the Application 
sentinel
ie. class-name or jar-name.

http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/

Thanks
Kumar



From mike.duigou at oracle.com  Wed Dec 11 23:30:07 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 11 Dec 2013 23:30:07 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131211233032.81D2762C0F@hg.openjdk.java.net>

Changeset: 1298e476729c
Author:    michaelm
Date:      2013-12-11 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1298e476729c

8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method
Reviewed-by: mduigou
Contributed-by: michael.mcmahon at oracle.com

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java

Changeset: 1970e3c3d202
Author:    michaelm
Date:      2013-12-11 15:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1970e3c3d202

8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream
Reviewed-by: mduigou

! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java



From darryl.mocek at oracle.com  Wed Dec 11 23:39:39 2013
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Wed, 11 Dec 2013 15:39:39 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
In-Reply-To: <52A8DEDD.6060107@oracle.com>
References: <52A8DEDD.6060107@oracle.com>
Message-ID: <52A8F7BB.1030002@oracle.com>

Should this be a warning or error?

Darryl

On 12/11/2013 01:53 PM, Stuart Marks wrote:
> Hi all,
>
> Just one more deprecation task for JDK 8....
>
> Please review the following change to rmic to add a warning message 
> that's emitted when static stubs are generated:
>
> http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
>
> https://bugs.openjdk.java.net/browse/JDK-8027536
>
> Thanks,
>
> s'marks



From mandy.chung at oracle.com  Thu Dec 12 00:37:16 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Dec 2013 16:37:16 -0800
Subject: RFR: JDK9: 8029388: java.exe consumes argument intended for
	launched java class
In-Reply-To: <52A8F388.6010907@oracle.com>
References: <52A8F388.6010907@oracle.com>
Message-ID: <52A9053C.6020607@oracle.com>

On 12/11/2013 3:21 PM, Kumar Srinivasan wrote:
> Hello,
>
> Please review a fix for Windows launcher where it consumes application 
> args
> -d32 and -d64, the fix is to stop the scan when it hits the 
> Application sentinel
> ie. class-name or jar-name.
>
> http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/

Nit: can we start checking from argv[1] and skip argv[0]?   line 194 no 
need to check i > 0 then.

Nit: line 95 - an extra space before "dmodel".   A general question -  
doExec handles the case when the cmd terminates with an exception.  I 
was wondering if the generated Args class should just throw an exception 
if it doesn't match the expected value (i.e. have Args class to do the 
verification).  I pondered a little bit when reading the verifyOption 
method before I read the createOptionsJar method.

Otherwise, looks good.

Mandy


From kumar.x.srinivasan at oracle.com  Thu Dec 12 02:09:53 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 11 Dec 2013 18:09:53 -0800
Subject: RFR: JDK9: 8029388: java.exe consumes argument intended for
	launched java class
In-Reply-To: <52A9053C.6020607@oracle.com>
References: <52A8F388.6010907@oracle.com> <52A9053C.6020607@oracle.com>
Message-ID: <52A91AF1.100@oracle.com>


Mandy,

Thanks for the review.

> On 12/11/2013 3:21 PM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review a fix for Windows launcher where it consumes 
>> application args
>> -d32 and -d64, the fix is to stop the scan when it hits the 
>> Application sentinel
>> ie. class-name or jar-name.
>>
>> http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/
>
> Nit: can we start checking from argv[1] and skip argv[0]?   line 194 
> no need to check i > 0 then.

Yes, we can start from 1 instead of 0.

>
> Nit: line 95 - an extra space before "dmodel".   A general question -  
> doExec handles the case when the cmd 

Will fix that.

> terminates with an exception.  I was wondering if the generated Args 
> class should just throw an exception if it doesn't match the expected 
> value (i.e. have Args class to do the verification).  I pondered a 
> little bit when reading the verifyOption method before I read the 
> createOptionsJar method.

I have tried to keep the generated classes as simple as possible, 
compilation failures
and errors in these are hard to track down.

Kumar

>
> Otherwise, looks good.
>
> Mandy



From michael.fang at oracle.com  Thu Dec 12 05:24:56 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Thu, 12 Dec 2013 05:24:56 +0000
Subject: hg: jdk8/tl/jdk: 8026115: [zh_CN] inproper translation in output of
	jarsigner command
Message-ID: <20131212052509.A0A9E62C15@hg.openjdk.java.net>

Changeset: 01b11184bcf9
Author:    mfang
Date:      2013-12-11 21:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b11184bcf9

8026115: [zh_CN] inproper translation in output of jarsigner command
Reviewed-by: naoto, yhuang

! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java



From mike.duigou at oracle.com  Thu Dec 12 05:24:43 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 11 Dec 2013 21:24:43 -0800
Subject: RFR: 8030016: HashMap.computeIfAbsent generates spurious access event
Message-ID: 

Hello all;

In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects that behaviour.

http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/

The actual regression test is LinkedHashMap/ComputeIfAbsentAccessOrder.java whereas the changes to Map/Defaults are improvements to the existing tests suggested by this bug (though they would not detect it).

Cheers,

Mike

From sundararajan.athijegannathan at oracle.com  Thu Dec 12 04:58:58 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 12 Dec 2013 04:58:58 +0000
Subject: hg: jdk8/tl/nashorn: 3 new changesets
Message-ID: <20131212045902.34FFF62C13@hg.openjdk.java.net>

Changeset: 4706897b4dec
Author:    attila
Date:      2013-12-09 10:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4706897b4dec

8029467: Widening of booleans causes bad results
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8029467.js
+ test/script/basic/JDK-8029467.js.EXPECTED

Changeset: 18edd7a1b166
Author:    lagergren
Date:      2013-12-11 18:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18edd7a1b166

8029780: "ant externals" broke our test harness with the latest version of the octane benchmarks
Reviewed-by: attila, sundar

! make/build-benchmark.xml
! test/script/basic/compile-octane-splitter.js.EXPECTED
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js

Changeset: e452a3797290
Author:    sundar
Date:      2013-12-12 09:18 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e452a3797290

Merge




From joe.darcy at oracle.com  Thu Dec 12 07:28:03 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 11 Dec 2013 23:28:03 -0800
Subject: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
In-Reply-To: <52A8D54E.6040708@oracle.com>
References: <52A8C620.1050406@oracle.com>	
	<52A8D54E.6040708@oracle.com>
Message-ID: <52A96583.9020703@oracle.com>

Hi Kumar,

Will be glad to see this "feature" purged from the sources!

I believe the comments on lines 135 to 167 in the new file still need 
some updating.

The comment block on line 261 - 273 may need revising too.

Otherwise, looks fine.

Thanks,

-Joe

On 12/11/2013 01:12 PM, Kumar Srinivasan wrote:
>
> On 12/11/2013 12:25 PM, Martin Buchholz wrote:
>> Although I have a small emotional attachment to the idea of fat 
>> binaries, there doesn't seem to be too much support for this in the 
>> larger java community, and probably the larger unix community will be 
>> 64-bit only relatively soon.  So ... OK.
>>
>> There's one remaining mention of "LD_LIBRARY_PATH_32".  Maybe you 
>> want to scrub that as well?
>>   589                 (void)UnsetEnv((wanted == 32) ? 
>> "LD_LIBRARY_PATH_32" : "LD_LIBRARY_PATH_64");
>>
> Good catch I will scrub that.
> Thanks Martin.
>
> Kumar
>
>>
>>
>> On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan 
>> > > wrote:
>>
>>     Hello Joe, Martin, et. al.,
>>
>>     In JDK8, solaris 32-bit support was removed entirely, this is the
>>     only platform that required
>>      dual-mode support, ie. 32-bit and 64-bit binaries co-located in
>>     the same binary hierarchy
>>     on the disk. In JDK 8 the DUAL_MODE support was disabled in the
>>     launcher, using compile
>>     time conditionals, however  in JDK9 we wish to remove the logic
>>     entirely, this is messy and
>>     makes the launcher cleaner and easier to maintain.
>>
>>     Webrev:
>>     http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/
>> 
>>
>>     Thanks
>>     Kumar
>>
>>
>



From kumar.x.srinivasan at oracle.com  Thu Dec 12 16:15:50 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 12 Dec 2013 08:15:50 -0800
Subject: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support
In-Reply-To: <52A96583.9020703@oracle.com>
References: <52A8C620.1050406@oracle.com>	
	<52A8D54E.6040708@oracle.com> <52A96583.9020703@oracle.com>
Message-ID: <52A9E136.2050802@oracle.com>


Joe,

Thanks for the review.

> Hi Kumar,
>
> Will be glad to see this "feature" purged from the sources!
>
> I believe the comments on lines 135 to 167 in the new file still need 
> some updating.
>
> The comment block on line 261 - 273 may need revising too.

Got it, I will fix those.

Thanks
Kumar

>
> Otherwise, looks fine.
>
> Thanks,
>
> -Joe
>
> On 12/11/2013 01:12 PM, Kumar Srinivasan wrote:
>>
>> On 12/11/2013 12:25 PM, Martin Buchholz wrote:
>>> Although I have a small emotional attachment to the idea of fat 
>>> binaries, there doesn't seem to be too much support for this in the 
>>> larger java community, and probably the larger unix community will 
>>> be 64-bit only relatively soon.  So ... OK.
>>>
>>> There's one remaining mention of "LD_LIBRARY_PATH_32".  Maybe you 
>>> want to scrub that as well?
>>>   589                 (void)UnsetEnv((wanted == 32) ? 
>>> "LD_LIBRARY_PATH_32" : "LD_LIBRARY_PATH_64");
>>>
>> Good catch I will scrub that.
>> Thanks Martin.
>>
>> Kumar
>>
>>>
>>>
>>> On Wed, Dec 11, 2013 at 12:08 PM, Kumar Srinivasan 
>>> >> > wrote:
>>>
>>>     Hello Joe, Martin, et. al.,
>>>
>>>     In JDK8, solaris 32-bit support was removed entirely, this is the
>>>     only platform that required
>>>      dual-mode support, ie. 32-bit and 64-bit binaries co-located in
>>>     the same binary hierarchy
>>>     on the disk. In JDK 8 the DUAL_MODE support was disabled in the
>>>     launcher, using compile
>>>     time conditionals, however  in JDK9 we wish to remove the logic
>>>     entirely, this is messy and
>>>     makes the launcher cleaner and easier to maintain.
>>>
>>>     Webrev:
>>>     http://cr.openjdk.java.net/~ksrini/8024033/webrev.0/
>>> 
>>>
>>>     Thanks
>>>     Kumar
>>>
>>>
>>
>



From stuart.marks at oracle.com  Thu Dec 12 17:22:55 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Dec 2013 09:22:55 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
In-Reply-To: <52A8E922.1050400@oracle.com>
References: <52A8DEDD.6060107@oracle.com> <52A8E65B.5040306@oracle.com>
	<52A8E922.1050400@oracle.com>
Message-ID: <52A9F0EF.1090502@oracle.com>



On 12/11/13 2:37 PM, Mandy Chung wrote:
> The change looks okay.   The error(...) method is called to print warnings
> seems to be confusing.  Perhaps better to call output(getText(....)) directly?

Yeah, it's confusing. I'll change it.

> One other note:  AFAIK the last message drop for jdk8 localization was done.  It
> means that the Japanese and Chinese version will not be updated matching your
> patch.   It's okay for the new warning message as it will fall back to the
> default English version.   For the existing -v1.1, -vcompat, -v1.2 options, the
> Japanese and Chinese version will not have "(deprecated)" word in it.   I
> suggest to edit the other localized versions to update the modified existing
> messages.

Good point. I'll check with the localization folks on this.

s'marks



From stuart.marks at oracle.com  Thu Dec 12 17:27:32 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Dec 2013 09:27:32 -0800
Subject: RFR: 8027536: rmic: add deprecation warning message
In-Reply-To: <52A8F7BB.1030002@oracle.com>
References: <52A8DEDD.6060107@oracle.com> <52A8F7BB.1030002@oracle.com>
Message-ID: <52A9F204.1050004@oracle.com>

Per Mandy's comment, there's a call to error() but it really just issues a 
warning and proceeds the processing. I'll change it to output(getText()).

But it really should be just a warning. This functionality is deprecated, so for 
JDK 8 there are disclaimers in docs and warnings issued by tools like javac and 
now rmic, but using the deprecated features will still work. (For the time 
being, heh heh heh.)

s'marks

On 12/11/13 3:39 PM, Darryl Mocek wrote:
> Should this be a warning or error?
>
> Darryl
>
> On 12/11/2013 01:53 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Just one more deprecation task for JDK 8....
>>
>> Please review the following change to rmic to add a warning message that's
>> emitted when static stubs are generated:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8027536
>>
>> Thanks,
>>
>> s'marks
>


From bourges.laurent at gmail.com  Thu Dec 12 17:38:51 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 12 Dec 2013 18:38:51 +0100
Subject: Conflicts between JVM application and j.u.l logging shutdown hooks
In-Reply-To: <52A61EDE.5030106@oracle.com>
References: 
	<52A61EDE.5030106@oracle.com>
Message-ID: 

Alan,

Thanks for creating the bug 9005822 !

As I spotted in my initial email, both shutdown hook problems (JavaWS and
JUL) are due to the concurrent execution of shutdown hooks :

com.sun.imageio.stream.StreamCloser.java
101:  Runtime.getRuntime().addShutdownHook(streamCloser);

java.util.logging.LogManager.java
255:  Runtime.getRuntime().addShutdownHook(new Cleaner());
For example, the JavaWS bug is caused by a closed jar file (unable to load
an class during shutdown) because (I guess) the StreamCloser closed all
opened jar files or JUL Streams.

As I said, these 2 important hooks (StreamCloser and jul.Cleaner) should be
executed "later" and the StreamCloser as last.
As jul.Handlers can use sockets or files, it is important to flush / close
first handlers (Cleaner) and then close any remaining opened stream ...

I think this bug should be converted into a more general shutdown hook
issue:
- execute first application hooks (not JVM ones)
- fix priorities / order between all JVM hooks (~ 20 now)

Regards,
Laurent


From mandy.chung at oracle.com  Thu Dec 12 18:29:34 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Dec 2013 10:29:34 -0800
Subject: Review request for 8021368: Launch of Java Web Start app fails with
	ClassCircularityError exception
Message-ID: <52AA008E.1000206@oracle.com>

JDK-8021368: Launch of Java Web Start app fails with 
ClassCircularityError exception in 7u25
https://bugs.openjdk.java.net/browse/JDK-8021368

This is a fix for 7u60 only.  It's a regression in 7u25 due to 
JDK-8010117 where it calls Class.getMethod to determine if the 
checkMemberAccess method is overridden in a SecurityManager subclass but 
Class.getMethod causes parameter types and returned type of other public 
methods to be resolved and hence ClassCircularityError.  It is not an 
issue in JDK 8 as SecurityManager.checkMemberAccess is deprecated and 
not called by the JDK (see JDK-8007035).

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.00/

An alternative implementation is to add a new VM entry point to look up 
the declaring class of an overridden method instead of using 
JNI_GetMethodID and get a reflective method for a faster query. Since 
this check is only performed once in most cases, this performance cost 
of using JNI is not too bad that the new VM entry point doesn't 
necessarily buy much more.

thanks
Mandy


From huizhe.wang at oracle.com  Thu Dec 12 19:37:15 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Thu, 12 Dec 2013 19:37:15 +0000
Subject: hg: jdk8/tl/jaxp: 8029895: XMLOutputFactory.newFactory(String,
	ClassLoader) - incorrect specification
Message-ID: <20131212193718.E4E7E62C4C@hg.openjdk.java.net>

Changeset: 3e5bf0372a93
Author:    joehw
Date:      2013-12-12 11:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3e5bf0372a93

8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
Reviewed-by: alanb, dfuchs, lancea

! src/javax/xml/stream/XMLOutputFactory.java



From mandy.chung at oracle.com  Thu Dec 12 23:37:31 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Dec 2013 15:37:31 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52A4C659.4020406@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
Message-ID: <52AA48BB.7010303@oracle.com>

Hi Peter,

On 12/8/2013 11:19 AM, Peter Levart wrote:
> H Mandy,
>
> I created an issue for it nevertheless:
>
> https://bugs.openjdk.java.net/browse/JDK-8029781
>
> You're right, doPrivileged() is a more straight-forward approach than 
> 'sealed' variable. Since this might only be considered for inclusion 
> in JDK9 when lambdas are already a tried technology, how do you feel 
> about using them for platform code like logging? As far as I know 
> (just checked), lambda meta-factory is not using any j.u.logging, so 
> there is no danger of initialization loops or similar:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/

Sorry for the delay to get to this.

Alan is right that java.lang.invoke.ProxyClassesDumper does use 
PlatformLogger which will forward calls to j.u.logging if 
-Djava.util.logging.config.file is set or java.util.logging has been 
initialized (via other j.u.logging call).  It means that it may lead to 
recursive initialization.  Also the current PlatformLogger 
implementation formats the message in the same way as j.u.logging that 
may load locale providers and other classes.  I am afraid there are 
issues to tease out and resolve.

The overloads the doPrivileged method makes it cumbersome to use lambda 
that causes you to workaround it by adding a new PrivilegedVoidAction 
interface which is clever.  So I think it isn't too bad for this patch 
to use anonymous inner class and have the doPrivileged call in the 
constructor.

Mandy


From lana.steuck at oracle.com  Fri Dec 13 05:17:58 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:17:58 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20131213051808.0BE3D62C8B@hg.openjdk.java.net>

Changeset: 6c152deb600d
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6c152deb600d

Added tag jdk8-b119 for changeset 172b8e056ff2

! .hgtags

Changeset: 32050ab53c8a
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/32050ab53c8a

Added tag jdk8-b120 for changeset 6c152deb600d

! .hgtags



From lana.steuck at oracle.com  Fri Dec 13 05:17:58 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:17:58 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20131213051805.32C3B62C8A@hg.openjdk.java.net>

Changeset: 7fa32e7d755f
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7fa32e7d755f

Added tag jdk8-b119 for changeset c3343930c73c

! .hgtags

Changeset: 55cbc2d00c93
Author:    lana
Date:      2013-12-05 10:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/55cbc2d00c93

Merge


Changeset: 32631eed0fad
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/32631eed0fad

Added tag jdk8-b120 for changeset 55cbc2d00c93

! .hgtags

Changeset: 0225a7ca37ab
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0225a7ca37ab

Merge




From lana.steuck at oracle.com  Fri Dec 13 05:17:58 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:17:58 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20131213051814.46E5062C8C@hg.openjdk.java.net>

Changeset: 9b4fac40124d
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9b4fac40124d

Added tag jdk8-b119 for changeset 69a930376c70

! .hgtags

Changeset: 64d8b228a72c
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/64d8b228a72c

Merge


Changeset: 4045edd35e8b
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4045edd35e8b

Added tag jdk8-b120 for changeset 64d8b228a72c

! .hgtags

Changeset: 9c7e3a68dc77
Author:    lana
Date:      2013-12-12 19:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9c7e3a68dc77

Merge




From lana.steuck at oracle.com  Fri Dec 13 05:18:09 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:18:09 +0000
Subject: hg: jdk8/tl/langtools: 4 new changesets
Message-ID: <20131213051832.7B8B062C8D@hg.openjdk.java.net>

Changeset: 1670108bec25
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1670108bec25

Added tag jdk8-b119 for changeset 43a80d75d06e

! .hgtags

Changeset: b3d7e86a0647
Author:    lana
Date:      2013-12-05 10:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b3d7e86a0647

Merge


Changeset: afe63d41c699
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afe63d41c699

Added tag jdk8-b120 for changeset b3d7e86a0647

! .hgtags

Changeset: d80c3d6f4f05
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d80c3d6f4f05

Merge




From lana.steuck at oracle.com  Fri Dec 13 05:18:19 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:18:19 +0000
Subject: hg: jdk8/tl/hotspot: 22 new changesets
Message-ID: <20131213051916.2385D62C8E@hg.openjdk.java.net>

Changeset: a3dc98dc4d21
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3dc98dc4d21

Added tag jdk8-b119 for changeset ce42d815dd21

! .hgtags

Changeset: b6b9a5d4cda0
Author:    amurillo
Date:      2013-11-29 11:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6b9a5d4cda0

8029367: new hotspot build - hs25-b62
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 77b028ba548c
Author:    jprovino
Date:      2013-11-19 16:26 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77b028ba548c

8028396: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE
Summary: Minimal VM doesn't run
Reviewed-by: coleenp, dholmes

! src/share/vm/prims/jvmtiImpl.hpp

Changeset: 3fbb71fdc6e5
Author:    vladidan
Date:      2013-12-01 22:35 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3fbb71fdc6e5

Merge


Changeset: 8a42e81e2f9d
Author:    dsamersoff
Date:      2013-11-27 14:26 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a42e81e2f9d

7050685: jsdbproc64.sh has a typo in the package name
Summary: fixed typeo
Reviewed-by: sla, kmo, sspitsyn

! agent/make/jsdbproc64.sh

Changeset: 6ce6a0d23467
Author:    mgronlun
Date:      2013-12-02 11:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ce6a0d23467

Merge

- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 7a58803b5069
Author:    acorn
Date:      2013-12-03 08:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a58803b5069

8026066: ICCE for invokeinterface static
Reviewed-by: coleenp, lfoltan, hseigel

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! test/TEST.groups
! test/runtime/8024804/RegisterNatives.java

Changeset: 379f11bc04fc
Author:    acorn
Date:      2013-12-03 11:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/379f11bc04fc

8028438: static superclass method masks default methods
Reviewed-by: hseigel, lfoltan, coleenp

! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klassVtable.cpp

Changeset: c8c2d6b82499
Author:    sspitsyn
Date:      2013-12-03 15:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8c2d6b82499

8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers
Summary: Fix a race between VMOp_GetCurrentLocation reaching a safepoint and arget thread exiting from Java execution
Reviewed-by: sla, dholmes, dsamersoff
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiEnvThreadState.cpp

Changeset: e84d2afb2fb0
Author:    sspitsyn
Date:      2013-12-03 13:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e84d2afb2fb0

Merge


Changeset: 55a0da3d420b
Author:    sjohanss
Date:      2013-11-26 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55a0da3d420b

8027675: Full collections with Serial slower in JDK 8 compared to 7u40
Summary: Reduced the number of calls to follow_class_loader and instead marked and pushed the klass holder directly. Also removed unneeded calls to adjust_klass.
Reviewed-by: coleenp, jmasa, mgerdin, tschatzl

! 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/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp

Changeset: 9fc985481d78
Author:    ehelin
Date:      2013-12-02 15:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9fc985481d78

Merge

! src/share/vm/oops/instanceKlass.cpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 50287b659eb8
Author:    sjohanss
Date:      2013-12-03 12:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50287b659eb8

8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder
Summary: Now iterating over all committed (used) G1 regions instead of all reserved.
Reviewed-by: brutisso, dsamersoff, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java
! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java

Changeset: 816c89d5957d
Author:    ehelin
Date:      2013-12-05 17:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/816c89d5957d

Merge

! src/share/vm/oops/instanceKlass.cpp

Changeset: 9949533a8623
Author:    rbackman
Date:      2013-11-22 14:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9949533a8623

8028997: mathexact intrinsics are unstable
Reviewed-by: iveresov, kvn

! src/share/vm/opto/c2_globals.hpp
! test/compiler/intrinsics/mathexact/AddExactICondTest.java
! test/compiler/intrinsics/mathexact/AddExactIConstantTest.java
! test/compiler/intrinsics/mathexact/AddExactILoadTest.java
! test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java
! test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java
! test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java
! test/compiler/intrinsics/mathexact/AddExactLConstantTest.java
! test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java
! test/compiler/intrinsics/mathexact/CompareTest.java
! test/compiler/intrinsics/mathexact/DecExactITest.java
! test/compiler/intrinsics/mathexact/DecExactLTest.java
! test/compiler/intrinsics/mathexact/GVNTest.java
! test/compiler/intrinsics/mathexact/IncExactITest.java
! test/compiler/intrinsics/mathexact/IncExactLTest.java
! test/compiler/intrinsics/mathexact/MulExactICondTest.java
! test/compiler/intrinsics/mathexact/MulExactIConstantTest.java
! test/compiler/intrinsics/mathexact/MulExactILoadTest.java
! test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java
! test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java
! test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java
! test/compiler/intrinsics/mathexact/MulExactLConstantTest.java
! test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java
! test/compiler/intrinsics/mathexact/NegExactIConstantTest.java
! test/compiler/intrinsics/mathexact/NegExactILoadTest.java
! test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java
! test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java
! test/compiler/intrinsics/mathexact/NegExactLConstantTest.java
! test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java
! test/compiler/intrinsics/mathexact/NestedMathExactTest.java
! test/compiler/intrinsics/mathexact/SplitThruPhiTest.java
! test/compiler/intrinsics/mathexact/SubExactICondTest.java
! test/compiler/intrinsics/mathexact/SubExactIConstantTest.java
! test/compiler/intrinsics/mathexact/SubExactILoadTest.java
! test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java
! test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java
! test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java
! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java
! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java

Changeset: 55dd6e77b399
Author:    rbackman
Date:      2013-11-22 15:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55dd6e77b399

8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest
Reviewed-by: kvn, twisti

! test/compiler/intrinsics/mathexact/DecExactLTest.java

Changeset: eae426d683f6
Author:    simonis
Date:      2013-12-02 11:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eae426d683f6

8029190: VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs
Summary: fix code to allow testing on Fujitsu Sparc64 CPUs
Reviewed-by: kvn

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 61746b5f0ed3
Author:    anoll
Date:      2013-12-04 09:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61746b5f0ed3

8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline
Summary: Use non-relocatable code to load byte_map_base
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp

Changeset: 6a8941dbd26f
Author:    anoll
Date:      2013-12-05 12:49 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a8941dbd26f

Merge


Changeset: 05fedd51e40d
Author:    amurillo
Date:      2013-12-06 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05fedd51e40d

Merge


Changeset: fca262db9c43
Author:    amurillo
Date:      2013-12-06 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fca262db9c43

Added tag hs25-b62 for changeset 05fedd51e40d

! .hgtags

Changeset: ce2d7e46f3c7
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce2d7e46f3c7

Added tag jdk8-b120 for changeset fca262db9c43

! .hgtags



From lana.steuck at oracle.com  Fri Dec 13 05:19:48 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:19:48 +0000
Subject: hg: jdk8/tl/jdk: 19 new changesets
Message-ID: <20131213052355.2A87662C8F@hg.openjdk.java.net>

Changeset: 92ce9338bec4
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92ce9338bec4

Added tag jdk8-b119 for changeset e4499a6529e8

! .hgtags

Changeset: d30a92b7a0b5
Author:    prr
Date:      2013-12-03 09:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30a92b7a0b5

8029204: Printing a GlyphVector on Windows ignores position of first glyph
Reviewed-by: jgodinez, bae

! src/windows/classes/sun/awt/windows/WPathGraphics.java
+ test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java

Changeset: b6bd334ebc4e
Author:    lana
Date:      2013-12-03 17:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6bd334ebc4e

Merge

- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- 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/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- 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/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- 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/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml
- test/javax/xml/jaxp/transform/jdk8004476/TestBase.java
- test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher

Changeset: ddf4d1c3385d
Author:    lana
Date:      2013-12-05 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddf4d1c3385d

Merge


Changeset: 3aab01f03bb7
Author:    pchelko
Date:      2013-11-29 11:08 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3aab01f03bb7

7152982: [TEST_BUG][macosx] Extremely unstable mouse modifiers test
Reviewed-by: anthony, serb

! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java

Changeset: abfde064573b
Author:    serb
Date:      2013-11-29 16:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abfde064573b

8029010: [macosx] Need test for JDK-7124513
Reviewed-by: pchelko, alexsch

+ test/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java

Changeset: 4f6ea4c78627
Author:    pchelko
Date:      2013-11-29 16:43 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f6ea4c78627

7178682: [TEST_BUG][macosx] Mouse Pressed event can't be monitored for DisabledComponentsTest.html.
Reviewed-by: anthony, serb

+ test/java/awt/event/MouseEvent/DisabledComponents/DisabledComponentsTest.java

Changeset: e4bdf647215f
Author:    yan
Date:      2013-12-03 15:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4bdf647215f

8023576: [TEST BUG] Compilation fails for java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
Reviewed-by: anthony, serb
Contributed-by: Andrei Eremeev 

! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java

Changeset: 776024b3f13d
Author:    pchelko
Date:      2013-12-03 15:31 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/776024b3f13d

8029251: [TEST_BUG][macosx] Use safari browser, the ouput contain information that DataFlavor.allHtmlFlavor is not present in the system clipboard
Reviewed-by: anthony, serb

! test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java

Changeset: 5774800ba1e9
Author:    pchelko
Date:      2013-12-03 19:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5774800ba1e9

7124391: [TEST_BUG][macosx] MouseEvents are not dispatched when the mouse cursor leaves the component
Reviewed-by: anthony, serb

+ test/java/awt/event/MouseEvent/EnterAsGrabbedEvent/EnterAsGrabbedEvent.java

Changeset: e9cd2dfd545f
Author:    lana
Date:      2013-12-03 15:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9cd2dfd545f

Merge

- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- 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/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- 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/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- 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/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml
- test/javax/xml/jaxp/transform/jdk8004476/TestBase.java
- test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml
- test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher

Changeset: 233cc95e1a0a
Author:    alitvinov
Date:      2013-12-04 12:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/233cc95e1a0a

8025775: JNI warnings in TryXShmAttach
Reviewed-by: art, anthony

! src/solaris/classes/sun/awt/X11/XConstants.java
! src/solaris/classes/sun/awt/X11/XErrorHandler.java
! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.h
! src/solaris/native/sun/awt/awt_util.c
! src/solaris/native/sun/awt/awt_util.h
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c
! src/solaris/native/sun/xawt/XlibWrapper.c

Changeset: 1490b2b2af97
Author:    pchelko
Date:      2013-12-04 15:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1490b2b2af97

8028484: [TEST_BUG][macosx] closed/java/awt/MouseInfo/JContainerMousePositionTest fails
Reviewed-by: anthony, serb

+ test/java/awt/MouseInfo/JContainerMousePositionTest.java

Changeset: 613fdc6afb2c
Author:    serb
Date:      2013-12-04 15:55 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/613fdc6afb2c

8029382: [macosx] Need test for JDK-7161437
Reviewed-by: pchelko, anthony

+ test/java/awt/FileDialog/FileDialogForDirectories/FileDialogForDirectories.html
+ test/java/awt/FileDialog/FileDialogForDirectories/FileDialogForDirectories.java

Changeset: 68a64d582d1a
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68a64d582d1a

Merge


Changeset: 7ecaa4402c4e
Author:    lana
Date:      2013-12-05 10:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ecaa4402c4e

Merge

- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED
- test/com/sun/jmx/snmp/NoInfoLeakTest.java
- test/com/sun/tools/attach/AgentSetup.sh
- test/com/sun/tools/attach/ApplicationSetup.sh
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
- test/com/sun/tools/attach/PermissionTests.sh
- test/com/sun/tools/attach/ProviderTests.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh

Changeset: d31cd980e1da
Author:    rgallard
Date:      2013-12-10 15:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d31cd980e1da

8029616: Update jdeps man page to include a new -jdkinternals option
Reviewed-by: mchung

! src/bsd/doc/man/jdeps.1
! src/linux/doc/man/jdeps.1
! src/solaris/doc/sun/man/man1/jdeps.1

Changeset: 27b384262cba
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27b384262cba

Added tag jdk8-b120 for changeset d31cd980e1da

! .hgtags

Changeset: 23b89bd740e9
Author:    lana
Date:      2013-12-12 19:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23b89bd740e9

Merge




From paul.sandoz at oracle.com  Fri Dec 13 08:49:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Dec 2013 09:49:05 +0100
Subject: RFR: 8030016: HashMap.computeIfAbsent generates spurious access
	event
In-Reply-To: 
References: 
Message-ID: <3F9D6E3F-E726-4C99-A021-35632444A4D7@oracle.com>


On Dec 12, 2013, at 6:24 AM, Mike Duigou  wrote:

> Hello all;
> 
> In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects that behaviour.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/
> 
> The actual regression test is LinkedHashMap/ComputeIfAbsentAccessOrder.java whereas the changes to Map/Defaults are improvements to the existing tests suggested by this bug (though they would not detect it).
> 

Looks OK to me.

I believe that fits better within the strange world of an existing entry considered absent if its value is null i.e. no side-effects if the entry is absent and mapping function returns null.

Paul.

From lana.steuck at oracle.com  Fri Dec 13 05:17:58 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:17:58 +0000
Subject: hg: jdk8/tl: 4 new changesets
Message-ID: <20131213051759.0C17762C87@hg.openjdk.java.net>

Changeset: 6c9cfee19264
Author:    katleman
Date:      2013-12-04 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/6c9cfee19264

Added tag jdk8-b119 for changeset 9e90215673be

! .hgtags

Changeset: f204455b60cc
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f204455b60cc

Merge


Changeset: cd3825b29830
Author:    ihse
Date:      2013-12-09 14:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/cd3825b29830

8029515: Building multiple configurations fails after removal of old build system
Reviewed-by: erikj

! Makefile
! make/MakeHelpers.gmk

Changeset: 1e1f86d5d4e2
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/1e1f86d5d4e2

Added tag jdk8-b120 for changeset cd3825b29830

! .hgtags



From lana.steuck at oracle.com  Fri Dec 13 05:17:55 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:17:55 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20131213051758.D6A0262C86@hg.openjdk.java.net>

Changeset: 53fd772d28c8
Author:    katleman
Date:      2013-12-04 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/53fd772d28c8

Added tag jdk8-b119 for changeset 379fc7609beb

! .hgtags

Changeset: a7d3638deb2f
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/a7d3638deb2f

Added tag jdk8-b120 for changeset 53fd772d28c8

! .hgtags



From Alan.Bateman at oracle.com  Fri Dec 13 12:00:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Dec 2013 12:00:36 +0000
Subject: Conflicts between JVM application and j.u.l logging shutdown hooks
In-Reply-To: 
References: 
	<52A61EDE.5030106@oracle.com>
	
Message-ID: <52AAF6E4.2080202@oracle.com>

On 12/12/2013 17:38, Laurent Bourg?s wrote:
> Alan,
>
> Thanks for creating the bug 9005822 !
The logging bug we created is JDK-8029834


> :
>
> I think this bug should be converted into a more general shutdown hook 
> issue:
> - execute first application hooks (not JVM ones)
> - fix priorities / order between all JVM hooks (~ 20 now)
>
The existing shutdown hooks already provide lots of rope to hang 
yourself and so I think any proposal to expose priorities in the API 
would need to be approached with great care. As you have found, the JDK 
internally can run hooks before or after the application hooks but given 
the delicate time when they run then great care also needs to be taken 
when doing any adjustments there too.

In any case, the LogManager shutdown hook does need to be looked at as 
it clearly has a number of issues.

-Alan.






From vicente.romero at oracle.com  Fri Dec 13 14:16:08 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 13 Dec 2013 14:16:08 +0000
Subject: hg: jdk8/tl/langtools: 8029721: javac crash for annotated parameter
	type of lambda in a field
Message-ID: <20131213141613.8939E62CC0@hg.openjdk.java.net>

Changeset: 8832b6048e65
Author:    vromero
Date:      2013-12-13 14:13 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8832b6048e65

8029721: javac crash for annotated parameter type of lambda in a field
Reviewed-by: rfield, jfranck

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java
! test/tools/javac/lambda/LambdaScope05.out



From Alan.Bateman at oracle.com  Fri Dec 13 15:07:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Dec 2013 15:07:40 +0000
Subject: Review request for 8021368: Launch of Java Web Start app fails
	with ClassCircularityError exception
In-Reply-To: <52AA008E.1000206@oracle.com>
References: <52AA008E.1000206@oracle.com>
Message-ID: <52AB22BC.4050601@oracle.com>

On 12/12/2013 18:29, Mandy Chung wrote:
> JDK-8021368: Launch of Java Web Start app fails with 
> ClassCircularityError exception in 7u25
> https://bugs.openjdk.java.net/browse/JDK-8021368
>
> This is a fix for 7u60 only.  It's a regression in 7u25 due to 
> JDK-8010117 where it calls Class.getMethod to determine if the 
> checkMemberAccess method is overridden in a SecurityManager subclass 
> but Class.getMethod causes parameter types and returned type of other 
> public methods to be resolved and hence ClassCircularityError.  It is 
> not an issue in JDK 8 as SecurityManager.checkMemberAccess is 
> deprecated and not called by the JDK (see JDK-8007035).
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.00/
>
> An alternative implementation is to add a new VM entry point to look 
> up the declaring class of an overridden method instead of using 
> JNI_GetMethodID and get a reflective method for a faster query. Since 
> this check is only performed once in most cases, this performance cost 
> of using JNI is not too bad that the new VM entry point doesn't 
> necessarily buy much more.

I looked at changes and the approach seems okay to me (at least I can't 
of other ways to check for the override without also tickling the issue. 
I think you are right that a special entry point for this is excessive 
given that the result can be cached.

A minor point on the SecurityManagerHelper constructor, shouldn't it be:

boolean overridden = false;
if (smgr.getClass() != SecurityManager.class) {
     try { overridden = ... }
}

A minor comment on naming where "cache" seems a bit general given that 
Class has several caches (I know useCaches is general too). Also I see 
the new code is using "smgr" whereas everywhere every seems to be using 
"sm", "security" or other.

-Alan.


From mandy.chung at oracle.com  Fri Dec 13 16:20:09 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Dec 2013 08:20:09 -0800
Subject: Review request for 8021368: Launch of Java Web Start app fails
	with ClassCircularityError exception
In-Reply-To: <52AB22BC.4050601@oracle.com>
References: <52AA008E.1000206@oracle.com> <52AB22BC.4050601@oracle.com>
Message-ID: <52AB33B9.3030205@oracle.com>

Alan.

Thanks for the review.

On 12/13/2013 7:07 AM, Alan Bateman wrote:
> I looked at changes and the approach seems okay to me (at least I 
> can't of other ways to check for the override without also tickling 
> the issue. I think you are right that a special entry point for this 
> is excessive given that the result can be cached.
>
> A minor point on the SecurityManagerHelper constructor, shouldn't it be:
>
> boolean overridden = false;
> if (smgr.getClass() != SecurityManager.class) {
>     try { overridden = ... }
> }
>

yes that's better.  While SecurityManagerHelper should only be 
constructed when smgr is a subclass, I'll make the change.

> A minor comment on naming where "cache" seems a bit general given that 
> Class has several caches (I know useCaches is general too). Also I see 
> the new code is using "smgr" whereas everywhere every seems to be 
> using "sm", "security" or other.
>

Agree the name is too general.  Will rename it.

Mandy



From brent.christian at oracle.com  Fri Dec 13 18:06:58 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 13 Dec 2013 10:06:58 -0800
Subject: RFR: 8030016: HashMap.computeIfAbsent generates spurious access
	event
In-Reply-To: 
References: 
Message-ID: <52AB4CC2.4080707@oracle.com>

On 12/11/13 9:24 PM, Mike Duigou wrote:
> Hello all;
>
> In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects that behaviour.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/
>
> The actual regression test is LinkedHashMap/ComputeIfAbsentAccessOrder.java whereas the changes to Map/Defaults are improvements to the existing tests suggested by this bug (though they would not detect it).
>

The changes look fine to me.

-Brent


From mike.duigou at oracle.com  Sat Dec 14 00:16:46 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 14 Dec 2013 00:16:46 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131214001728.9D16662CDB@hg.openjdk.java.net>

Changeset: a7ed72627c3f
Author:    mduigou
Date:      2013-12-13 13:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ed72627c3f

8029055: Map.merge implementations should refuse null value param
Reviewed-by: briangoetz, dl

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! test/java/util/Map/Defaults.java

Changeset: 26028cb56c68
Author:    mduigou
Date:      2013-12-13 13:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26028cb56c68

8030016: HashMap.computeIfAbsent generates spurious access event
Reviewed-by: psandoz, bchristi

! src/share/classes/java/util/HashMap.java
+ test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java
! test/java/util/Map/Defaults.java



From brian.burkhalter at oracle.com  Sat Dec 14 00:19:34 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Dec 2013 16:19:34 -0800
Subject: RFR: JDK 9: 4891331: BigInteger a.multiply(a) should use squaring code
Message-ID: <52D680DF-1239-4ADF-8B77-BFFECAE58F17@oracle.com>

The patch in questions was already approved in this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023611.html

so unless there are objections I shall push it to the new Java 9 repository.

Thanks,

Brian

From mike.duigou at oracle.com  Sat Dec 14 00:42:16 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Dec 2013 16:42:16 -0800
Subject: RFR: 8030016 & 8029055: (forward ports to jdk 9)
Message-ID: <443D4389-ED0E-400A-8894-690ABF2D5B61@oracle.com>

Hello all;

These two changesets were committed to JDK 8 forest. I wish to commit the same changes to JDK 9.

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26028cb56c68
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ed72627c3f

Mike

From mike.duigou at oracle.com  Sat Dec 14 00:47:19 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Dec 2013 16:47:19 -0800
Subject: RFR: JDK 9: 4891331: BigInteger a.multiply(a) should use squaring
	code
In-Reply-To: <52D680DF-1239-4ADF-8B77-BFFECAE58F17@oracle.com>
References: <52D680DF-1239-4ADF-8B77-BFFECAE58F17@oracle.com>
Message-ID: 

If the changeset is the same, which it should be, then proceed.

Mike

On Dec 13 2013, at 16:19 , Brian Burkhalter  wrote:

> The patch in questions was already approved in this thread
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023611.html
> 
> so unless there are objections I shall push it to the new Java 9 repository.
> 
> Thanks,
> 
> Brian



From joe.darcy at oracle.com  Sat Dec 14 00:57:58 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 13 Dec 2013 16:57:58 -0800
Subject: RFR: JDK 9: 4891331: BigInteger a.multiply(a) should use squaring
	code
In-Reply-To: <52D680DF-1239-4ADF-8B77-BFFECAE58F17@oracle.com>
References: <52D680DF-1239-4ADF-8B77-BFFECAE58F17@oracle.com>
Message-ID: <52ABAD16.4040403@oracle.com>

Sound good to me :-)

Thanks

-Joe

On 12/13/2013 4:19 PM, Brian Burkhalter wrote:
> The patch in questions was already approved in this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023611.html
>
> so unless there are objections I shall push it to the new Java 9 repository.
>
> Thanks,
>
> Brian



From stuart.marks at oracle.com  Sat Dec 14 02:19:28 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Sat, 14 Dec 2013 02:19:28 +0000
Subject: hg: jdk8/tl/jdk: 8027536: rmic: add deprecation warning message when
	generating JRMP static stubs/skeletons
Message-ID: <20131214021944.A819D62CDF@hg.openjdk.java.net>

Changeset: 6c343d3d2721
Author:    smarks
Date:      2013-12-13 18:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c343d3d2721

8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons
Reviewed-by: mchung, dmocek

! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/resources/rmic.properties



From peter.levart at gmail.com  Sat Dec 14 11:25:15 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Dec 2013 12:25:15 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AA48BB.7010303@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com>
Message-ID: <52AC401B.1010405@gmail.com>

Hi Mandy,

On 12/13/2013 12:37 AM, Mandy Chung wrote:
> Hi Peter,
>
> On 12/8/2013 11:19 AM, Peter Levart wrote:
>> H Mandy,
>>
>> I created an issue for it nevertheless:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>
>> You're right, doPrivileged() is a more straight-forward approach than 
>> 'sealed' variable. Since this might only be considered for inclusion 
>> in JDK9 when lambdas are already a tried technology, how do you feel 
>> about using them for platform code like logging? As far as I know 
>> (just checked), lambda meta-factory is not using any j.u.logging, so 
>> there is no danger of initialization loops or similar:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>
>
> Sorry for the delay to get to this.

No rush. We have time before JDK9 gets set-up and running...

>
> Alan is right that java.lang.invoke.ProxyClassesDumper does use 
> PlatformLogger which will forward calls to j.u.logging if 
> -Djava.util.logging.config.file is set or java.util.logging has been 
> initialized (via other j.u.logging call).  It means that it may lead 
> to recursive initialization.  Also the current PlatformLogger 
> implementation formats the message in the same way as j.u.logging that 
> may load locale providers and other classes. I am afraid there are 
> issues to tease out and resolve.

It's unfortunate that a lambda debugging feature prevents us from using 
a basic language feature in j.u.logging code. As far as I know, 
java.lang.invoke.ProxyClassesDumper is only used if 
'jdk.internal.lambda.dumpProxyClasses' system property is set to point 
to a directory where lambda proxy class files are to be dumped as they 
are generated - a debugging hook therefore. Wouldn't it be good-enough 
if error messages about not-being able to set-up/use the dump facility 
were output to System.err directly - not using PlatformLogger at all?

>
> The overloads the doPrivileged method makes it cumbersome to use 
> lambda that causes you to workaround it by adding a new 
> PrivilegedVoidAction interface which is clever.  So I think it isn't 
> too bad for this patch to use anonymous inner class and have the 
> doPrivileged call in the constructor.

Right. I have prepared a modified webrev which doesn't use lambdas:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/

In attempt to minimize the boilerplate, I haven't just replaced lambdas 
with anonymous inner classes, but rather turned all private configure() 
methods into ConfigureAction inner classes. In two occasions 
(SocketHandler and StreamHandler), they are extended with anonymous 
inner classes to append some actions. In SocketHandler I kept the 
mechanics of transporting the checked IOException out of 
PrivilegedAction by wrapping it with Unchecked IOException and later 
unwrapping and throwing it, rather than using PrivilegedExceptionAction 
which would further complicate exception handling, since it declares 
throwing a general j.l.Exception, but the SocketHandler constructor only 
declares throwing IOException...

I think this could be backported to 7u as-is.

Regards, Peter

>
>
> Mandy



From peter.levart at gmail.com  Sat Dec 14 14:09:07 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Dec 2013 15:09:07 +0100
Subject: Review request for 8021368: Launch of Java Web Start app fails
	with ClassCircularityError exception
In-Reply-To: <52AA008E.1000206@oracle.com>
References: <52AA008E.1000206@oracle.com>
Message-ID: <52AC6683.3020107@gmail.com>


On 12/12/2013 07:29 PM, Mandy Chung wrote:
> JDK-8021368: Launch of Java Web Start app fails with 
> ClassCircularityError exception in 7u25
> https://bugs.openjdk.java.net/browse/JDK-8021368
>
> This is a fix for 7u60 only.  It's a regression in 7u25 due to 
> JDK-8010117 where it calls Class.getMethod to determine if the 
> checkMemberAccess method is overridden in a SecurityManager subclass 
> but Class.getMethod causes parameter types and returned type of other 
> public methods to be resolved and hence ClassCircularityError.  It is 
> not an issue in JDK 8 as SecurityManager.checkMemberAccess is 
> deprecated and not called by the JDK (see JDK-8007035).
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.00/
>
> An alternative implementation is to add a new VM entry point to look 
> up the declaring class of an overridden method instead of using 
> JNI_GetMethodID and get a reflective method for a faster query. Since 
> this check is only performed once in most cases, this performance cost 
> of using JNI is not too bad that the new VM entry point doesn't 
> necessarily buy much more.
>
> thanks
> Mandy

Hi Mandy,

I tried the following:


public class Test {

     static class A {}

     static class B {}

     static class X {
         public void x() { }
     }

     static class Y extends X {
         public A a(B b) { return null; }
         public B b(A a) { return null; }
         public void x() { }
     }

     public static void main(String[] args) throws Exception {
         MethodHandles.Lookup lookup = MethodHandles.lookup();
         MethodHandle mh = lookup.findVirtual(Y.class, "x", 
MethodType.methodType(void.class, new Class[0]));
         MethodHandleInfo mhi = lookup.revealDirect(mh);
         System.out.println(mhi.getDeclaringClass() == Y.class);
     }
}


The above code does not trigger loading of classes A or B. But 
unfortunately it prints true even if I comment-out the declaration of 
method Y.x(). I don't know if this is a bug though. I should ask on the 
mlvm-dev list...

Anyway, your approach seems more appropriate as it doesn't depend on 
method handles and their peculiarities...

Some nits:

2241      * Finds the checkMemberAccess method of the given SecurityManager*instance*.


...I think it should read "...of the given SecurityManager*class*." instead, since the method parameter is of type Class.


2210     private static class SecurityManagerHelper {
2211         private final SecurityManager smgr;
2212         private final boolean overrideCheckMemberAccess;


...the fields could be declared package-private so that no synthetic access methods are generated...


Regards, Peter



From peter.levart at gmail.com  Sat Dec 14 17:38:55 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Dec 2013 18:38:55 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AC401B.1010405@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
Message-ID: <52AC97AF.4050403@gmail.com>

Hi,

Daniel reminded me of a couple of issues the 4th revision of the patch 
would have when backporting to 7u. So here's another variant that tries 
to be more backport-friendly:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/

This variant could be backported by simply replacing a limited variant 
of doPrivileged (introduced in JDK 8) with full variant and still not 
elevate the privilege of Socket creation in SocketHandler. I also 
removed the need to subclass various ConfigureAction(s) with annonymous 
inner subclasses by introducing overloaded constructors to 
ConfigureActions(s) that follow the overloaded constructors of various 
Handlers.

Regards, Peter

On 12/14/2013 12:25 PM, Peter Levart wrote:
> Hi Mandy,
>
> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>> Hi Peter,
>>
>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>> H Mandy,
>>>
>>> I created an issue for it nevertheless:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>
>>> You're right, doPrivileged() is a more straight-forward approach 
>>> than 'sealed' variable. Since this might only be considered for 
>>> inclusion in JDK9 when lambdas are already a tried technology, how 
>>> do you feel about using them for platform code like logging? As far 
>>> as I know (just checked), lambda meta-factory is not using any 
>>> j.u.logging, so there is no danger of initialization loops or similar:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>>
>>
>> Sorry for the delay to get to this.
>
> No rush. We have time before JDK9 gets set-up and running...
>
>>
>> Alan is right that java.lang.invoke.ProxyClassesDumper does use 
>> PlatformLogger which will forward calls to j.u.logging if 
>> -Djava.util.logging.config.file is set or java.util.logging has been 
>> initialized (via other j.u.logging call).  It means that it may lead 
>> to recursive initialization.  Also the current PlatformLogger 
>> implementation formats the message in the same way as j.u.logging 
>> that may load locale providers and other classes.  I am afraid there 
>> are issues to tease out and resolve.
>
> It's unfortunate that a lambda debugging feature prevents us from 
> using a basic language feature in j.u.logging code. As far as I know, 
> java.lang.invoke.ProxyClassesDumper is only used if 
> 'jdk.internal.lambda.dumpProxyClasses' system property is set to point 
> to a directory where lambda proxy class files are to be dumped as they 
> are generated - a debugging hook therefore. Wouldn't it be good-enough 
> if error messages about not-being able to set-up/use the dump facility 
> were output to System.err directly - not using PlatformLogger at all?
>
>>
>> The overloads the doPrivileged method makes it cumbersome to use 
>> lambda that causes you to workaround it by adding a new 
>> PrivilegedVoidAction interface which is clever.  So I think it isn't 
>> too bad for this patch to use anonymous inner class and have the 
>> doPrivileged call in the constructor.
>
> Right. I have prepared a modified webrev which doesn't use lambdas:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>
> In attempt to minimize the boilerplate, I haven't just replaced 
> lambdas with anonymous inner classes, but rather turned all private 
> configure() methods into ConfigureAction inner classes. In two 
> occasions (SocketHandler and StreamHandler), they are extended with 
> anonymous inner classes to append some actions. In SocketHandler I 
> kept the mechanics of transporting the checked IOException out of 
> PrivilegedAction by wrapping it with Unchecked IOException and later 
> unwrapping and throwing it, rather than using 
> PrivilegedExceptionAction which would further complicate exception 
> handling, since it declares throwing a general j.l.Exception, but the 
> SocketHandler constructor only declares throwing IOException...
>
> I think this could be backported to 7u as-is.
>
> Regards, Peter
>
>>
>>
>> Mandy
>



From joe.darcy at oracle.com  Sat Dec 14 19:02:19 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 14 Dec 2013 11:02:19 -0800
Subject: RFR: 8030016 & 8029055: (forward ports to jdk 9)
In-Reply-To: <443D4389-ED0E-400A-8894-690ABF2D5B61@oracle.com>
References: <443D4389-ED0E-400A-8894-690ABF2D5B61@oracle.com>
Message-ID: <52ACAB3B.7030907@oracle.com>

On 12/13/2013 04:42 PM, Mike Duigou wrote:
> Hello all;
>
> These two changesets were committed to JDK 8 forest. I wish to commit the same changes to JDK 9.
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26028cb56c68
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ed72627c3f
>
> Mike

Looks fine Mike.

As a general point, if a changeset has been approved for JDK 8, I think 
it would be reasonable to also treat it as approved for 9 as long as the 
patch applies cleanly.

-Joe


From mandy.chung at oracle.com  Sun Dec 15 01:02:16 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 14 Dec 2013 17:02:16 -0800
Subject: Review request for 8021368: Launch of Java Web Start app fails
	with ClassCircularityError exception
In-Reply-To: <52AC6683.3020107@gmail.com>
References: <52AA008E.1000206@oracle.com> <52AC6683.3020107@gmail.com>
Message-ID: <52ACFF98.8070509@oracle.com>

Hi Peter,

Thanks for the review.   This code path is critical in this core 
reflection implementation and I want to resolve this bug with a low risk 
fix in an update release and thus the proposed fix.   Thanks for the 
experiment with MethodHandles and finding out the pecularity.   As a 
side note, I really look forward to the reflective method call being 
reimplemented with method handles (great to see your prototype).

I have incorporated Alan's and your comment.   Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.01/

Mandy

On 12/14/2013 6:09 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> I tried the following:
>
>
> public class Test {
>
>     static class A {}
>
>     static class B {}
>
>     static class X {
>         public void x() { }
>     }
>
>     static class Y extends X {
>         public A a(B b) { return null; }
>         public B b(A a) { return null; }
>         public void x() { }
>     }
>
>     public static void main(String[] args) throws Exception {
>         MethodHandles.Lookup lookup = MethodHandles.lookup();
>         MethodHandle mh = lookup.findVirtual(Y.class, "x", 
> MethodType.methodType(void.class, new Class[0]));
>         MethodHandleInfo mhi = lookup.revealDirect(mh);
>         System.out.println(mhi.getDeclaringClass() == Y.class);
>     }
> }
>
>
> The above code does not trigger loading of classes A or B. But 
> unfortunately it prints true even if I comment-out the declaration of 
> method Y.x(). I don't know if this is a bug though. I should ask on 
> the mlvm-dev list...
>
> Anyway, your approach seems more appropriate as it doesn't depend on 
> method handles and their peculiarities...
>
> Some nits:
>
> 2241      * Finds the checkMemberAccess method of the given SecurityManager*instance*.
>
>
> ...I think it should read "...of the given SecurityManager*class*." instead, since the method parameter is of type Class.
>
>
> 2210     private static class SecurityManagerHelper {
> 2211         private final SecurityManager smgr;
> 2212         private final boolean overrideCheckMemberAccess;
>
>
> ...the fields could be declared package-private so that no synthetic access methods are generated...
>
> Regards, Peter
>



From francis.andre.kampbell at orange.fr  Sun Dec 15 08:20:12 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Sun, 15 Dec 2013 09:20:12 +0100
Subject: [8] WXP minor fixes for a cleaner compile of c code
In-Reply-To: <52A8DDC6.8080403@oracle.com>
References: <52A35FA1.8080802@orange.fr> <52A80759.6030305@orange.fr>
	<0FE6431B-8C3D-4B41-9ED6-63B7590BC575@oracle.com>
	<52A8DDC6.8080403@oracle.com>
Message-ID: <52AD663C.4060806@orange.fr>

Hi Mandy

Thanks for the sponsoring.... I have other warnings to suppress and will let you 
know.

Francis

Le 11/12/2013 22:48, Mandy Chung a ?crit :
> I have filed https://bugs.openjdk.java.net/browse/JDK-8030010 to clean up 
> these warning and I can sponsor it.
>
> Mandy
>
> On 12/10/2013 11:17 PM, Staffan Larsen wrote:
>> I see you were directed here from the build-dev list. Unfortunately these are 
>> core library fixes, not hotspot fixes. I?ve added core-libs and bcc:d 
>> hotspot-dev.
>>
>> Thanks,
>> /Staffan
>>
>> On 11 dec 2013, at 07:34, Francis ANDRE  
>> wrote:
>>
>>> Hi
>>>
>>> Below are some warnings produced by the build of jdk8.
>>>
>>> Z:/JDK/jdk8/jdk/src/share/native/java/lang/Throwable.c(48) : warning C4028:
>>> param?tre formel 3 diff?rent de la d?claration
>>> Z:/JDK/jdk8/jdk/src/windows/native/java/io/WinNTFileSystem_md.c(363) : warning
>>> C4101: 'pathlen': variable locale non r?f?renc?e
>>> Z:/JDK/jdk8/jdk/src/windows/native/common/jdk_util_md.c(45) : warning C4101:
>>> 'ret': variable locale non r?f?renc?e
>>> Z:/JDK/jdk8/jdk/src/share/bin/java.c(1253) : warning C4101: 'result': variable
>>> locale nonr?f?renc?e
>>> Z:/JDK/jdk8/jdk/src/share/bin/parse_manifest.c(196) : warning C4244: 
>>> 'fonction':
>>> conversion de 'jlong' en 'unsigned int', perte possible de donn?es
>>>
>>>
>>>
>>> And here are the fixes
>>>
>>> diff --git a/src/share/bin/java.c b/src/share/bin/java.c
>>> --- a/src/share/bin/java.c
>>> +++ b/src/share/bin/java.c
>>> @@ -1250,7 +1250,6 @@
>>> GetApplicationClass(JNIEnv *env)
>>> {
>>>      jmethodID mid;
>>> -    jobject result;
>>>      jclass cls = GetLauncherHelperClass(env);
>>>      NULL_CHECK0(cls);
>>>      NULL_CHECK0(mid = (*env)->GetStaticMethodID(env, cls,
>>> diff --git a/src/share/bin/parse_manifest.c b/src/share/bin/parse_manifest.c
>>> --- a/src/share/bin/parse_manifest.c
>>> +++ b/src/share/bin/parse_manifest.c
>>> @@ -193,7 +193,7 @@
>>>          return (-1);
>>>      if ((buffer = malloc(END_MAXLEN)) == NULL)
>>>          return (-1);
>>> -    if ((bytes = read(fd, buffer, len)) < 0) {
>>> +    if ((bytes = read(fd, buffer, (size_t)len)) < 0) {
>>>          free(buffer);
>>>          return (-1);
>>>      }
>>> diff --git a/src/share/native/java/lang/Throwable.c
>>> b/src/share/native/java/lang/Throwable.c
>>> --- a/src/share/native/java/lang/Throwable.c
>>> +++ b/src/share/native/java/lang/Throwable.c
>>> @@ -44,7 +44,7 @@
>>>   * `this' so you can write 'throw e.fillInStackTrace();'
>>>   */
>>> JNIEXPORT jobject JNICALL
>>> -Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, int
>>> dummy)
>>> +Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, jint
>>> dummy)
>>> {
>>>      JVM_FillInStackTrace(env, throwable);
>>>      return throwable;
>>> diff --git a/src/windows/native/common/jdk_util_md.c
>>> b/src/windows/native/common/jdk_util_md.c
>>> --- a/src/windows/native/common/jdk_util_md.c
>>> +++ b/src/windows/native/common/jdk_util_md.c
>>> @@ -42,7 +42,6 @@
>>> JNIEXPORT HMODULE JDK_LoadSystemLibrary(const char* name) {
>>>      HMODULE handle = NULL;
>>>      char path[MAX_PATH];
>>> -    int ret;
>>>
>>>      if (GetSystemDirectory(path, sizeof(path)) != 0) {
>>>          strcat(path, "\\");
>>> diff --git a/src/windows/native/java/io/WinNTFileSystem_md.c
>>> b/src/windows/native/java/io/WinNTFileSystem_md.c
>>> --- a/src/windows/native/java/io/WinNTFileSystem_md.c
>>> +++ b/src/windows/native/java/io/WinNTFileSystem_md.c
>>> @@ -360,7 +360,6 @@
>>>                                                    jobject file)
>>> {
>>>      jint rv = 0;
>>> -    jint pathlen;
>>>
>>>      WCHAR *pathbuf = fileToNTPath(env, file, ids.path);
>>>      if (pathbuf == NULL)
>>>
>>>
>>>
>
>



From daniel.fuchs at oracle.com  Mon Dec 16 09:51:48 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 16 Dec 2013 10:51:48 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AC97AF.4050403@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
	<52AC97AF.4050403@gmail.com>
Message-ID: <52AECD34.7000708@oracle.com>

On 12/14/13 6:38 PM, Peter Levart wrote:
> Hi,
>
> Daniel reminded me of a couple of issues the 4th revision of the patch
> would have when backporting to 7u. So here's another variant that tries
> to be more backport-friendly:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>
> This variant could be backported by simply replacing a limited variant
> of doPrivileged (introduced in JDK 8) with full variant and still not
> elevate the privilege of Socket creation in SocketHandler. I also
> removed the need to subclass various ConfigureAction(s) with annonymous
> inner subclasses by introducing overloaded constructors to
> ConfigureActions(s) that follow the overloaded constructors of various
> Handlers.
>
> Regards, Peter

Hi Peter,

This looks good! Particularly since moving connect() out of
the doProvileged has removed the need for wrapping/unwrapping the
IOException.

best regards,

-- daniel

>
> On 12/14/2013 12:25 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>> H Mandy,
>>>>
>>>> I created an issue for it nevertheless:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>>
>>>> You're right, doPrivileged() is a more straight-forward approach
>>>> than 'sealed' variable. Since this might only be considered for
>>>> inclusion in JDK9 when lambdas are already a tried technology, how
>>>> do you feel about using them for platform code like logging? As far
>>>> as I know (just checked), lambda meta-factory is not using any
>>>> j.u.logging, so there is no danger of initialization loops or similar:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
>>>>
>>>
>>> Sorry for the delay to get to this.
>>
>> No rush. We have time before JDK9 gets set-up and running...
>>
>>>
>>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>> PlatformLogger which will forward calls to j.u.logging if
>>> -Djava.util.logging.config.file is set or java.util.logging has been
>>> initialized (via other j.u.logging call).  It means that it may lead
>>> to recursive initialization.  Also the current PlatformLogger
>>> implementation formats the message in the same way as j.u.logging
>>> that may load locale providers and other classes.  I am afraid there
>>> are issues to tease out and resolve.
>>
>> It's unfortunate that a lambda debugging feature prevents us from
>> using a basic language feature in j.u.logging code. As far as I know,
>> java.lang.invoke.ProxyClassesDumper is only used if
>> 'jdk.internal.lambda.dumpProxyClasses' system property is set to point
>> to a directory where lambda proxy class files are to be dumped as they
>> are generated - a debugging hook therefore. Wouldn't it be good-enough
>> if error messages about not-being able to set-up/use the dump facility
>> were output to System.err directly - not using PlatformLogger at all?
>>
>>>
>>> The overloads the doPrivileged method makes it cumbersome to use
>>> lambda that causes you to workaround it by adding a new
>>> PrivilegedVoidAction interface which is clever.  So I think it isn't
>>> too bad for this patch to use anonymous inner class and have the
>>> doPrivileged call in the constructor.
>>
>> Right. I have prepared a modified webrev which doesn't use lambdas:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>
>> In attempt to minimize the boilerplate, I haven't just replaced
>> lambdas with anonymous inner classes, but rather turned all private
>> configure() methods into ConfigureAction inner classes. In two
>> occasions (SocketHandler and StreamHandler), they are extended with
>> anonymous inner classes to append some actions. In SocketHandler I
>> kept the mechanics of transporting the checked IOException out of
>> PrivilegedAction by wrapping it with Unchecked IOException and later
>> unwrapping and throwing it, rather than using
>> PrivilegedExceptionAction which would further complicate exception
>> handling, since it declares throwing a general j.l.Exception, but the
>> SocketHandler constructor only declares throwing IOException...
>>
>> I think this could be backported to 7u as-is.
>>
>> Regards, Peter
>>
>>>
>>>
>>> Mandy
>>
>



From joel.franck at oracle.com  Mon Dec 16 09:53:45 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 16 Dec 2013 10:53:45 +0100
Subject: Review request for 8021368: Launch of Java Web Start app fails
	with ClassCircularityError exception
In-Reply-To: <52ACFF98.8070509@oracle.com>
References: <52AA008E.1000206@oracle.com> <52AC6683.3020107@gmail.com>
	<52ACFF98.8070509@oracle.com>
Message-ID: <20131216095345.GA21368@oracle.com>

Hi Mandy,

Looks good.

cheers
/Joel

On 2013-12-14, Mandy Chung wrote:
> Hi Peter,
> 
> Thanks for the review.   This code path is critical in this core
> reflection implementation and I want to resolve this bug with a low
> risk fix in an update release and thus the proposed fix.   Thanks
> for the experiment with MethodHandles and finding out the
> pecularity.   As a side note, I really look forward to the
> reflective method call being reimplemented with method handles
> (great to see your prototype).
> 
> I have incorporated Alan's and your comment.   Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.01/
> 
> Mandy
> 
> On 12/14/2013 6:09 AM, Peter Levart wrote:
> >
> >Hi Mandy,
> >
> >I tried the following:
> >
> >
> >public class Test {
> >
> >    static class A {}
> >
> >    static class B {}
> >
> >    static class X {
> >        public void x() { }
> >    }
> >
> >    static class Y extends X {
> >        public A a(B b) { return null; }
> >        public B b(A a) { return null; }
> >        public void x() { }
> >    }
> >
> >    public static void main(String[] args) throws Exception {
> >        MethodHandles.Lookup lookup = MethodHandles.lookup();
> >        MethodHandle mh = lookup.findVirtual(Y.class, "x",
> >MethodType.methodType(void.class, new Class[0]));
> >        MethodHandleInfo mhi = lookup.revealDirect(mh);
> >        System.out.println(mhi.getDeclaringClass() == Y.class);
> >    }
> >}
> >
> >
> >The above code does not trigger loading of classes A or B. But
> >unfortunately it prints true even if I comment-out the declaration
> >of method Y.x(). I don't know if this is a bug though. I should
> >ask on the mlvm-dev list...
> >
> >Anyway, your approach seems more appropriate as it doesn't depend
> >on method handles and their peculiarities...
> >
> >Some nits:
> >
> >2241      * Finds the checkMemberAccess method of the given SecurityManager*instance*.
> >
> >
> >...I think it should read "...of the given SecurityManager*class*." instead, since the method parameter is of type Class.
> >
> >
> >2210     private static class SecurityManagerHelper {
> >2211         private final SecurityManager smgr;
> >2212         private final boolean overrideCheckMemberAccess;
> >
> >
> >...the fields could be declared package-private so that no synthetic access methods are generated...
> >
> >Regards, Peter
> >
> 


From roger.riggs at oracle.com  Mon Dec 16 17:02:05 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 16 Dec 2013 12:02:05 -0500
Subject: RFR java.time serialization
Message-ID: <52AF320D.6090706@oracle.com>

Please review these changes to java.time serialization.
The format of the serialized data is unchanged; deserialization
uses readObject instead of readResolve to flag invalid values.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/

Thanks, Roger



From roger.riggs at oracle.com  Mon Dec 16 17:47:20 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 16 Dec 2013 12:47:20 -0500
Subject: RFR java.time.chrono equals and hashCode
Message-ID: <52AF3CA8.7060507@oracle.com>

Please review this change to explicitly document the behavior of
equals and hashCode for java.time.chrono concrete types.
The behavior is not changed.

(They had been documented but the javadoc was not inherited during an 
earlier refactoring).

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-chrono-equals-8029909/

Thanks, Roger



From chris.hegarty at oracle.com  Mon Dec 16 17:49:18 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 16 Dec 2013 17:49:18 +0000
Subject: RFR java.time serialization
In-Reply-To: <52AF320D.6090706@oracle.com>
References: <52AF320D.6090706@oracle.com>
Message-ID: 

Roger,

The source changes look good to me, and in line with the Serialization proxy idiom (ignoring the Externalizable stuff).

-Chris.

On 16 Dec 2013, at 17:02, roger riggs  wrote:

> Please review these changes to java.time serialization.
> The format of the serialized data is unchanged; deserialization
> uses readObject instead of readResolve to flag invalid values.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/
> 
> Thanks, Roger
> 



From xueming.shen at oracle.com  Mon Dec 16 18:00:44 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Dec 2013 10:00:44 -0800
Subject: RFR java.time serialization
In-Reply-To: <52AF320D.6090706@oracle.com>
References: <52AF320D.6090706@oracle.com>
Message-ID: <52AF3FCC.4030502@oracle.com>

On 12/16/2013 09:02 AM, roger riggs wrote:
> Please review these changes to java.time serialization.
> The format of the serialized data is unchanged; deserialization
> uses readObject instead of readResolve to flag invalid values.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/
>
> Thanks, Roger
>
|| *
*(1) test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java*
*
    -- import not necessary?

(2) AbstractTCKTest.assertNotSerializable()

   -- the problem is that this test fails with current readResolve()
   implementation, as we chatted last Friday. So it might be hard to
   say it's a bulletproof test. But I guess it might not be worth to
   a proof there would be a loophole here if only define the readResolve()
   to throw the IOE.

-Sherman



From huizhe.wang at oracle.com  Mon Dec 16 19:31:43 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 16 Dec 2013 11:31:43 -0800
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon parsing
	literals with > 100 LF chars
Message-ID: <52AF551F.6070704@oracle.com>

Hi,

This is a quick fix for a whitespace buffer that was not adjusted 
properly in one of the two cases.  The buffer, whiteSpaceLookup, is 
filled in two cases and adjusted properly the 2nd time. The code is 
moved into a method storeWhiteSpace so that it's shared for the 1st case 
as well.

Note at line 1175, there is no need to save character 0x20 since all 
whitespace characters will later be replaced with character 0x20.

webrevs:
http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/

Thanks,
Joe


From roger.riggs at oracle.com  Mon Dec 16 20:21:57 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 16 Dec 2013 15:21:57 -0500
Subject: RFR java.time serialization
In-Reply-To: <52AF3FCC.4030502@oracle.com>
References: <52AF320D.6090706@oracle.com> <52AF3FCC.4030502@oracle.com>
Message-ID: <52AF60E5.20508@oracle.com>

Hi Sherman,

Thanks for the comments, corrected and updated the webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/

On 12/16/2013 1:00 PM, Xueming Shen wrote:
> On 12/16/2013 09:02 AM, roger riggs wrote:
>> Please review these changes to java.time serialization.
>> The format of the serialized data is unchanged; deserialization
>> uses readObject instead of readResolve to flag invalid values.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/
>>
>> Thanks, Roger
>>
> || *
> *(1) test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java*
> *
>    -- import not necessary?
removed extra imports
>
> (2) AbstractTCKTest.assertNotSerializable()
>
>   -- the problem is that this test fails with current readResolve()
>   implementation, as we chatted last Friday. So it might be hard to
>   say it's a bulletproof test. But I guess it might not be worth to
>   a proof there would be a loophole here if only define the readResolve()
>   to throw the IOE.
Thanks, Yes, the test(s) should be more liberal and catch Exception instead
of only InvalidObjectException since any exception during deserialization
terminates serialization.

Thanks, Roger



From mandy.chung at oracle.com  Mon Dec 16 21:14:03 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Dec 2013 13:14:03 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AC97AF.4050403@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
	<52AC97AF.4050403@gmail.com>
Message-ID: <52AF6D1B.8030409@oracle.com>

On 12/14/2013 9:38 AM, Peter Levart wrote:
> Hi,
>
> Daniel reminded me of a couple of issues the 4th revision of the patch 
> would have when backporting to 7u. So here's another variant that 
> tries to be more backport-friendly:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/

This looks good in general.

SocketHandler line 200 - it looks to me that this is an existing bug 
that should call setOutputStream within doPrivileged.

I think it'd be simpler if SocketHandler no-arg constructor can first 
get the port and host from the logging properties so that it doesn't 
need to differentiate hostAndPortSet is set and ConfigureAction no-arg 
constructor can be removed.

Daniel/Peter - do we have tests to cover these permission check for 
these handlers?

Mandy

>
> This variant could be backported by simply replacing a limited variant 
> of doPrivileged (introduced in JDK 8) with full variant and still not 
> elevate the privilege of Socket creation in SocketHandler. I also 
> removed the need to subclass various ConfigureAction(s) with 
> annonymous inner subclasses by introducing overloaded constructors to 
> ConfigureActions(s) that follow the overloaded constructors of various 
> Handlers.
>
> Regards, Peter
>
> On 12/14/2013 12:25 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>> H Mandy,
>>>>
>>>> I created an issue for it nevertheless:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>>
>>>> You're right, doPrivileged() is a more straight-forward approach 
>>>> than 'sealed' variable. Since this might only be considered for 
>>>> inclusion in JDK9 when lambdas are already a tried technology, how 
>>>> do you feel about using them for platform code like logging? As far 
>>>> as I know (just checked), lambda meta-factory is not using any 
>>>> j.u.logging, so there is no danger of initialization loops or similar:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>>>
>>>
>>> Sorry for the delay to get to this.
>>
>> No rush. We have time before JDK9 gets set-up and running...
>>
>>>
>>> Alan is right that java.lang.invoke.ProxyClassesDumper does use 
>>> PlatformLogger which will forward calls to j.u.logging if 
>>> -Djava.util.logging.config.file is set or java.util.logging has been 
>>> initialized (via other j.u.logging call).  It means that it may lead 
>>> to recursive initialization.  Also the current PlatformLogger 
>>> implementation formats the message in the same way as j.u.logging 
>>> that may load locale providers and other classes.  I am afraid there 
>>> are issues to tease out and resolve.
>>
>> It's unfortunate that a lambda debugging feature prevents us from 
>> using a basic language feature in j.u.logging code. As far as I know, 
>> java.lang.invoke.ProxyClassesDumper is only used if 
>> 'jdk.internal.lambda.dumpProxyClasses' system property is set to 
>> point to a directory where lambda proxy class files are to be dumped 
>> as they are generated - a debugging hook therefore. Wouldn't it be 
>> good-enough if error messages about not-being able to set-up/use the 
>> dump facility were output to System.err directly - not using 
>> PlatformLogger at all?
>>
>>>
>>> The overloads the doPrivileged method makes it cumbersome to use 
>>> lambda that causes you to workaround it by adding a new 
>>> PrivilegedVoidAction interface which is clever.  So I think it isn't 
>>> too bad for this patch to use anonymous inner class and have the 
>>> doPrivileged call in the constructor.
>>
>> Right. I have prepared a modified webrev which doesn't use lambdas:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>
>> In attempt to minimize the boilerplate, I haven't just replaced 
>> lambdas with anonymous inner classes, but rather turned all private 
>> configure() methods into ConfigureAction inner classes. In two 
>> occasions (SocketHandler and StreamHandler), they are extended with 
>> anonymous inner classes to append some actions. In SocketHandler I 
>> kept the mechanics of transporting the checked IOException out of 
>> PrivilegedAction by wrapping it with Unchecked IOException and later 
>> unwrapping and throwing it, rather than using 
>> PrivilegedExceptionAction which would further complicate exception 
>> handling, since it declares throwing a general j.l.Exception, but the 
>> SocketHandler constructor only declares throwing IOException...
>>
>> I think this could be backported to 7u as-is.
>>
>> Regards, Peter
>>
>>>
>>>
>>> Mandy
>>
>



From mike.duigou at oracle.com  Tue Dec 17 03:42:30 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 16 Dec 2013 19:42:30 -0800
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: 
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	
	<042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>
	
Message-ID: 

I've updated the documentation per Paul's suggestions. Specifically, in addition to the existing put() and get() methods the new Map methods

putIfAbsent()
getOrDefault()
compute()
computeIfAbsent()
computeIfPresent()
merge()

are all documented to perform a single access of the entry (assuming that an entry is created or modified as a result). 

replace()

is documented as accessing the entry, if it exists and a replacement is made. If no replacement is made then no access is recorded.

http://cr.openjdk.java.net/~mduigou/JDK-8029795/2/webrev/

Mike


On Dec 11 2013, at 02:32 , Paul Sandoz  wrote:

> 
> On Dec 11, 2013, at 1:27 AM, Mike Duigou  wrote:
> 
>> I have added tests and documentation for the other methods.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/
>> 
>> The documentation for some of the methods is ambiguous about how many access events are generated. For LRU cache is OK but other cases (counting based eviction) may care about the total number of accesses.
> 
> + * invocation completes).  Invoking the {@code replace}, {@code merge},
> + * {@code compute} or {@code computeIfPresent} methods results in one or more
> + * accesses of the corresponding entry. The {@code putAll} method generates one
> 
> If i look at the code for say replace it generates *at most one access* in terms of affecting last access order, if the entry exists and if the old/new value constraint holds:
> 
>    @Override
>    public boolean replace(K key, V oldValue, V newValue) {
>        Node e; V v;
>        if ((e = getNode(hash(key), key)) != null &&
>            ((v = e.value) == oldValue || (v != null && v.equals(oldValue)))) {
>            e.value = newValue;
>            afterNodeAccess(e);
>            return true;
>        }
>        return false;
>    }
> 
> 
> I have attempted to categorise the access behaviour of each method:
> 
> get:
>  access to entry, if it exists
> 
> put:
>  access to new entry
> 
> putIfAbsent
>  access to entry, if it exists
>  otherwise access to new entry
> 
> replace(K key, V value)
>  access to entry, if it exists
> 
> replace(K key, V oldValue, V newValue)
>  access to entry, if it exists and it's value is updated
> 
> computeIfAbsent:
>  access to entry, if it exists and it's value is non-null, or 
>  access to entry, if it exists and it's null value is updated to a non-null value [*], 
>  otherwise access to new entry, if created
> 
> computeIfPresent
>  access to entry, if it exists and it's non-null value is updated to a non-null value
> 
> compute
>  access to entry, if it exists and it's value is updated to a non-null value,
>  otherwise access to new entry, if created
> 
> merge
>  access to entry, if it exists and it's value is updated to a non-null value,
>  otherwise access to new entry, if created
> 
> 
> Patterns, to help group for documentation:
> 
> get/put/putIfAbsent/replace(K key, V value): access to entry associated with the key, if entry exists after invocation completes
> 
> replace(K key, V oldValue, V newValue): access to entry associated with the key, if returns true
> 
> computeIfAbsent/computeIfPresent/compute/merge: access to entry associated with the key, if returns a non-null value.
> 
> 
> --
> 
> [*] There is some ambiguity with computeIfAbsent. When the entry exists, it's value is null, and the value returned from the mapping function is null then, an access to that entry occurs:
> 
>        V v = mappingFunction.apply(key);
>        if (old != null) {
>            old.value = v;
>            afterNodeAccess(old);
>            return v;
>        }
>        else if (v == null)
>            return null;
> 
> Is that a bug? I would have expected the returning of null from the mapping function to signal no-action to be taken. Thus computeIfPresent and computeIfAbsent have no side-effects for an existing entry whose value is null when the function returns null (same applies to merge, if the value parameter is null or the remapping function returns null, and to compute, if the remapping function returns null).
> 
> So perhaps that code should be:
> 
>        V v = mappingFunction.apply(key);
>        if (v == null)
>           return null;
>        else if (old != null) {
>            old.value = v;
>            afterNodeAccess(old);
>            return v;
>        }
> 
> Paul.



From scolebourne at joda.org  Tue Dec 17 05:30:00 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 17 Dec 2013 18:30:00 +1300
Subject: RFR java.time serialization
In-Reply-To: <52AF60E5.20508@oracle.com>
References: <52AF320D.6090706@oracle.com> <52AF3FCC.4030502@oracle.com>
	<52AF60E5.20508@oracle.com>
Message-ID: 

Looks fine AFAICT
Stephen
On 17 Dec 2013 09:23, "roger riggs"  wrote:

> Hi Sherman,
>
> Thanks for the comments, corrected and updated the webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/
>
> On 12/16/2013 1:00 PM, Xueming Shen wrote:
>
>> On 12/16/2013 09:02 AM, roger riggs wrote:
>>
>>> Please review these changes to java.time serialization.
>>> The format of the serialized data is unchanged; deserialization
>>> uses readObject instead of readResolve to flag invalid values.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/
>>>
>>> Thanks, Roger
>>>
>>>  || *
>> *(1) test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java*
>> *
>>    -- import not necessary?
>>
> removed extra imports
>
>>
>> (2) AbstractTCKTest.assertNotSerializable()
>>
>>   -- the problem is that this test fails with current readResolve()
>>   implementation, as we chatted last Friday. So it might be hard to
>>   say it's a bulletproof test. But I guess it might not be worth to
>>   a proof there would be a loophole here if only define the readResolve()
>>   to throw the IOE.
>>
> Thanks, Yes, the test(s) should be more liberal and catch Exception instead
> of only InvalidObjectException since any exception during deserialization
> terminates serialization.
>
> Thanks, Roger
>
>


From scolebourne at joda.org  Tue Dec 17 05:31:57 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 17 Dec 2013 18:31:57 +1300
Subject: RFR java.time.chrono equals and hashCode
In-Reply-To: <52AF3CA8.7060507@oracle.com>
References: <52AF3CA8.7060507@oracle.com>
Message-ID: 

Looks good to me
Stephen
On 17 Dec 2013 06:48, "roger riggs"  wrote:

> Please review this change to explicitly document the behavior of
> equals and hashCode for java.time.chrono concrete types.
> The behavior is not changed.
>
> (They had been documented but the javadoc was not inherited during an
> earlier refactoring).
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-time-chrono-equals-8029909/
>
> Thanks, Roger
>
>


From daniel.fuchs at oracle.com  Tue Dec 17 10:29:21 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Dec 2013 11:29:21 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AF6D1B.8030409@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
	<52AC97AF.4050403@gmail.com> <52AF6D1B.8030409@oracle.com>
Message-ID: <52B02781.60606@oracle.com>

On 12/16/13 10:14 PM, Mandy Chung wrote:
> On 12/14/2013 9:38 AM, Peter Levart wrote:
>> Hi,
>>
>> Daniel reminded me of a couple of issues the 4th revision of the patch
>> would have when backporting to 7u. So here's another variant that
>> tries to be more backport-friendly:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>
> This looks good in general.
>
> SocketHandler line 200 - it looks to me that this is an existing bug
> that should call setOutputStream within doPrivileged.

I'm not sure I would qualify this as a bug: if you want to create a
SocketHandler that sends to a specific host/port you need the
LoggingPermission("control").

> I think it'd be simpler if SocketHandler no-arg constructor can first
> get the port and host from the logging properties so that it doesn't
> need to differentiate hostAndPortSet is set and ConfigureAction no-arg
> constructor can be removed.
>
> Daniel/Peter - do we have tests to cover these permission check for
> these handlers?

Shockingly:

$ cd jdk/test/java/util/logging
$ find . -type f -exec grep SocketHandler {} /dev/null \;

reveals nothing. So it seams we have no unit tests for SocketHandler!

-- daniel

>
> Mandy
>
>>
>> This variant could be backported by simply replacing a limited variant
>> of doPrivileged (introduced in JDK 8) with full variant and still not
>> elevate the privilege of Socket creation in SocketHandler. I also
>> removed the need to subclass various ConfigureAction(s) with
>> annonymous inner subclasses by introducing overloaded constructors to
>> ConfigureActions(s) that follow the overloaded constructors of various
>> Handlers.
>>
>> Regards, Peter
>>
>> On 12/14/2013 12:25 PM, Peter Levart wrote:
>>> Hi Mandy,
>>>
>>> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>>> Hi Peter,
>>>>
>>>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>>> H Mandy,
>>>>>
>>>>> I created an issue for it nevertheless:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>>>
>>>>> You're right, doPrivileged() is a more straight-forward approach
>>>>> than 'sealed' variable. Since this might only be considered for
>>>>> inclusion in JDK9 when lambdas are already a tried technology, how
>>>>> do you feel about using them for platform code like logging? As far
>>>>> as I know (just checked), lambda meta-factory is not using any
>>>>> j.u.logging, so there is no danger of initialization loops or similar:
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
>>>>>
>>>>
>>>> Sorry for the delay to get to this.
>>>
>>> No rush. We have time before JDK9 gets set-up and running...
>>>
>>>>
>>>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>>> PlatformLogger which will forward calls to j.u.logging if
>>>> -Djava.util.logging.config.file is set or java.util.logging has been
>>>> initialized (via other j.u.logging call).  It means that it may lead
>>>> to recursive initialization.  Also the current PlatformLogger
>>>> implementation formats the message in the same way as j.u.logging
>>>> that may load locale providers and other classes.  I am afraid there
>>>> are issues to tease out and resolve.
>>>
>>> It's unfortunate that a lambda debugging feature prevents us from
>>> using a basic language feature in j.u.logging code. As far as I know,
>>> java.lang.invoke.ProxyClassesDumper is only used if
>>> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>> point to a directory where lambda proxy class files are to be dumped
>>> as they are generated - a debugging hook therefore. Wouldn't it be
>>> good-enough if error messages about not-being able to set-up/use the
>>> dump facility were output to System.err directly - not using
>>> PlatformLogger at all?
>>>
>>>>
>>>> The overloads the doPrivileged method makes it cumbersome to use
>>>> lambda that causes you to workaround it by adding a new
>>>> PrivilegedVoidAction interface which is clever.  So I think it isn't
>>>> too bad for this patch to use anonymous inner class and have the
>>>> doPrivileged call in the constructor.
>>>
>>> Right. I have prepared a modified webrev which doesn't use lambdas:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>>
>>> In attempt to minimize the boilerplate, I haven't just replaced
>>> lambdas with anonymous inner classes, but rather turned all private
>>> configure() methods into ConfigureAction inner classes. In two
>>> occasions (SocketHandler and StreamHandler), they are extended with
>>> anonymous inner classes to append some actions. In SocketHandler I
>>> kept the mechanics of transporting the checked IOException out of
>>> PrivilegedAction by wrapping it with Unchecked IOException and later
>>> unwrapping and throwing it, rather than using
>>> PrivilegedExceptionAction which would further complicate exception
>>> handling, since it declares throwing a general j.l.Exception, but the
>>> SocketHandler constructor only declares throwing IOException...
>>>
>>> I think this could be backported to 7u as-is.
>>>
>>> Regards, Peter
>>>
>>>>
>>>>
>>>> Mandy
>>>
>>
>



From daniel.fuchs at oracle.com  Tue Dec 17 11:57:11 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Dec 2013 12:57:11 +0100
Subject: RFR: java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
	failing again
Message-ID: <52B03C17.5040204@oracle.com>

Hi,

Please find below a fix for what I believe is a test bug.
I plan to push this in JDK 9 dev.

https://bugs.openjdk.java.net/browse/JDK-8030187

This seems to be a very intermittent failure.
It looks as if a logger held in a local variable can be
arbitrarily garbage collected if that variable is no longer
used.
To prevent arbitrary garbage collection of such loggers, the fix
makes sure to use the variable again at the end of the test.

In the event that my analysis were wrong, I have also added
some debug traces that should help if this test fails again in
similar situations.

http://cr.openjdk.java.net/~dfuchs/webrev_8030187/webrev.00/

best regards,

-- daniel


From daniel.fuchs at oracle.com  Tue Dec 17 12:10:14 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Dec 2013 13:10:14 +0100
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52AF551F.6070704@oracle.com>
References: <52AF551F.6070704@oracle.com>
Message-ID: <52B03F26.8070204@oracle.com>

Hi Joe,

The fix looks good - though I wonder at whether incrementing
whiteSpaceLookup by a fix amount wouldn't be better than
doubling its length.

best regards,

-- daniel

On 12/16/13 8:31 PM, huizhe wang wrote:
> Hi,
>
> This is a quick fix for a whitespace buffer that was not adjusted
> properly in one of the two cases.  The buffer, whiteSpaceLookup, is
> filled in two cases and adjusted properly the 2nd time. The code is
> moved into a method storeWhiteSpace so that it's shared for the 1st case
> as well.
>
> Note at line 1175, there is no need to save character 0x20 since all
> whitespace characters will later be replaced with character 0x20.
>
> webrevs:
> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>
> Thanks,
> Joe



From paul.sandoz at oracle.com  Tue Dec 17 13:51:18 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Dec 2013 14:51:18 +0100
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: 
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	
	<042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>
	
	
Message-ID: <85C4CD55-B0EC-47F8-848A-0311FA943EC6@oracle.com>


On Dec 17, 2013, at 4:42 AM, Mike Duigou  wrote:

> I've updated the documentation per Paul's suggestions. Specifically, in addition to the existing put() and get() methods the new Map methods
> 
> putIfAbsent()
> getOrDefault()
> compute()
> computeIfAbsent()
> computeIfPresent()
> merge()
> 
> are all documented to perform a single access of the entry (assuming that an entry is created or modified as a result). 
> 
> replace()
> 
> is documented as accessing the entry, if it exists and a replacement is made. If no replacement is made then no access is recorded.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8029795/2/webrev/
> 

Looking good. Just one v. minor thing for:

+ * invocation completes). The {@code replace} method only results in an access
+ * of the entry if the value is replaced.  The {@code putAll} method generates one

There are two replace methods:

* invocation completes). The {@code replace} methods only results in an access

Paul.

From jason_mehrens at hotmail.com  Tue Dec 17 15:29:56 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 17 Dec 2013 09:29:56 -0600
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AF6D1B.8030409@oracle.com>
References: <529D9BAC.1020904@gmail.com>
	<529DA808.7070009@gmail.com>,<529E68E5.7000103@oracle.com>
	<52A4C659.4020406@gmail.com>,<52AA48BB.7010303@oracle.com>
	<52AC401B.1010405@gmail.com>, <52AC97AF.4050403@gmail.com>,
	<52AF6D1B.8030409@oracle.com>
Message-ID: 

Handlers can be subclassed.  Is it a security concern when doPrivileged is invoking non-final public/protected methods?  For example,
 
@Override
public void setOutputStream(OutputStream out) {
     LogManager.getLogManager().reset();
}
 
@Override
public void setLevel(Level l) {
        LogManager.getLogManager().reset();
}
 
Jason
 
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.chung at oracle.com
> To: peter.levart at gmail.com
> Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> CC: core-libs-dev at openjdk.java.net
> 
> On 12/14/2013 9:38 AM, Peter Levart wrote:
> > Hi,
> >
> > Daniel reminded me of a couple of issues the 4th revision of the patch 
> > would have when backporting to 7u. So here's another variant that 
> > tries to be more backport-friendly:
> >
> > http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
> 
> This looks good in general.
> 
> SocketHandler line 200 - it looks to me that this is an existing bug 
> that should call setOutputStream within doPrivileged.
> 
> I think it'd be simpler if SocketHandler no-arg constructor can first 
> get the port and host from the logging properties so that it doesn't 
> need to differentiate hostAndPortSet is set and ConfigureAction no-arg 
> constructor can be removed.
> 
> Daniel/Peter - do we have tests to cover these permission check for 
> these handlers?
> 
> Mandy
> 
> >
> > This variant could be backported by simply replacing a limited variant 
> > of doPrivileged (introduced in JDK 8) with full variant and still not 
> > elevate the privilege of Socket creation in SocketHandler. I also 
> > removed the need to subclass various ConfigureAction(s) with 
> > annonymous inner subclasses by introducing overloaded constructors to 
> > ConfigureActions(s) that follow the overloaded constructors of various 
> > Handlers.
> >
> > Regards, Peter
> >
> > On 12/14/2013 12:25 PM, Peter Levart wrote:
> >> Hi Mandy,
> >>
> >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
> >>> Hi Peter,
> >>>
> >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
> >>>> H Mandy,
> >>>>
> >>>> I created an issue for it nevertheless:
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
> >>>>
> >>>> You're right, doPrivileged() is a more straight-forward approach 
> >>>> than 'sealed' variable. Since this might only be considered for 
> >>>> inclusion in JDK9 when lambdas are already a tried technology, how 
> >>>> do you feel about using them for platform code like logging? As far 
> >>>> as I know (just checked), lambda meta-factory is not using any 
> >>>> j.u.logging, so there is no danger of initialization loops or similar:
> >>>>
> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
> >>>>
> >>>
> >>> Sorry for the delay to get to this.
> >>
> >> No rush. We have time before JDK9 gets set-up and running...
> >>
> >>>
> >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use 
> >>> PlatformLogger which will forward calls to j.u.logging if 
> >>> -Djava.util.logging.config.file is set or java.util.logging has been 
> >>> initialized (via other j.u.logging call).  It means that it may lead 
> >>> to recursive initialization.  Also the current PlatformLogger 
> >>> implementation formats the message in the same way as j.u.logging 
> >>> that may load locale providers and other classes.  I am afraid there 
> >>> are issues to tease out and resolve.
> >>
> >> It's unfortunate that a lambda debugging feature prevents us from 
> >> using a basic language feature in j.u.logging code. As far as I know, 
> >> java.lang.invoke.ProxyClassesDumper is only used if 
> >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to 
> >> point to a directory where lambda proxy class files are to be dumped 
> >> as they are generated - a debugging hook therefore. Wouldn't it be 
> >> good-enough if error messages about not-being able to set-up/use the 
> >> dump facility were output to System.err directly - not using 
> >> PlatformLogger at all?
> >>
> >>>
> >>> The overloads the doPrivileged method makes it cumbersome to use 
> >>> lambda that causes you to workaround it by adding a new 
> >>> PrivilegedVoidAction interface which is clever.  So I think it isn't 
> >>> too bad for this patch to use anonymous inner class and have the 
> >>> doPrivileged call in the constructor.
> >>
> >> Right. I have prepared a modified webrev which doesn't use lambdas:
> >>
> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
> >>
> >> In attempt to minimize the boilerplate, I haven't just replaced 
> >> lambdas with anonymous inner classes, but rather turned all private 
> >> configure() methods into ConfigureAction inner classes. In two 
> >> occasions (SocketHandler and StreamHandler), they are extended with 
> >> anonymous inner classes to append some actions. In SocketHandler I 
> >> kept the mechanics of transporting the checked IOException out of 
> >> PrivilegedAction by wrapping it with Unchecked IOException and later 
> >> unwrapping and throwing it, rather than using 
> >> PrivilegedExceptionAction which would further complicate exception 
> >> handling, since it declares throwing a general j.l.Exception, but the 
> >> SocketHandler constructor only declares throwing IOException...
> >>
> >> I think this could be backported to 7u as-is.
> >>
> >> Regards, Peter
> >>
> >>>
> >>>
> >>> Mandy
> >>
> >
> 
 		 	   		  

From roger.riggs at oracle.com  Tue Dec 17 15:56:43 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 17 Dec 2013 10:56:43 -0500
Subject: Please Review Basic test improvement  8029629
Message-ID: <52B0743B.4030501@oracle.com>

Please review this test improvement proposed by Martin Buchholz.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-basic-8029629/

Thanks, Roger





From martinrb at google.com  Tue Dec 17 16:10:09 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 17 Dec 2013 08:10:09 -0800
Subject: Please Review Basic test improvement 8029629
In-Reply-To: <52B0743B.4030501@oracle.com>
References: <52B0743B.4030501@oracle.com>
Message-ID: 

Looks Good to Me!


On Tue, Dec 17, 2013 at 7:56 AM, roger riggs  wrote:

> Please review this test improvement proposed by Martin Buchholz.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-basic-8029629/
>
> Thanks, Roger
>
>
>
>


From peter.levart at gmail.com  Tue Dec 17 16:22:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Dec 2013 17:22:51 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B02781.60606@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
	<52AC97AF.4050403@gmail.com> <52AF6D1B.8030409@oracle.com>
	<52B02781.60606@oracle.com>
Message-ID: <52B07A5B.2000105@gmail.com>

On 12/17/2013 11:29 AM, Daniel Fuchs wrote:
> On 12/16/13 10:14 PM, Mandy Chung wrote:
>> On 12/14/2013 9:38 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> Daniel reminded me of a couple of issues the 4th revision of the patch
>>> would have when backporting to 7u. So here's another variant that
>>> tries to be more backport-friendly:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/ 
>>>
>>
>> This looks good in general.
>>
>> SocketHandler line 200 - it looks to me that this is an existing bug
>> that should call setOutputStream within doPrivileged.

I was asking myself the same question.

>
> I'm not sure I would qualify this as a bug: if you want to create a
> SocketHandler that sends to a specific host/port you need the
> LoggingPermission("control").

What is being protected with permission checking in Handler(s) is 
changing various properties of Handler(s). What we are granting with 
doPriviliged is a temporary elevation of privilege for changing the 
properties of the instance of Handler that is being constructed - just 
for the act of constructing the instance of Handler. Anybody should be 
able to instantiate new Handler instance - that doesn't present any 
special capability. Putting new Handler into service is already 
additionally protected (for example Logger.addHandler()). So in case of 
SocketHandler, one should be able to instantiate new SocketHandler for 
specified host/port if she has permission to create a Socket to that 
host/port, but nothing more should be required. To put such Handler into 
service (to direct logging messages generated by logging system to it), 
additional LoggingPermission("control") is already required.

So I think Mandy is right and that is an existing bug, although not very 
critical, since it only affects those that want to instantiate new 
SocketHandler although they are not able to use it in the logging system 
(maybe they use it somewhere else?).

Regards, Peter

>
>> I think it'd be simpler if SocketHandler no-arg constructor can first
>> get the port and host from the logging properties so that it doesn't
>> need to differentiate hostAndPortSet is set and ConfigureAction no-arg
>> constructor can be removed.
>>
>> Daniel/Peter - do we have tests to cover these permission check for
>> these handlers?
>
> Shockingly:
>
> $ cd jdk/test/java/util/logging
> $ find . -type f -exec grep SocketHandler {} /dev/null \;
>
> reveals nothing. So it seams we have no unit tests for SocketHandler!
>
> -- daniel
>
>>
>> Mandy
>>
>>>
>>> This variant could be backported by simply replacing a limited variant
>>> of doPrivileged (introduced in JDK 8) with full variant and still not
>>> elevate the privilege of Socket creation in SocketHandler. I also
>>> removed the need to subclass various ConfigureAction(s) with
>>> annonymous inner subclasses by introducing overloaded constructors to
>>> ConfigureActions(s) that follow the overloaded constructors of various
>>> Handlers.
>>>
>>> Regards, Peter
>>>
>>> On 12/14/2013 12:25 PM, Peter Levart wrote:
>>>> Hi Mandy,
>>>>
>>>> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>>>> H Mandy,
>>>>>>
>>>>>> I created an issue for it nevertheless:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>>>>
>>>>>> You're right, doPrivileged() is a more straight-forward approach
>>>>>> than 'sealed' variable. Since this might only be considered for
>>>>>> inclusion in JDK9 when lambdas are already a tried technology, how
>>>>>> do you feel about using them for platform code like logging? As far
>>>>>> as I know (just checked), lambda meta-factory is not using any
>>>>>> j.u.logging, so there is no danger of initialization loops or 
>>>>>> similar:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>>>>>
>>>>>>
>>>>>
>>>>> Sorry for the delay to get to this.
>>>>
>>>> No rush. We have time before JDK9 gets set-up and running...
>>>>
>>>>>
>>>>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>>>> PlatformLogger which will forward calls to j.u.logging if
>>>>> -Djava.util.logging.config.file is set or java.util.logging has been
>>>>> initialized (via other j.u.logging call).  It means that it may lead
>>>>> to recursive initialization.  Also the current PlatformLogger
>>>>> implementation formats the message in the same way as j.u.logging
>>>>> that may load locale providers and other classes.  I am afraid there
>>>>> are issues to tease out and resolve.
>>>>
>>>> It's unfortunate that a lambda debugging feature prevents us from
>>>> using a basic language feature in j.u.logging code. As far as I know,
>>>> java.lang.invoke.ProxyClassesDumper is only used if
>>>> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>>> point to a directory where lambda proxy class files are to be dumped
>>>> as they are generated - a debugging hook therefore. Wouldn't it be
>>>> good-enough if error messages about not-being able to set-up/use the
>>>> dump facility were output to System.err directly - not using
>>>> PlatformLogger at all?
>>>>
>>>>>
>>>>> The overloads the doPrivileged method makes it cumbersome to use
>>>>> lambda that causes you to workaround it by adding a new
>>>>> PrivilegedVoidAction interface which is clever.  So I think it isn't
>>>>> too bad for this patch to use anonymous inner class and have the
>>>>> doPrivileged call in the constructor.
>>>>
>>>> Right. I have prepared a modified webrev which doesn't use lambdas:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/ 
>>>>
>>>>
>>>> In attempt to minimize the boilerplate, I haven't just replaced
>>>> lambdas with anonymous inner classes, but rather turned all private
>>>> configure() methods into ConfigureAction inner classes. In two
>>>> occasions (SocketHandler and StreamHandler), they are extended with
>>>> anonymous inner classes to append some actions. In SocketHandler I
>>>> kept the mechanics of transporting the checked IOException out of
>>>> PrivilegedAction by wrapping it with Unchecked IOException and later
>>>> unwrapping and throwing it, rather than using
>>>> PrivilegedExceptionAction which would further complicate exception
>>>> handling, since it declares throwing a general j.l.Exception, but the
>>>> SocketHandler constructor only declares throwing IOException...
>>>>
>>>> I think this could be backported to 7u as-is.
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>
>>>>> Mandy
>>>>
>>>
>>
>



From peter.levart at gmail.com  Tue Dec 17 16:25:30 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Dec 2013 17:25:30 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: 
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
Message-ID: <52B07AFA.6080703@gmail.com>

On 12/17/2013 04:29 PM, Jason Mehrens wrote:
> Handlers can be subclassed.  Is it a security concern when 
> doPrivileged is invoking non-final public/protected methods?  For example,
>
> @Override
> public void setOutputStream(OutputStream out) {
>      LogManager.getLogManager().reset();
> }
>
> @Override
> public void setLevel(Level l) {
>         LogManager.getLogManager().reset();
> }
>
> Jason

Good catch! The 'sealed' field did not allow that, since there was no 
elevation of privilege. So doPrivileged is out of question, right?

Peter

>
> > Date: Mon, 16 Dec 2013 13:14:03 -0800
> > From: mandy.chung at oracle.com
> > To: peter.levart at gmail.com
> > Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> > CC: core-libs-dev at openjdk.java.net
> >
> > On 12/14/2013 9:38 AM, Peter Levart wrote:
> > > Hi,
> > >
> > > Daniel reminded me of a couple of issues the 4th revision of the 
> patch
> > > would have when backporting to 7u. So here's another variant that
> > > tries to be more backport-friendly:
> > >
> > > 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
> >
> > This looks good in general.
> >
> > SocketHandler line 200 - it looks to me that this is an existing bug
> > that should call setOutputStream within doPrivileged.
> >
> > I think it'd be simpler if SocketHandler no-arg constructor can first
> > get the port and host from the logging properties so that it doesn't
> > need to differentiate hostAndPortSet is set and ConfigureAction no-arg
> > constructor can be removed.
> >
> > Daniel/Peter - do we have tests to cover these permission check for
> > these handlers?
> >
> > Mandy
> >
> > >
> > > This variant could be backported by simply replacing a limited 
> variant
> > > of doPrivileged (introduced in JDK 8) with full variant and still not
> > > elevate the privilege of Socket creation in SocketHandler. I also
> > > removed the need to subclass various ConfigureAction(s) with
> > > annonymous inner subclasses by introducing overloaded constructors to
> > > ConfigureActions(s) that follow the overloaded constructors of 
> various
> > > Handlers.
> > >
> > > Regards, Peter
> > >
> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
> > >> Hi Mandy,
> > >>
> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
> > >>> Hi Peter,
> > >>>
> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
> > >>>> H Mandy,
> > >>>>
> > >>>> I created an issue for it nevertheless:
> > >>>>
> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
> > >>>>
> > >>>> You're right, doPrivileged() is a more straight-forward approach
> > >>>> than 'sealed' variable. Since this might only be considered for
> > >>>> inclusion in JDK9 when lambdas are already a tried technology, how
> > >>>> do you feel about using them for platform code like logging? As 
> far
> > >>>> as I know (just checked), lambda meta-factory is not using any
> > >>>> j.u.logging, so there is no danger of initialization loops or 
> similar:
> > >>>>
> > >>>> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
> > >>>>
> > >>>
> > >>> Sorry for the delay to get to this.
> > >>
> > >> No rush. We have time before JDK9 gets set-up and running...
> > >>
> > >>>
> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
> > >>> PlatformLogger which will forward calls to j.u.logging if
> > >>> -Djava.util.logging.config.file is set or java.util.logging has 
> been
> > >>> initialized (via other j.u.logging call). It means that it may lead
> > >>> to recursive initialization. Also the current PlatformLogger
> > >>> implementation formats the message in the same way as j.u.logging
> > >>> that may load locale providers and other classes. I am afraid there
> > >>> are issues to tease out and resolve.
> > >>
> > >> It's unfortunate that a lambda debugging feature prevents us from
> > >> using a basic language feature in j.u.logging code. As far as I 
> know,
> > >> java.lang.invoke.ProxyClassesDumper is only used if
> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
> > >> point to a directory where lambda proxy class files are to be dumped
> > >> as they are generated - a debugging hook therefore. Wouldn't it be
> > >> good-enough if error messages about not-being able to set-up/use the
> > >> dump facility were output to System.err directly - not using
> > >> PlatformLogger at all?
> > >>
> > >>>
> > >>> The overloads the doPrivileged method makes it cumbersome to use
> > >>> lambda that causes you to workaround it by adding a new
> > >>> PrivilegedVoidAction interface which is clever. So I think it isn't
> > >>> too bad for this patch to use anonymous inner class and have the
> > >>> doPrivileged call in the constructor.
> > >>
> > >> Right. I have prepared a modified webrev which doesn't use lambdas:
> > >>
> > >> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
> > >>
> > >> In attempt to minimize the boilerplate, I haven't just replaced
> > >> lambdas with anonymous inner classes, but rather turned all private
> > >> configure() methods into ConfigureAction inner classes. In two
> > >> occasions (SocketHandler and StreamHandler), they are extended with
> > >> anonymous inner classes to append some actions. In SocketHandler I
> > >> kept the mechanics of transporting the checked IOException out of
> > >> PrivilegedAction by wrapping it with Unchecked IOException and later
> > >> unwrapping and throwing it, rather than using
> > >> PrivilegedExceptionAction which would further complicate exception
> > >> handling, since it declares throwing a general j.l.Exception, but 
> the
> > >> SocketHandler constructor only declares throwing IOException...
> > >>
> > >> I think this could be backported to 7u as-is.
> > >>
> > >> Regards, Peter
> > >>
> > >>>
> > >>>
> > >>> Mandy
> > >>
> > >
> >



From mandy.chung at oracle.com  Tue Dec 17 16:26:04 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Dec 2013 08:26:04 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: 
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
Message-ID: <52B07B1C.80806@oracle.com>

This is a good point.   The patch for JDK 8 and above uses limited 
doPrivileged that only grants LoggingPermission("control") access even 
though the system class has all permissions and it should be no 
difference than the current implementation.   When we backport to 7u, it 
would be an issue.

We shall look into this and it's an existing issue to the current 
implementation.

thanks
Mandy

On 12/17/2013 7:29 AM, Jason Mehrens wrote:
> Handlers can be subclassed.  Is it a security concern when 
> doPrivileged is invoking non-final public/protected methods?  For example,
>
> @Override
> public void setOutputStream(OutputStream out) {
>      LogManager.getLogManager().reset();
> }
>
> @Override
> public void setLevel(Level l) {
>         LogManager.getLogManager().reset();
> }
>
> Jason
>
> > Date: Mon, 16 Dec 2013 13:14:03 -0800
> > From: mandy.chung at oracle.com
> > To: peter.levart at gmail.com
> > Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> > CC: core-libs-dev at openjdk.java.net
> >
> > On 12/14/2013 9:38 AM, Peter Levart wrote:
> > > Hi,
> > >
> > > Daniel reminded me of a couple of issues the 4th revision of the 
> patch
> > > would have when backporting to 7u. So here's another variant that
> > > tries to be more backport-friendly:
> > >
> > > 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
> >
> > This looks good in general.
> >
> > SocketHandler line 200 - it looks to me that this is an existing bug
> > that should call setOutputStream within doPrivileged.
> >
> > I think it'd be simpler if SocketHandler no-arg constructor can first
> > get the port and host from the logging properties so that it doesn't
> > need to differentiate hostAndPortSet is set and ConfigureAction no-arg
> > constructor can be removed.
> >
> > Daniel/Peter - do we have tests to cover these permission check for
> > these handlers?
> >
> > Mandy
> >
> > >
> > > This variant could be backported by simply replacing a limited 
> variant
> > > of doPrivileged (introduced in JDK 8) with full variant and still not
> > > elevate the privilege of Socket creation in SocketHandler. I also
> > > removed the need to subclass various ConfigureAction(s) with
> > > annonymous inner subclasses by introducing overloaded constructors to
> > > ConfigureActions(s) that follow the overloaded constructors of 
> various
> > > Handlers.
> > >
> > > Regards, Peter
> > >
> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
> > >> Hi Mandy,
> > >>
> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
> > >>> Hi Peter,
> > >>>
> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
> > >>>> H Mandy,
> > >>>>
> > >>>> I created an issue for it nevertheless:
> > >>>>
> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
> > >>>>
> > >>>> You're right, doPrivileged() is a more straight-forward approach
> > >>>> than 'sealed' variable. Since this might only be considered for
> > >>>> inclusion in JDK9 when lambdas are already a tried technology, how
> > >>>> do you feel about using them for platform code like logging? As 
> far
> > >>>> as I know (just checked), lambda meta-factory is not using any
> > >>>> j.u.logging, so there is no danger of initialization loops or 
> similar:
> > >>>>
> > >>>> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
> > >>>>
> > >>>
> > >>> Sorry for the delay to get to this.
> > >>
> > >> No rush. We have time before JDK9 gets set-up and running...
> > >>
> > >>>
> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
> > >>> PlatformLogger which will forward calls to j.u.logging if
> > >>> -Djava.util.logging.config.file is set or java.util.logging has 
> been
> > >>> initialized (via other j.u.logging call). It means that it may lead
> > >>> to recursive initialization. Also the current PlatformLogger
> > >>> implementation formats the message in the same way as j.u.logging
> > >>> that may load locale providers and other classes. I am afraid there
> > >>> are issues to tease out and resolve.
> > >>
> > >> It's unfortunate that a lambda debugging feature prevents us from
> > >> using a basic language feature in j.u.logging code. As far as I 
> know,
> > >> java.lang.invoke.ProxyClassesDumper is only used if
> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
> > >> point to a directory where lambda proxy class files are to be dumped
> > >> as they are generated - a debugging hook therefore. Wouldn't it be
> > >> good-enough if error messages about not-being able to set-up/use the
> > >> dump facility were output to System.err directly - not using
> > >> PlatformLogger at all?
> > >>
> > >>>
> > >>> The overloads the doPrivileged method makes it cumbersome to use
> > >>> lambda that causes you to workaround it by adding a new
> > >>> PrivilegedVoidAction interface which is clever. So I think it isn't
> > >>> too bad for this patch to use anonymous inner class and have the
> > >>> doPrivileged call in the constructor.
> > >>
> > >> Right. I have prepared a modified webrev which doesn't use lambdas:
> > >>
> > >> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
> > >>
> > >> In attempt to minimize the boilerplate, I haven't just replaced
> > >> lambdas with anonymous inner classes, but rather turned all private
> > >> configure() methods into ConfigureAction inner classes. In two
> > >> occasions (SocketHandler and StreamHandler), they are extended with
> > >> anonymous inner classes to append some actions. In SocketHandler I
> > >> kept the mechanics of transporting the checked IOException out of
> > >> PrivilegedAction by wrapping it with Unchecked IOException and later
> > >> unwrapping and throwing it, rather than using
> > >> PrivilegedExceptionAction which would further complicate exception
> > >> handling, since it declares throwing a general j.l.Exception, but 
> the
> > >> SocketHandler constructor only declares throwing IOException...
> > >>
> > >> I think this could be backported to 7u as-is.
> > >>
> > >> Regards, Peter
> > >>
> > >>>
> > >>>
> > >>> Mandy
> > >>
> > >
> >



From peter.levart at gmail.com  Tue Dec 17 17:02:19 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Dec 2013 18:02:19 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B07B1C.80806@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com>
Message-ID: <52B0839B.6020006@gmail.com>

On 12/17/2013 05:26 PM, Mandy Chung wrote:
> This is a good point.   The patch for JDK 8 and above uses limited 
> doPrivileged that only grants LoggingPermission("control") access even 
> though the system class has all permissions and it should be no 
> difference than the current implementation.   When we backport to 7u, 
> it would be an issue.

I think it's an issue for limited doPrivileged use too (JDK 8). 
LoggingPermission("control") is a permission used to protect the whole 
logging system. So what was not possible with 'sealed' field would be 
possible with doPermission's temporary elevation of privilege even if it 
is just for LoggingPermission("control").

>
> We shall look into this and it's an existing issue to the current 
> implementation.

I don't think so. The 'sealed' field only pertains to permission checks 
inside the Handler instance - not globally. I think we must fix the bug 
by keeping 'sealed' field. One variant is by having final 'sealed' 
field(s) in each Handler's subclass (as proposed initialy), the other 
would be to replace the primitive boolean sealed field in Handler with:

final AtomicBoolean sealed = new AtomicBoolean(true);

Which one do you prefer?

Regards, Peter

>
> thanks
> Mandy
>
> On 12/17/2013 7:29 AM, Jason Mehrens wrote:
>> Handlers can be subclassed.  Is it a security concern when 
>> doPrivileged is invoking non-final public/protected methods?  For 
>> example,
>>
>> @Override
>> public void setOutputStream(OutputStream out) {
>>      LogManager.getLogManager().reset();
>> }
>>
>> @Override
>> public void setLevel(Level l) {
>>         LogManager.getLogManager().reset();
>> }
>>
>> Jason
>>
>> > Date: Mon, 16 Dec 2013 13:14:03 -0800
>> > From: mandy.chung at oracle.com
>> > To: peter.levart at gmail.com
>> > Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
>> > CC: core-libs-dev at openjdk.java.net
>> >
>> > On 12/14/2013 9:38 AM, Peter Levart wrote:
>> > > Hi,
>> > >
>> > > Daniel reminded me of a couple of issues the 4th revision of the 
>> patch
>> > > would have when backporting to 7u. So here's another variant that
>> > > tries to be more backport-friendly:
>> > >
>> > > 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>> >
>> > This looks good in general.
>> >
>> > SocketHandler line 200 - it looks to me that this is an existing bug
>> > that should call setOutputStream within doPrivileged.
>> >
>> > I think it'd be simpler if SocketHandler no-arg constructor can first
>> > get the port and host from the logging properties so that it doesn't
>> > need to differentiate hostAndPortSet is set and ConfigureAction no-arg
>> > constructor can be removed.
>> >
>> > Daniel/Peter - do we have tests to cover these permission check for
>> > these handlers?
>> >
>> > Mandy
>> >
>> > >
>> > > This variant could be backported by simply replacing a limited 
>> variant
>> > > of doPrivileged (introduced in JDK 8) with full variant and still 
>> not
>> > > elevate the privilege of Socket creation in SocketHandler. I also
>> > > removed the need to subclass various ConfigureAction(s) with
>> > > annonymous inner subclasses by introducing overloaded 
>> constructors to
>> > > ConfigureActions(s) that follow the overloaded constructors of 
>> various
>> > > Handlers.
>> > >
>> > > Regards, Peter
>> > >
>> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
>> > >> Hi Mandy,
>> > >>
>> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>> > >>> Hi Peter,
>> > >>>
>> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>> > >>>> H Mandy,
>> > >>>>
>> > >>>> I created an issue for it nevertheless:
>> > >>>>
>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>> > >>>>
>> > >>>> You're right, doPrivileged() is a more straight-forward approach
>> > >>>> than 'sealed' variable. Since this might only be considered for
>> > >>>> inclusion in JDK9 when lambdas are already a tried technology, 
>> how
>> > >>>> do you feel about using them for platform code like logging? 
>> As far
>> > >>>> as I know (just checked), lambda meta-factory is not using any
>> > >>>> j.u.logging, so there is no danger of initialization loops or 
>> similar:
>> > >>>>
>> > >>>> 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>
>> > >>>>
>> > >>>
>> > >>> Sorry for the delay to get to this.
>> > >>
>> > >> No rush. We have time before JDK9 gets set-up and running...
>> > >>
>> > >>>
>> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>> > >>> PlatformLogger which will forward calls to j.u.logging if
>> > >>> -Djava.util.logging.config.file is set or java.util.logging has 
>> been
>> > >>> initialized (via other j.u.logging call). It means that it may 
>> lead
>> > >>> to recursive initialization. Also the current PlatformLogger
>> > >>> implementation formats the message in the same way as j.u.logging
>> > >>> that may load locale providers and other classes. I am afraid 
>> there
>> > >>> are issues to tease out and resolve.
>> > >>
>> > >> It's unfortunate that a lambda debugging feature prevents us from
>> > >> using a basic language feature in j.u.logging code. As far as I 
>> know,
>> > >> java.lang.invoke.ProxyClassesDumper is only used if
>> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>> > >> point to a directory where lambda proxy class files are to be 
>> dumped
>> > >> as they are generated - a debugging hook therefore. Wouldn't it be
>> > >> good-enough if error messages about not-being able to set-up/use 
>> the
>> > >> dump facility were output to System.err directly - not using
>> > >> PlatformLogger at all?
>> > >>
>> > >>>
>> > >>> The overloads the doPrivileged method makes it cumbersome to use
>> > >>> lambda that causes you to workaround it by adding a new
>> > >>> PrivilegedVoidAction interface which is clever. So I think it 
>> isn't
>> > >>> too bad for this patch to use anonymous inner class and have the
>> > >>> doPrivileged call in the constructor.
>> > >>
>> > >> Right. I have prepared a modified webrev which doesn't use lambdas:
>> > >>
>> > >> 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>> > >>
>> > >> In attempt to minimize the boilerplate, I haven't just replaced
>> > >> lambdas with anonymous inner classes, but rather turned all private
>> > >> configure() methods into ConfigureAction inner classes. In two
>> > >> occasions (SocketHandler and StreamHandler), they are extended with
>> > >> anonymous inner classes to append some actions. In SocketHandler I
>> > >> kept the mechanics of transporting the checked IOException out of
>> > >> PrivilegedAction by wrapping it with Unchecked IOException and 
>> later
>> > >> unwrapping and throwing it, rather than using
>> > >> PrivilegedExceptionAction which would further complicate exception
>> > >> handling, since it declares throwing a general j.l.Exception, 
>> but the
>> > >> SocketHandler constructor only declares throwing IOException...
>> > >>
>> > >> I think this could be backported to 7u as-is.
>> > >>
>> > >> Regards, Peter
>> > >>
>> > >>>
>> > >>>
>> > >>> Mandy
>> > >>
>> > >
>> >
>



From mike.duigou at oracle.com  Tue Dec 17 17:25:23 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 17 Dec 2013 09:25:23 -0800
Subject: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access
	order. (was Why doesn't new Map methods generate entry accesses
	on LinkedHashMap?)
In-Reply-To: <85C4CD55-B0EC-47F8-848A-0311FA943EC6@oracle.com>
References: <77261386538162@web15j.yandex.ru>
	<9EEFC5AC-D87E-4676-9967-E190B0ED5041@oracle.com>
	
	
	
	<042FDEC2-D558-45D7-B416-754055549CA8@oracle.com>
	
	
	<85C4CD55-B0EC-47F8-848A-0311FA943EC6@oracle.com>
Message-ID: 

Noted. Thank you.

Mike

On Dec 17 2013, at 05:51 , Paul Sandoz  wrote:

> 
> On Dec 17, 2013, at 4:42 AM, Mike Duigou  wrote:
> 
>> I've updated the documentation per Paul's suggestions. Specifically, in addition to the existing put() and get() methods the new Map methods
>> 
>> putIfAbsent()
>> getOrDefault()
>> compute()
>> computeIfAbsent()
>> computeIfPresent()
>> merge()
>> 
>> are all documented to perform a single access of the entry (assuming that an entry is created or modified as a result). 
>> 
>> replace()
>> 
>> is documented as accessing the entry, if it exists and a replacement is made. If no replacement is made then no access is recorded.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8029795/2/webrev/
>> 
> 
> Looking good. Just one v. minor thing for:
> 
> + * invocation completes). The {@code replace} method only results in an access
> + * of the entry if the value is replaced.  The {@code putAll} method generates one
> 
> There are two replace methods:
> 
> * invocation completes). The {@code replace} methods only results in an access
> 
> Paul.



From huizhe.wang at oracle.com  Tue Dec 17 17:26:43 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 17 Dec 2013 09:26:43 -0800
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B03F26.8070204@oracle.com>
References: <52AF551F.6070704@oracle.com> <52B03F26.8070204@oracle.com>
Message-ID: <52B08953.4090806@oracle.com>


On 12/17/2013 4:10 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> The fix looks good - though I wonder at whether incrementing
> whiteSpaceLookup by a fix amount wouldn't be better than
> doubling its length.

Both would be okay. The case, as demonstrated in the report, that there 
are hundreds of LFs in an attribute, is very rare.

Best,
Joe

>
> best regards,
>
> -- daniel
>
> On 12/16/13 8:31 PM, huizhe wang wrote:
>> Hi,
>>
>> This is a quick fix for a whitespace buffer that was not adjusted
>> properly in one of the two cases.  The buffer, whiteSpaceLookup, is
>> filled in two cases and adjusted properly the 2nd time. The code is
>> moved into a method storeWhiteSpace so that it's shared for the 1st case
>> as well.
>>
>> Note at line 1175, there is no need to save character 0x20 since all
>> whitespace characters will later be replaced with character 0x20.
>>
>> webrevs:
>> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>>
>> Thanks,
>> Joe
>



From Lance.Andersen at oracle.com  Tue Dec 17 17:42:37 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 17 Dec 2013 12:42:37 -0500
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B08953.4090806@oracle.com>
References: <52AF551F.6070704@oracle.com> <52B03F26.8070204@oracle.com>
	<52B08953.4090806@oracle.com>
Message-ID: <82A28B24-FD9D-4E6E-B3C9-16DB5B102C91@oracle.com>

Joe,

I thought this looked OK also


On Dec 17, 2013, at 12:26 PM, huizhe wang wrote:

> 
> On 12/17/2013 4:10 AM, Daniel Fuchs wrote:
>> Hi Joe,
>> 
>> The fix looks good - though I wonder at whether incrementing
>> whiteSpaceLookup by a fix amount wouldn't be better than
>> doubling its length.
> 
> Both would be okay. The case, as demonstrated in the report, that there are hundreds of LFs in an attribute, is very rare.
> 
> Best,
> Joe
> 
>> 
>> best regards,
>> 
>> -- daniel
>> 
>> On 12/16/13 8:31 PM, huizhe wang wrote:
>>> Hi,
>>> 
>>> This is a quick fix for a whitespace buffer that was not adjusted
>>> properly in one of the two cases.  The buffer, whiteSpaceLookup, is
>>> filled in two cases and adjusted properly the 2nd time. The code is
>>> moved into a method storeWhiteSpace so that it's shared for the 1st case
>>> as well.
>>> 
>>> Note at line 1175, there is no need to save character 0x20 since all
>>> whitespace characters will later be replaced with character 0x20.
>>> 
>>> webrevs:
>>> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>>> 
>>> Thanks,
>>> Joe
>> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From mandy.chung at oracle.com  Tue Dec 17 17:43:07 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Dec 2013 09:43:07 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B0839B.6020006@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
Message-ID: <52B08D2B.7050300@oracle.com>

On 12/17/2013 9:02 AM, Peter Levart wrote:
> On 12/17/2013 05:26 PM, Mandy Chung wrote:
>> This is a good point.   The patch for JDK 8 and above uses limited 
>> doPrivileged that only grants LoggingPermission("control") access 
>> even though the system class has all permissions and it should be no 
>> difference than the current implementation.   When we backport to 7u, 
>> it would be an issue.
>

A typo: I meant s/would/may/ (this requires investigation).

If a method in a handle subclass is invoked within the doPrivileged 
block, the permission will be checked against the protection domain of 
the handler subclass.  If the subclass doesn't have the permission, the 
access should be denied.

> I think it's an issue for limited doPrivileged use too (JDK 8). 
> LoggingPermission("control") is a permission used to protect the whole 
> logging system. So what was not possible with 'sealed' field would be 
> possible with doPermission's temporary elevation of privilege even if 
> it is just for LoggingPermission("control").
>

Can you check what methods are called by the constructors whose access 
are denied in the current implementation but granted in the patch?  I 
have to take another look to make sure but I believe they only calls the 
methods in the handler classes that calls Handler.checkPermission.

Mandy

>>
>> We shall look into this and it's an existing issue to the current 
>> implementation.
>
> I don't think so. The 'sealed' field only pertains to permission 
> checks inside the Handler instance - not globally. I think we must fix 
> the bug by keeping 'sealed' field. One variant is by having final 
> 'sealed' field(s) in each Handler's subclass (as proposed initialy), 
> the other would be to replace the primitive boolean sealed field in 
> Handler with:
>
> final AtomicBoolean sealed = new AtomicBoolean(true);
>
> Which one do you prefer?
>
> Regards, Peter
>
>>
>> thanks
>> Mandy
>>
>> On 12/17/2013 7:29 AM, Jason Mehrens wrote:
>>> Handlers can be subclassed.  Is it a security concern when 
>>> doPrivileged is invoking non-final public/protected methods?  For 
>>> example,
>>>
>>> @Override
>>> public void setOutputStream(OutputStream out) {
>>>      LogManager.getLogManager().reset();
>>> }
>>>
>>> @Override
>>> public void setLevel(Level l) {
>>>         LogManager.getLogManager().reset();
>>> }
>>>
>>> Jason
>>>
>>> > Date: Mon, 16 Dec 2013 13:14:03 -0800
>>> > From: mandy.chung at oracle.com
>>> > To: peter.levart at gmail.com
>>> > Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
>>> > CC: core-libs-dev at openjdk.java.net
>>> >
>>> > On 12/14/2013 9:38 AM, Peter Levart wrote:
>>> > > Hi,
>>> > >
>>> > > Daniel reminded me of a couple of issues the 4th revision of the 
>>> patch
>>> > > would have when backporting to 7u. So here's another variant that
>>> > > tries to be more backport-friendly:
>>> > >
>>> > > 
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>>> >
>>> > This looks good in general.
>>> >
>>> > SocketHandler line 200 - it looks to me that this is an existing bug
>>> > that should call setOutputStream within doPrivileged.
>>> >
>>> > I think it'd be simpler if SocketHandler no-arg constructor can first
>>> > get the port and host from the logging properties so that it doesn't
>>> > need to differentiate hostAndPortSet is set and ConfigureAction 
>>> no-arg
>>> > constructor can be removed.
>>> >
>>> > Daniel/Peter - do we have tests to cover these permission check for
>>> > these handlers?
>>> >
>>> > Mandy
>>> >
>>> > >
>>> > > This variant could be backported by simply replacing a limited 
>>> variant
>>> > > of doPrivileged (introduced in JDK 8) with full variant and 
>>> still not
>>> > > elevate the privilege of Socket creation in SocketHandler. I also
>>> > > removed the need to subclass various ConfigureAction(s) with
>>> > > annonymous inner subclasses by introducing overloaded 
>>> constructors to
>>> > > ConfigureActions(s) that follow the overloaded constructors of 
>>> various
>>> > > Handlers.
>>> > >
>>> > > Regards, Peter
>>> > >
>>> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
>>> > >> Hi Mandy,
>>> > >>
>>> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>> > >>> Hi Peter,
>>> > >>>
>>> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>> > >>>> H Mandy,
>>> > >>>>
>>> > >>>> I created an issue for it nevertheless:
>>> > >>>>
>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>> > >>>>
>>> > >>>> You're right, doPrivileged() is a more straight-forward approach
>>> > >>>> than 'sealed' variable. Since this might only be considered for
>>> > >>>> inclusion in JDK9 when lambdas are already a tried 
>>> technology, how
>>> > >>>> do you feel about using them for platform code like logging? 
>>> As far
>>> > >>>> as I know (just checked), lambda meta-factory is not using any
>>> > >>>> j.u.logging, so there is no danger of initialization loops or 
>>> similar:
>>> > >>>>
>>> > >>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>>
>>> > >>>>
>>> > >>>
>>> > >>> Sorry for the delay to get to this.
>>> > >>
>>> > >> No rush. We have time before JDK9 gets set-up and running...
>>> > >>
>>> > >>>
>>> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>> > >>> PlatformLogger which will forward calls to j.u.logging if
>>> > >>> -Djava.util.logging.config.file is set or java.util.logging 
>>> has been
>>> > >>> initialized (via other j.u.logging call). It means that it may 
>>> lead
>>> > >>> to recursive initialization. Also the current PlatformLogger
>>> > >>> implementation formats the message in the same way as j.u.logging
>>> > >>> that may load locale providers and other classes. I am afraid 
>>> there
>>> > >>> are issues to tease out and resolve.
>>> > >>
>>> > >> It's unfortunate that a lambda debugging feature prevents us from
>>> > >> using a basic language feature in j.u.logging code. As far as I 
>>> know,
>>> > >> java.lang.invoke.ProxyClassesDumper is only used if
>>> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>> > >> point to a directory where lambda proxy class files are to be 
>>> dumped
>>> > >> as they are generated - a debugging hook therefore. Wouldn't it be
>>> > >> good-enough if error messages about not-being able to 
>>> set-up/use the
>>> > >> dump facility were output to System.err directly - not using
>>> > >> PlatformLogger at all?
>>> > >>
>>> > >>>
>>> > >>> The overloads the doPrivileged method makes it cumbersome to use
>>> > >>> lambda that causes you to workaround it by adding a new
>>> > >>> PrivilegedVoidAction interface which is clever. So I think it 
>>> isn't
>>> > >>> too bad for this patch to use anonymous inner class and have the
>>> > >>> doPrivileged call in the constructor.
>>> > >>
>>> > >> Right. I have prepared a modified webrev which doesn't use lambdas:
>>> > >>
>>> > >> 
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>> > >>
>>> > >> In attempt to minimize the boilerplate, I haven't just replaced
>>> > >> lambdas with anonymous inner classes, but rather turned all 
>>> private
>>> > >> configure() methods into ConfigureAction inner classes. In two
>>> > >> occasions (SocketHandler and StreamHandler), they are extended 
>>> with
>>> > >> anonymous inner classes to append some actions. In SocketHandler I
>>> > >> kept the mechanics of transporting the checked IOException out of
>>> > >> PrivilegedAction by wrapping it with Unchecked IOException and 
>>> later
>>> > >> unwrapping and throwing it, rather than using
>>> > >> PrivilegedExceptionAction which would further complicate exception
>>> > >> handling, since it declares throwing a general j.l.Exception, 
>>> but the
>>> > >> SocketHandler constructor only declares throwing IOException...
>>> > >>
>>> > >> I think this could be backported to 7u as-is.
>>> > >>
>>> > >> Regards, Peter
>>> > >>
>>> > >>>
>>> > >>>
>>> > >>> Mandy
>>> > >>
>>> > >
>>> >
>>
>



From joe.darcy at oracle.com  Tue Dec 17 18:26:42 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 17 Dec 2013 18:26:42 +0000
Subject: hg: jdk8/tl/langtools: 8030080: Correct misstatement in JSR 269 MR
	(in javax.lang.model)
Message-ID: <20131217182653.5D48262D69@hg.openjdk.java.net>

Changeset: 6d1f9d1fd585
Author:    darcy
Date:      2013-12-17 10:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6d1f9d1fd585

8030080: Correct misstatement in JSR 269 MR (in javax.lang.model)
Reviewed-by: jfranck

! src/share/classes/javax/lang/model/type/IntersectionType.java
! src/share/classes/javax/lang/model/util/Types.java



From mike.duigou at oracle.com  Tue Dec 17 17:37:38 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 17 Dec 2013 17:37:38 +0000
Subject: hg: jdk8/tl/jdk: 8029795: LinkedHashMap.getOrDefault() doesn't update
	access order.
Message-ID: <20131217173815.6023562D61@hg.openjdk.java.net>

Changeset: 8e133b86b9f8
Author:    mduigou
Date:      2013-12-17 09:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e133b86b9f8

8029795: LinkedHashMap.getOrDefault() doesn't update access order.
Reviewed-by: psandoz

! src/share/classes/java/util/LinkedHashMap.java
! test/java/util/LinkedHashMap/Basic.java



From Ulf.Zibis at CoSoCo.de  Tue Dec 17 19:49:33 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 17 Dec 2013 20:49:33 +0100
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52AF551F.6070704@oracle.com>
References: <52AF551F.6070704@oracle.com>
Message-ID: <52B0AACD.4090909@CoSoCo.de>

Hi Joe,

I would use ?\t? instead of 0x9, to stay consistent with ahead code:
1175                 if (c == ?\t?) {
1176                     storeWhiteSpace(fCurrentEntity.position-1);

Lines 1214..1221 could be simpler:
1214         if (whiteSpaceLen >= whiteSpaceLookup.length) {
1215             int [] tmp = new int[whiteSpaceLookup.length*2];
1216             System.arraycopy(whiteSpaceLookup, 0, tmp, 0, whiteSpaceLookup.length);
1217             whiteSpaceLookup = tmp;
1218         }
1219         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;

Or even shorter:
1214         if (whiteSpaceLen >= whiteSpaceLookup.length)
1215             whiteSpaceLookup = Arrays.copyOf(whiteSpaceLookup, whiteSpaceLookup.length*2);
1216         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;

(please insert spaces around if clause, else and after commas.)

-Ulf


On 16.12.2013 20:31, huizhe wang wrote:
> Hi,
>
> This is a quick fix for a whitespace buffer that was not adjusted properly in one of the two 
> cases.  The buffer, whiteSpaceLookup, is filled in two cases and adjusted properly the 2nd time. 
> The code is moved into a method storeWhiteSpace so that it's shared for the 1st case as well.
>
> Note at line 1175, there is no need to save character 0x20 since all whitespace characters will 
> later be replaced with character 0x20.
>
> webrevs:
> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>
> Thanks,
> Joe
>



From Ulf.Zibis at CoSoCo.de  Tue Dec 17 21:03:32 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 17 Dec 2013 22:03:32 +0100
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B0AACD.4090909@CoSoCo.de>
References: <52AF551F.6070704@oracle.com> <52B0AACD.4090909@CoSoCo.de>
Message-ID: <52B0BC24.6010408@CoSoCo.de>

Also you could increment fCurrentEntity.position at the end of the loop, save 1 "if" and indent 
correctly with 8 spaces:
1166         for (; fCurrentEntity.position Hi Joe,
>
> I would use ?\t? instead of 0x9, to stay consistent with ahead code:
> 1175                 if (c == ?\t?) {
>
> Lines 1214..1221 could be simpler:
> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length) {
> 1215             int [] tmp = new int[whiteSpaceLookup.length*2];
> 1216             System.arraycopy(whiteSpaceLookup, 0, tmp, 0, whiteSpaceLookup.length);
> 1217             whiteSpaceLookup = tmp;
> 1218         }
> 1219         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;
>
> Or even shorter:
> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length)
> 1215             whiteSpaceLookup = Arrays.copyOf(whiteSpaceLookup, whiteSpaceLookup.length*2);
> 1216         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;
>
> (please insert spaces around if clause, else and after commas.)
>
> -Ulf
>
>
> On 16.12.2013 20:31, huizhe wang wrote:
>> Hi,
>>
>> This is a quick fix for a whitespace buffer that was not adjusted properly in one of the two 
>> cases.  The buffer, whiteSpaceLookup, is filled in two cases and adjusted properly the 2nd time. 
>> The code is moved into a method storeWhiteSpace so that it's shared for the 1st case as well.
>>
>> Note at line 1175, there is no need to save character 0x20 since all whitespace characters will 
>> later be replaced with character 0x20.
>>
>> webrevs:
>> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>>
>> Thanks,
>> Joe
>>
>
>



From daniel.fuchs at oracle.com  Tue Dec 17 22:02:13 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Dec 2013 23:02:13 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B0839B.6020006@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>,
	<52AF6D1B.8030409@oracle.com>		<52B07B1C.80806@oracle.com>
	<52B0839B.6020006@gmail.com>
Message-ID: <52B0C9E5.7060506@oracle.com>

On 12/17/13 6:02 PM, Peter Levart wrote:
> On 12/17/2013 05:26 PM, Mandy Chung wrote:
>> This is a good point.   The patch for JDK 8 and above uses limited
>> doPrivileged that only grants LoggingPermission("control") access even
>> though the system class has all permissions and it should be no
>> difference than the current implementation.   When we backport to 7u,
>> it would be an issue.
>
> I think it's an issue for limited doPrivileged use too (JDK 8).
> LoggingPermission("control") is a permission used to protect the whole
> logging system. So what was not possible with 'sealed' field would be
> possible with doPermission's temporary elevation of privilege even if it
> is just for LoggingPermission("control").

Hi Peter,

I don't think that is an issue - because if Handler is subclassed
and the custom subclass attempts to call something requiring
LoggingPermission("control") then the custom subclass will
*still need* to  have the "control" permission  - otherwise a
security exception will be  thrown. This is because the
custom subclass's protection domain will be in the code
path:

- callers call new XxxxHandler
   - XxxxHandler call Handler's super constructor
      - super constructor calls doPrivileged
        - super constructor calls e.g. this.setLevel()
          which is redefined as XxxxHandler.setLevel
          - setLevel calls something else requiring "control"

At this point you have XxxxHandler.class in the code path so
the security manager will check that XxxxHandler.class has the
"control" permission.


>> We shall look into this and it's an existing issue to the current
>> implementation.
>
> I don't think so. The 'sealed' field only pertains to permission checks
> inside the Handler instance - not globally. I think we must fix the bug
> by keeping 'sealed' field. One variant is by having final 'sealed'
> field(s) in each Handler's subclass (as proposed initialy), the other
> would be to replace the primitive boolean sealed field in Handler with:
>
> final AtomicBoolean sealed = new AtomicBoolean(true);

I don't think that would solve anything - it wouldn't prevent
the race condition - would it?

>
> Which one do you prefer?

I think we should fix the potential race condition using
limited doPrivileged in 9. IMHO that does exactly what we
want.

best regards,

-- daniel
>
> Regards, Peter
>
>>
>> thanks
>> Mandy
>>
>> On 12/17/2013 7:29 AM, Jason Mehrens wrote:
>>> Handlers can be subclassed.  Is it a security concern when
>>> doPrivileged is invoking non-final public/protected methods?  For
>>> example,
>>>
>>> @Override
>>> public void setOutputStream(OutputStream out) {
>>>      LogManager.getLogManager().reset();
>>> }
>>>
>>> @Override
>>> public void setLevel(Level l) {
>>>         LogManager.getLogManager().reset();
>>> }
>>>
>>> Jason
>>>
>>> > Date: Mon, 16 Dec 2013 13:14:03 -0800
>>> > From: mandy.chung at oracle.com
>>> > To: peter.levart at gmail.com
>>> > Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
>>> > CC: core-libs-dev at openjdk.java.net
>>> >
>>> > On 12/14/2013 9:38 AM, Peter Levart wrote:
>>> > > Hi,
>>> > >
>>> > > Daniel reminded me of a couple of issues the 4th revision of the
>>> patch
>>> > > would have when backporting to 7u. So here's another variant that
>>> > > tries to be more backport-friendly:
>>> > >
>>> > >
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>>>
>>> >
>>> > This looks good in general.
>>> >
>>> > SocketHandler line 200 - it looks to me that this is an existing bug
>>> > that should call setOutputStream within doPrivileged.
>>> >
>>> > I think it'd be simpler if SocketHandler no-arg constructor can first
>>> > get the port and host from the logging properties so that it doesn't
>>> > need to differentiate hostAndPortSet is set and ConfigureAction no-arg
>>> > constructor can be removed.
>>> >
>>> > Daniel/Peter - do we have tests to cover these permission check for
>>> > these handlers?
>>> >
>>> > Mandy
>>> >
>>> > >
>>> > > This variant could be backported by simply replacing a limited
>>> variant
>>> > > of doPrivileged (introduced in JDK 8) with full variant and still
>>> not
>>> > > elevate the privilege of Socket creation in SocketHandler. I also
>>> > > removed the need to subclass various ConfigureAction(s) with
>>> > > annonymous inner subclasses by introducing overloaded
>>> constructors to
>>> > > ConfigureActions(s) that follow the overloaded constructors of
>>> various
>>> > > Handlers.
>>> > >
>>> > > Regards, Peter
>>> > >
>>> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
>>> > >> Hi Mandy,
>>> > >>
>>> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>> > >>> Hi Peter,
>>> > >>>
>>> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>> > >>>> H Mandy,
>>> > >>>>
>>> > >>>> I created an issue for it nevertheless:
>>> > >>>>
>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>> > >>>>
>>> > >>>> You're right, doPrivileged() is a more straight-forward approach
>>> > >>>> than 'sealed' variable. Since this might only be considered for
>>> > >>>> inclusion in JDK9 when lambdas are already a tried technology,
>>> how
>>> > >>>> do you feel about using them for platform code like logging?
>>> As far
>>> > >>>> as I know (just checked), lambda meta-factory is not using any
>>> > >>>> j.u.logging, so there is no danger of initialization loops or
>>> similar:
>>> > >>>>
>>> > >>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
>>>
>>> > >>>>
>>> > >>>
>>> > >>> Sorry for the delay to get to this.
>>> > >>
>>> > >> No rush. We have time before JDK9 gets set-up and running...
>>> > >>
>>> > >>>
>>> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>> > >>> PlatformLogger which will forward calls to j.u.logging if
>>> > >>> -Djava.util.logging.config.file is set or java.util.logging has
>>> been
>>> > >>> initialized (via other j.u.logging call). It means that it may
>>> lead
>>> > >>> to recursive initialization. Also the current PlatformLogger
>>> > >>> implementation formats the message in the same way as j.u.logging
>>> > >>> that may load locale providers and other classes. I am afraid
>>> there
>>> > >>> are issues to tease out and resolve.
>>> > >>
>>> > >> It's unfortunate that a lambda debugging feature prevents us from
>>> > >> using a basic language feature in j.u.logging code. As far as I
>>> know,
>>> > >> java.lang.invoke.ProxyClassesDumper is only used if
>>> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>> > >> point to a directory where lambda proxy class files are to be
>>> dumped
>>> > >> as they are generated - a debugging hook therefore. Wouldn't it be
>>> > >> good-enough if error messages about not-being able to set-up/use
>>> the
>>> > >> dump facility were output to System.err directly - not using
>>> > >> PlatformLogger at all?
>>> > >>
>>> > >>>
>>> > >>> The overloads the doPrivileged method makes it cumbersome to use
>>> > >>> lambda that causes you to workaround it by adding a new
>>> > >>> PrivilegedVoidAction interface which is clever. So I think it
>>> isn't
>>> > >>> too bad for this patch to use anonymous inner class and have the
>>> > >>> doPrivileged call in the constructor.
>>> > >>
>>> > >> Right. I have prepared a modified webrev which doesn't use lambdas:
>>> > >>
>>> > >>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>>
>>> > >>
>>> > >> In attempt to minimize the boilerplate, I haven't just replaced
>>> > >> lambdas with anonymous inner classes, but rather turned all private
>>> > >> configure() methods into ConfigureAction inner classes. In two
>>> > >> occasions (SocketHandler and StreamHandler), they are extended with
>>> > >> anonymous inner classes to append some actions. In SocketHandler I
>>> > >> kept the mechanics of transporting the checked IOException out of
>>> > >> PrivilegedAction by wrapping it with Unchecked IOException and
>>> later
>>> > >> unwrapping and throwing it, rather than using
>>> > >> PrivilegedExceptionAction which would further complicate exception
>>> > >> handling, since it declares throwing a general j.l.Exception,
>>> but the
>>> > >> SocketHandler constructor only declares throwing IOException...
>>> > >>
>>> > >> I think this could be backported to 7u as-is.
>>> > >>
>>> > >> Regards, Peter
>>> > >>
>>> > >>>
>>> > >>>
>>> > >>> Mandy
>>> > >>
>>> > >
>>> >
>>
>



From roger.riggs at oracle.com  Tue Dec 17 22:35:01 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 17 Dec 2013 17:35:01 -0500
Subject: RFR: simple javadoc cleanup in java.net
Message-ID: <52B0D195.6010206@oracle.com>

Please review, an easy one, just 1 less bug on the queue.

Webrev,
    http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/

Thanks, Roger



From joe.darcy at oracle.com  Tue Dec 17 22:50:47 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 17 Dec 2013 14:50:47 -0800
Subject: RFR: simple javadoc cleanup in java.net
In-Reply-To: <52B0D195.6010206@oracle.com>
References: <52B0D195.6010206@oracle.com>
Message-ID: <52B0D547.8030102@oracle.com>

On 12/17/2013 02:35 PM, roger riggs wrote:
> Please review, an easy one, just 1 less bug on the queue.
>
> Webrev,
>    http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
>
> Thanks, Roger
>

Approved for 9; thanks,

-Joe


From vincent.x.ryan at oracle.com  Tue Dec 17 23:05:05 2013
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Tue, 17 Dec 2013 23:05:05 +0000
Subject: hg: jdk8/tl/jdk: 8029788: Certificate validation -
	java.lang.ClassCastException
Message-ID: <20131217230518.1113E62D7D@hg.openjdk.java.net>

Changeset: 68c31754f925
Author:    vinnie
Date:      2013-12-17 23:03 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68c31754f925

8029788: Certificate validation - java.lang.ClassCastException
Reviewed-by: xuelei, mullan, weijun

! src/share/classes/sun/security/provider/certpath/OCSPResponse.java



From michael.fang at oracle.com  Tue Dec 17 22:16:17 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Tue, 17 Dec 2013 22:16:17 +0000
Subject: hg: jdk8/tl/jdk: 7090826: Newly added codes need to be localized into
	pt_BR in LocaleNames
Message-ID: <20131217221657.38BB562D7A@hg.openjdk.java.net>

Changeset: 4fa27233a3e9
Author:    mfang
Date:      2013-12-17 14:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fa27233a3e9

7090826: Newly added codes need to be localized into pt_BR in LocaleNames
Reviewed-by: okutsu

! 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
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java



From huizhe.wang at oracle.com  Tue Dec 17 23:45:25 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 17 Dec 2013 15:45:25 -0800
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B0BC24.6010408@CoSoCo.de>
References: <52AF551F.6070704@oracle.com> <52B0AACD.4090909@CoSoCo.de>
	<52B0BC24.6010408@CoSoCo.de>
Message-ID: <52B0E215.6000008@oracle.com>

Thanks for the comments. I incorporated the suggested changes.

In terms of code format, for small source files, I would just hit the 
source->format button. For big files like this one, it'd unfortunately 
create too much distraction from real changes.

http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/

Joe

On 12/17/2013 1:03 PM, Ulf Zibis wrote:
> Also you could increment fCurrentEntity.position at the end of the 
> loop, save 1 "if" and indent correctly with 8 spaces:
> 1166         for (; fCurrentEntity.position fCurrentEntity.position++) {
> 1167             c = fCurrentEntity.ch[fCurrentEntity.position];
> 1168             if ((c == quote &&
> 1169                     (!fCurrentEntity.literal || isExternal)) ||
> 1170                     c == '%' || !XMLChar.isContent(c)) {
> 1171                 break;
> 1172             }
> 1173             if (whiteSpaceInfoNeeded && c == ?\t?) {
> 1174                 storeWhiteSpace(fCurrentEntity.position);
> 1175             }
> 1176         }
>
> -Ulf
>
> On 17.12.2013 20:49, Ulf Zibis wrote:
>> Hi Joe,
>>
>> I would use ?\t? instead of 0x9, to stay consistent with ahead code:
>> 1175                 if (c == ?\t?) {
>>
>> Lines 1214..1221 could be simpler:
>> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length) {
>> 1215             int [] tmp = new int[whiteSpaceLookup.length*2];
>> 1216             System.arraycopy(whiteSpaceLookup, 0, tmp, 0, 
>> whiteSpaceLookup.length);
>> 1217             whiteSpaceLookup = tmp;
>> 1218         }
>> 1219         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;
>>
>> Or even shorter:
>> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length)
>> 1215             whiteSpaceLookup = Arrays.copyOf(whiteSpaceLookup, 
>> whiteSpaceLookup.length*2);
>> 1216         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;
>>
>> (please insert spaces around if clause, else and after commas.)
>>
>> -Ulf
>>
>>
>> On 16.12.2013 20:31, huizhe wang wrote:
>>> Hi,
>>>
>>> This is a quick fix for a whitespace buffer that was not adjusted 
>>> properly in one of the two cases.  The buffer, whiteSpaceLookup, is 
>>> filled in two cases and adjusted properly the 2nd time. The code is 
>>> moved into a method storeWhiteSpace so that it's shared for the 1st 
>>> case as well.
>>>
>>> Note at line 1175, there is no need to save character 0x20 since all 
>>> whitespace characters will later be replaced with character 0x20.
>>>
>>> webrevs:
>>> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>>>
>>> Thanks,
>>> Joe
>>>
>>
>>
>



From peter.levart at gmail.com  Tue Dec 17 23:55:44 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Dec 2013 00:55:44 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B0C9E5.7060506@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>,
	<52AF6D1B.8030409@oracle.com>		<52B07B1C.80806@oracle.com>
	<52B0839B.6020006@gmail.com> <52B0C9E5.7060506@oracle.com>
Message-ID: <52B0E480.30402@gmail.com>


On 12/17/2013 11:02 PM, Daniel Fuchs wrote:
> On 12/17/13 6:02 PM, Peter Levart wrote:
>> On 12/17/2013 05:26 PM, Mandy Chung wrote:
>>> This is a good point.   The patch for JDK 8 and above uses limited
>>> doPrivileged that only grants LoggingPermission("control") access even
>>> though the system class has all permissions and it should be no
>>> difference than the current implementation.   When we backport to 7u,
>>> it would be an issue.
>>
>> I think it's an issue for limited doPrivileged use too (JDK 8).
>> LoggingPermission("control") is a permission used to protect the whole
>> logging system. So what was not possible with 'sealed' field would be
>> possible with doPermission's temporary elevation of privilege even if it
>> is just for LoggingPermission("control").
>
> Hi Peter,
>
> I don't think that is an issue - because if Handler is subclassed
> and the custom subclass attempts to call something requiring
> LoggingPermission("control") then the custom subclass will
> *still need* to  have the "control" permission  - otherwise a
> security exception will be  thrown. This is because the
> custom subclass's protection domain will be in the code
> path:
>
> - callers call new XxxxHandler
>   - XxxxHandler call Handler's super constructor
>      - super constructor calls doPrivileged
>        - super constructor calls e.g. this.setLevel()
>          which is redefined as XxxxHandler.setLevel
>          - setLevel calls something else requiring "control"
>
> At this point you have XxxxHandler.class in the code path so
> the security manager will check that XxxxHandler.class has the
> "control" permission.

Ah, I see. Thanks for the explanation. I haven't thought of different 
protection domains. I have studied the AccessControler javadocs and I 
think I understand the behavior now. So there's no problem even if 
unlimited doPrivileged is used, or am I missing something?

But then we have another problem with doPrivileged approach, since it is 
even more restrictive than 'sealed' field approach. Currently the 
Handler's subclass that overrides a setter and calls super, works:


@Override
public void setOutputStream(OutputStream out) {
     super.setOutputStream(out);
}


With doPrivileged wrapping setOutputStream in the superclass 
constructor, it will throw SecurityException if the subclass protection 
domain does not have the "control" permission...

Can this break custom handlers in some environment?


Regards, Peter

>
>>> We shall look into this and it's an existing issue to the current
>>> implementation.
>>
>> I don't think so. The 'sealed' field only pertains to permission checks
>> inside the Handler instance - not globally. I think we must fix the bug
>> by keeping 'sealed' field. One variant is by having final 'sealed'
>> field(s) in each Handler's subclass (as proposed initialy), the other
>> would be to replace the primitive boolean sealed field in Handler with:
>>
>> final AtomicBoolean sealed = new AtomicBoolean(true);
>
> I don't think that would solve anything - it wouldn't prevent
> the race condition - would it?
>
>>
>> Which one do you prefer?
>
> I think we should fix the potential race condition using
> limited doPrivileged in 9. IMHO that does exactly what we
> want.
>
> best regards,
>
> -- daniel
>>
>> Regards, Peter
>>
>>>
>>> thanks
>>> Mandy
>>>
>>> On 12/17/2013 7:29 AM, Jason Mehrens wrote:
>>>> Handlers can be subclassed.  Is it a security concern when
>>>> doPrivileged is invoking non-final public/protected methods?  For
>>>> example,
>>>>
>>>> @Override
>>>> public void setOutputStream(OutputStream out) {
>>>>      LogManager.getLogManager().reset();
>>>> }
>>>>
>>>> @Override
>>>> public void setLevel(Level l) {
>>>>         LogManager.getLogManager().reset();
>>>> }
>>>>
>>>> Jason
>>>>
>>>> > Date: Mon, 16 Dec 2013 13:14:03 -0800
>>>> > From: mandy.chung at oracle.com
>>>> > To: peter.levart at gmail.com
>>>> > Subject: Re: Theoretical data race on 
>>>> java.util.logging.Handler.sealed
>>>> > CC: core-libs-dev at openjdk.java.net
>>>> >
>>>> > On 12/14/2013 9:38 AM, Peter Levart wrote:
>>>> > > Hi,
>>>> > >
>>>> > > Daniel reminded me of a couple of issues the 4th revision of the
>>>> patch
>>>> > > would have when backporting to 7u. So here's another variant that
>>>> > > tries to be more backport-friendly:
>>>> > >
>>>> > >
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/ 
>>>>
>>>>
>>>> >
>>>> > This looks good in general.
>>>> >
>>>> > SocketHandler line 200 - it looks to me that this is an existing bug
>>>> > that should call setOutputStream within doPrivileged.
>>>> >
>>>> > I think it'd be simpler if SocketHandler no-arg constructor can 
>>>> first
>>>> > get the port and host from the logging properties so that it doesn't
>>>> > need to differentiate hostAndPortSet is set and ConfigureAction 
>>>> no-arg
>>>> > constructor can be removed.
>>>> >
>>>> > Daniel/Peter - do we have tests to cover these permission check for
>>>> > these handlers?
>>>> >
>>>> > Mandy
>>>> >
>>>> > >
>>>> > > This variant could be backported by simply replacing a limited
>>>> variant
>>>> > > of doPrivileged (introduced in JDK 8) with full variant and still
>>>> not
>>>> > > elevate the privilege of Socket creation in SocketHandler. I also
>>>> > > removed the need to subclass various ConfigureAction(s) with
>>>> > > annonymous inner subclasses by introducing overloaded
>>>> constructors to
>>>> > > ConfigureActions(s) that follow the overloaded constructors of
>>>> various
>>>> > > Handlers.
>>>> > >
>>>> > > Regards, Peter
>>>> > >
>>>> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
>>>> > >> Hi Mandy,
>>>> > >>
>>>> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>>> > >>> Hi Peter,
>>>> > >>>
>>>> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>> > >>>> H Mandy,
>>>> > >>>>
>>>> > >>>> I created an issue for it nevertheless:
>>>> > >>>>
>>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>> > >>>>
>>>> > >>>> You're right, doPrivileged() is a more straight-forward 
>>>> approach
>>>> > >>>> than 'sealed' variable. Since this might only be considered for
>>>> > >>>> inclusion in JDK9 when lambdas are already a tried technology,
>>>> how
>>>> > >>>> do you feel about using them for platform code like logging?
>>>> As far
>>>> > >>>> as I know (just checked), lambda meta-factory is not using any
>>>> > >>>> j.u.logging, so there is no danger of initialization loops or
>>>> similar:
>>>> > >>>>
>>>> > >>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/ 
>>>>
>>>>
>>>> > >>>>
>>>> > >>>
>>>> > >>> Sorry for the delay to get to this.
>>>> > >>
>>>> > >> No rush. We have time before JDK9 gets set-up and running...
>>>> > >>
>>>> > >>>
>>>> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>>> > >>> PlatformLogger which will forward calls to j.u.logging if
>>>> > >>> -Djava.util.logging.config.file is set or java.util.logging has
>>>> been
>>>> > >>> initialized (via other j.u.logging call). It means that it may
>>>> lead
>>>> > >>> to recursive initialization. Also the current PlatformLogger
>>>> > >>> implementation formats the message in the same way as 
>>>> j.u.logging
>>>> > >>> that may load locale providers and other classes. I am afraid
>>>> there
>>>> > >>> are issues to tease out and resolve.
>>>> > >>
>>>> > >> It's unfortunate that a lambda debugging feature prevents us from
>>>> > >> using a basic language feature in j.u.logging code. As far as I
>>>> know,
>>>> > >> java.lang.invoke.ProxyClassesDumper is only used if
>>>> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>>> > >> point to a directory where lambda proxy class files are to be
>>>> dumped
>>>> > >> as they are generated - a debugging hook therefore. Wouldn't 
>>>> it be
>>>> > >> good-enough if error messages about not-being able to set-up/use
>>>> the
>>>> > >> dump facility were output to System.err directly - not using
>>>> > >> PlatformLogger at all?
>>>> > >>
>>>> > >>>
>>>> > >>> The overloads the doPrivileged method makes it cumbersome to use
>>>> > >>> lambda that causes you to workaround it by adding a new
>>>> > >>> PrivilegedVoidAction interface which is clever. So I think it
>>>> isn't
>>>> > >>> too bad for this patch to use anonymous inner class and have the
>>>> > >>> doPrivileged call in the constructor.
>>>> > >>
>>>> > >> Right. I have prepared a modified webrev which doesn't use 
>>>> lambdas:
>>>> > >>
>>>> > >>
>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/ 
>>>>
>>>>
>>>> > >>
>>>> > >> In attempt to minimize the boilerplate, I haven't just replaced
>>>> > >> lambdas with anonymous inner classes, but rather turned all 
>>>> private
>>>> > >> configure() methods into ConfigureAction inner classes. In two
>>>> > >> occasions (SocketHandler and StreamHandler), they are extended 
>>>> with
>>>> > >> anonymous inner classes to append some actions. In 
>>>> SocketHandler I
>>>> > >> kept the mechanics of transporting the checked IOException out of
>>>> > >> PrivilegedAction by wrapping it with Unchecked IOException and
>>>> later
>>>> > >> unwrapping and throwing it, rather than using
>>>> > >> PrivilegedExceptionAction which would further complicate 
>>>> exception
>>>> > >> handling, since it declares throwing a general j.l.Exception,
>>>> but the
>>>> > >> SocketHandler constructor only declares throwing IOException...
>>>> > >>
>>>> > >> I think this could be backported to 7u as-is.
>>>> > >>
>>>> > >> Regards, Peter
>>>> > >>
>>>> > >>>
>>>> > >>>
>>>> > >>> Mandy
>>>> > >>
>>>> > >
>>>> >
>>>
>>
>



From Ulf.Zibis at CoSoCo.de  Wed Dec 18 01:46:31 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 18 Dec 2013 02:46:31 +0100
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B0E215.6000008@oracle.com>
References: <52AF551F.6070704@oracle.com>
	<52B0AACD.4090909@CoSoCo.de>	<52B0BC24.6010408@CoSoCo.de>
	<52B0E215.6000008@oracle.com>
Message-ID: <52B0FE77.8080006@CoSoCo.de>


On 18.12.2013 00:45, huizhe wang wrote:
> Thanks for the comments. I incorporated the suggested changes.
>
> In terms of code format, for small source files, I would just hit the source->format button. For 
> big files like this one, it'd unfortunately create too much distraction from real changes.
>
> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>
> Joe

Fine.

But: ERROR: Line 1216 should be removed !!!

Why didn't you like this very short version? :

>>> Or even shorter:
>>> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length)
>>> 1215             whiteSpaceLookup = Arrays.copyOf(whiteSpaceLookup, whiteSpaceLookup.length*2);
>>> 1216         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;

Another shortage:

1095             do {
1098                 newlines++;
1099                 fCurrentEntity.lineNumber++;
1100                 fCurrentEntity.columnNumber = 1;
1101                 if (++fCurrentEntity.position == fCurrentEntity.count) {
1102                     invokeListeners(newlines);
1103                     offset = 0;
1104                     fCurrentEntity.position = newlines;
1105                     if (load(newlines, false)) {
1106                         break;
1107                     }
1108                 }
1097                 if (c == '\r') {
1109                     if (fCurrentEntity.ch[fCurrentEntity.position] == '\n') {
1110                         fCurrentEntity.position++;
1111                         offset++;
1112                     }
1113                     /*** NEWLINE NORMALIZATION ***/
1114                     else {
1115                         newlines++;
1116                     }
1118                 } else {
1130                     /*** NEWLINE NORMALIZATION ***
1131                      * if (fCurrentEntity.ch[fCurrentEntity.position] == '\r') {
1133                      *     fCurrentEntity.position++;
1134                      *     offset++;
1135                      * }***/
1137                 }
1096                 c = fCurrentEntity.ch[fCurrentEntity.position];
1141             } while (fCurrentEntity.position < fCurrentEntity.count - 1 && (c == '\n' || c == 
'\r'));
1142
1143             for (int i = offset; i < fCurrentEntity.position; i++) {
1144                 fCurrentEntity.ch[i] = '\n';
1145                 storeWhiteSpace(i);
1146             }


-Ulf



From huizhe.wang at oracle.com  Wed Dec 18 05:18:30 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 17 Dec 2013 21:18:30 -0800
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B0FE77.8080006@CoSoCo.de>
References: <52AF551F.6070704@oracle.com>
	<52B0AACD.4090909@CoSoCo.de>	<52B0BC24.6010408@CoSoCo.de>
	<52B0E215.6000008@oracle.com> <52B0FE77.8080006@CoSoCo.de>
Message-ID: <52B13026.5040307@oracle.com>


>> http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
>>
>> Joe
>
> Fine.
>
> But: ERROR: Line 1216 should be removed !!!

Done, thanks.

>
> Why didn't you like this very short version? :

JAXP currently maintains a code level 1.5 (Apache Xerces at 1.4). While 
we're getting close to the end of JAXP standalone, we may consider 
newer/advanced features in JDK9.  But we'll get to that discussion some 
time later.

>>>> Or even shorter:
>>>> 1214         if (whiteSpaceLen >= whiteSpaceLookup.length)
>>>> 1215             whiteSpaceLookup = Arrays.copyOf(whiteSpaceLookup, 
>>>> whiteSpaceLookup.length*2);
>>>> 1216         whiteSpaceLookup[whiteSpaceLen++] = whiteSpacePos;
>
> Another shortage:

Good catch! I'll remember to apply this cleanup in a separate or related 
patch, for JDK9. For the current issue, I want to keep my promise to RT 
that this is going to be a short and low-risk patch. We have a very 
small window for JDK8.

Thanks,
Joe

>
> 1095             do {
> 1098                 newlines++;
> 1099                 fCurrentEntity.lineNumber++;
> 1100                 fCurrentEntity.columnNumber = 1;
> 1101                 if (++fCurrentEntity.position == 
> fCurrentEntity.count) {
> 1102                     invokeListeners(newlines);
> 1103                     offset = 0;
> 1104                     fCurrentEntity.position = newlines;
> 1105                     if (load(newlines, false)) {
> 1106                         break;
> 1107                     }
> 1108                 }
> 1097                 if (c == '\r') {
> 1109                     if 
> (fCurrentEntity.ch[fCurrentEntity.position] == '\n') {
> 1110                         fCurrentEntity.position++;
> 1111                         offset++;
> 1112                     }
> 1113                     /*** NEWLINE NORMALIZATION ***/
> 1114                     else {
> 1115                         newlines++;
> 1116                     }
> 1118                 } else {
> 1130                     /*** NEWLINE NORMALIZATION ***
> 1131                      * if 
> (fCurrentEntity.ch[fCurrentEntity.position] == '\r') {
> 1133                      *     fCurrentEntity.position++;
> 1134                      *     offset++;
> 1135                      * }***/
> 1137                 }
> 1096                 c = fCurrentEntity.ch[fCurrentEntity.position];
> 1141             } while (fCurrentEntity.position < 
> fCurrentEntity.count - 1 && (c == '\n' || c == '\r'));
> 1142
> 1143             for (int i = offset; i < fCurrentEntity.position; i++) {
> 1144                 fCurrentEntity.ch[i] = '\n';
> 1145                 storeWhiteSpace(i);
> 1146             }
>
>
> -Ulf
>



From lana.steuck at oracle.com  Wed Dec 18 05:21:51 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Dec 2013 05:21:51 +0000
Subject: hg: jdk8/tl/hotspot: 22 new changesets
Message-ID: <20131218052249.88C6762D86@hg.openjdk.java.net>

Changeset: 3aa20cee331a
Author:    amurillo
Date:      2013-12-06 09:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3aa20cee331a

8029693: new hotspot build - hs25-b63
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9a60f4ac6a37
Author:    hseigel
Date:      2013-12-04 08:10 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a60f4ac6a37

8027458: VM anonymous classes: wrong context for protected access checks
Summary: Use the anonymous class's host class for protected access checks
Reviewed-by: acorn, coleenp, lfoltan

! src/share/vm/runtime/reflection.cpp

Changeset: a4f036ef52e8
Author:    sla
Date:      2013-12-04 14:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4f036ef52e8

8029395: SA: jstack throws WrongTypeException
Summary: SA missed some TLABs
Reviewed-by: dsamersoff, mgerdin, brutisso

! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java

Changeset: c586f8a7322f
Author:    mgronlun
Date:      2013-12-05 12:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c586f8a7322f

8028412: AsyncGetCallTrace() is broken on x86 in JDK 7u40
Reviewed-by: kvn, sspitsyn

! src/cpu/x86/vm/frame_x86.cpp

Changeset: 769557390c43
Author:    hseigel
Date:      2013-12-06 11:33 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/769557390c43

8029415: java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java fails on all platforms with hs25-b61
Summary: Check first that a class is not a dynamically-generated bytecode associated with 1.4 reflection implementation, to emitting an ICCE of an invokespecial IMR of a method in an indirect superinterface.
Reviewed-by: acorn, hseigel
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp

Changeset: a150ff9e8efc
Author:    hseigel
Date:      2013-12-06 11:49 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a150ff9e8efc

Merge


Changeset: bf15208b72a5
Author:    mgronlun
Date:      2013-12-08 18:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf15208b72a5

Merge


Changeset: 9fbabcbb875b
Author:    hseigel
Date:      2013-12-10 16:18 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9fbabcbb875b

8028741: Interface Method Resolution should skip static and non-public methods in j.l.Object
Summary: Implementation of JDK 8 JVMS 5.4.3.4 specification change to skip static and non-public methods of java.lang.Object for interface method resolution.
Reviewed-by: acorn, coleenp
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! test/runtime/8024804/RegisterNatives.java

Changeset: 1de8e5356754
Author:    ehelin
Date:      2013-12-09 08:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1de8e5356754

8029326: G1 does not check if threads gets created
Reviewed-by: brutisso, jmasa, jwilhelm

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: ad72068ac41e
Author:    sjohanss
Date:      2013-12-10 10:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad72068ac41e

8028993: Full collections with ParallelScavenge slower in JDK 8 compared to 7u40
Summary: Reducing the number of calls to follow_class_loader to speed up the marking phase. Also removed some unnecessary calls to adjust_klass.
Reviewed-by: stefank, jmasa, mgerdin

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/oops/instanceClassLoaderKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp

Changeset: fa76dce60db7
Author:    stefank
Date:      2013-12-09 10:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa76dce60db7

8029106: JVM crashes in Metachunk::Metachunk during parallel class redefinition (PrivateMLetController, anonymous-simple_copy_1)
Summary: Fixed overflow bug in VirtualSpaceNode::is_available
Reviewed-by: mgerdin, brutisso, coleenp, jmasa

! src/share/vm/memory/metaspace.cpp

Changeset: e3995ab44393
Author:    ehelin
Date:      2013-12-12 16:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3995ab44393

Merge


Changeset: df832bd8edb9
Author:    kvn
Date:      2013-12-06 12:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df832bd8edb9

8028107: Kitchensink crashed with EAV
Summary: check the state of caller and callee nmethods and skip call site patching if any of them is not alive
Reviewed-by: jrose, twisti

! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: b87211e33ebb
Author:    twisti
Date:      2013-12-06 16:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b87211e33ebb

8029366: ShouldNotReachHere error when creating an array with component type of void
Reviewed-by: kvn

! src/share/vm/opto/memnode.cpp
+ test/compiler/reflection/ArrayNewInstanceOfVoid.java

Changeset: ad45ebfba060
Author:    iignatyev
Date:      2013-12-11 01:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad45ebfba060

8028122: [TESTBUG] compiler/regalloc/C1ObjectSpillInLogicOp.java
Reviewed-by: kvn, twisti

! test/compiler/regalloc/C1ObjectSpillInLogicOp.java

Changeset: 62084ffe573b
Author:    iignatyev
Date:      2013-12-11 01:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62084ffe573b

8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException
Reviewed-by: twisti

! test/compiler/7141637/SpreadNullArg.java

Changeset: bc8b01f98ae3
Author:    anoll
Date:      2013-12-12 11:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc8b01f98ae3

Merge


Changeset: fa6d364024c2
Author:    jprovino
Date:      2013-12-11 13:51 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa6d364024c2

8029566: PPC: OrderAccess::load_acquire(julong) is broken
Summary: JFR needs this fix to run on PPC
Reviewed-by: sla, mikael

! src/share/vm/utilities/globalDefinitions_gcc.hpp

Changeset: dc09e905db20
Author:    vladidan
Date:      2013-12-12 17:08 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc09e905db20

Merge


Changeset: 2a21bf819fea
Author:    vladidan
Date:      2013-12-12 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a21bf819fea

Merge


Changeset: 41f4cad94c58
Author:    amurillo
Date:      2013-12-13 09:40 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41f4cad94c58

Merge


Changeset: 5f07ec8bb982
Author:    amurillo
Date:      2013-12-13 09:40 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f07ec8bb982

Added tag hs25-b63 for changeset 41f4cad94c58

! .hgtags



From michael.fang at oracle.com  Wed Dec 18 07:42:21 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 18 Dec 2013 07:42:21 +0000
Subject: hg: jdk8/tl/jdk: 8026741: jdk8 l10n resource file translation update 5
Message-ID: <20131218074355.6148762D8E@hg.openjdk.java.net>

Changeset: 9211877b25ba
Author:    mfang
Date:      2013-12-17 23:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9211877b25ba

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java
! src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
! src/share/classes/sun/security/tools/keytool/Resources_de.java
! src/share/classes/sun/security/tools/keytool/Resources_es.java
! src/share/classes/sun/security/tools/keytool/Resources_fr.java
! src/share/classes/sun/security/tools/keytool/Resources_it.java
! src/share/classes/sun/security/tools/keytool/Resources_ja.java
! src/share/classes/sun/security/tools/keytool/Resources_ko.java
! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/keytool/Resources_sv.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties



From michael.fang at oracle.com  Wed Dec 18 07:45:25 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 18 Dec 2013 07:45:25 +0000
Subject: hg: jdk8/tl/langtools: 8026741: jdk8 l10n resource file translation
	update 5
Message-ID: <20131218074534.5769F62D8F@hg.openjdk.java.net>

Changeset: f1be939b49f6
Author:    mfang
Date:      2013-12-17 23:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f1be939b49f6

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties



From michael.fang at oracle.com  Wed Dec 18 07:40:11 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 18 Dec 2013 07:40:11 +0000
Subject: hg: jdk8/tl/corba: 8026741: jdk8 l10n resource file translation
	update 5
Message-ID: <20131218074015.7372262D8C@hg.openjdk.java.net>

Changeset: eb5d3f8ca0ca
Author:    mfang
Date:      2013-12-17 22:03 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/eb5d3f8ca0ca

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp



From aleksej.efimov at oracle.com  Wed Dec 18 09:43:47 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 18 Dec 2013 13:43:47 +0400
Subject: RFR: 8025051: Update resource files for TimeZone display names
Message-ID: <52B16E53.7090705@oracle.com>

Hi,

Please help to review a fix [1] for 8025051 bug [2]. The following fix 
includes:
  - The translation of time zone generic names were added to all locales.
  - Time Zone names were updated according to the latest translations.
  - Added tz names regression test 
(test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
across all locales. This test compares short/long 
standard/daylight/generic names with translations stored in .properties 
files.
  - Tests updates to address current changes ( 
GenericTimeZoneNamesTest.sh and Bug6317929.java).

The following fix was tested with JPRT build and the 'jdk_util' test set 
succeeded (new test is included in this test set).

[1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8025051



From Ulf.Zibis at CoSoCo.de  Wed Dec 18 10:43:18 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 18 Dec 2013 11:43:18 +0100
Subject: RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
In-Reply-To: <52B13026.5040307@oracle.com>
References: <52AF551F.6070704@oracle.com>	<52B0AACD.4090909@CoSoCo.de>	<52B0BC24.6010408@CoSoCo.de>	<52B0E215.6000008@oracle.com>
	<52B0FE77.8080006@CoSoCo.de> <52B13026.5040307@oracle.com>
Message-ID: <52B17C46.1080808@CoSoCo.de>

On 18.12.2013 06:18, huizhe wang wrote:
>> Why didn't you like this very short version? :
>
> JAXP currently maintains a code level 1.5 (Apache Xerces at 1.4). While we're getting close to the 
> end of JAXP standalone, we may consider newer/advanced features in JDK9.  But we'll get to that 
> discussion some time later.

Thanks for your feedback, I didn't know that and additionally I wasn't aware that Arrays.copyOf is 
so "young".

> Good catch! I'll remember to apply this cleanup in a separate or related patch, for JDK9. For the 
> current issue, I want to keep my promise to RT that this is going to be a short and low-risk 
> patch. We have a very small window for JDK8.

Reasonable!

-Ulf


From daniel.fuchs at oracle.com  Wed Dec 18 11:05:57 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Dec 2013 12:05:57 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B0E480.30402@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>,
	<52AF6D1B.8030409@oracle.com>		<52B07B1C.80806@oracle.com>
	<52B0839B.6020006@gmail.com> <52B0C9E5.7060506@oracle.com>
	<52B0E480.30402@gmail.com>
Message-ID: <52B18195.5020809@oracle.com>

On 12/18/13 12:55 AM, Peter Levart wrote:
>
> On 12/17/2013 11:02 PM, Daniel Fuchs wrote:
>> On 12/17/13 6:02 PM, Peter Levart wrote:
>>> On 12/17/2013 05:26 PM, Mandy Chung wrote:
>>>> This is a good point.   The patch for JDK 8 and above uses limited
>>>> doPrivileged that only grants LoggingPermission("control") access even
>>>> though the system class has all permissions and it should be no
>>>> difference than the current implementation.   When we backport to 7u,
>>>> it would be an issue.
>>>
>>> I think it's an issue for limited doPrivileged use too (JDK 8).
>>> LoggingPermission("control") is a permission used to protect the whole
>>> logging system. So what was not possible with 'sealed' field would be
>>> possible with doPermission's temporary elevation of privilege even if it
>>> is just for LoggingPermission("control").
>>
>> Hi Peter,
>>
>> I don't think that is an issue - because if Handler is subclassed
>> and the custom subclass attempts to call something requiring
>> LoggingPermission("control") then the custom subclass will
>> *still need* to  have the "control" permission  - otherwise a
>> security exception will be  thrown. This is because the
>> custom subclass's protection domain will be in the code
>> path:
>>
>> - callers call new XxxxHandler
>>   - XxxxHandler call Handler's super constructor
>>      - super constructor calls doPrivileged
>>        - super constructor calls e.g. this.setLevel()
>>          which is redefined as XxxxHandler.setLevel
>>          - setLevel calls something else requiring "control"
>>
>> At this point you have XxxxHandler.class in the code path so
>> the security manager will check that XxxxHandler.class has the
>> "control" permission.
>
> Ah, I see. Thanks for the explanation. I haven't thought of different
> protection domains. I have studied the AccessControler javadocs and I
> think I understand the behavior now. So there's no problem even if
> unlimited doPrivileged is used, or am I missing something?
>
> But then we have another problem with doPrivileged approach, since it is
> even more restrictive than 'sealed' field approach. Currently the
> Handler's subclass that overrides a setter and calls super, works:
>
>
> @Override
> public void setOutputStream(OutputStream out) {
>      super.setOutputStream(out);
> }
>
>
> With doPrivileged wrapping setOutputStream in the superclass
> constructor, it will throw SecurityException if the subclass protection
> domain does not have the "control" permission...
>
> Can this break custom handlers in some environment?

Good question. It may yes - but on the other hand, a subclass of
handler that override such methods and call the super.method would
*need* to have the control permission too - wouldn't it?

Otherwise calling these methods when sealed is back to true would
always fail...

best regards,

-- daniel

>
>
> Regards, Peter
>
>>
>>>> We shall look into this and it's an existing issue to the current
>>>> implementation.
>>>
>>> I don't think so. The 'sealed' field only pertains to permission checks
>>> inside the Handler instance - not globally. I think we must fix the bug
>>> by keeping 'sealed' field. One variant is by having final 'sealed'
>>> field(s) in each Handler's subclass (as proposed initialy), the other
>>> would be to replace the primitive boolean sealed field in Handler with:
>>>
>>> final AtomicBoolean sealed = new AtomicBoolean(true);
>>
>> I don't think that would solve anything - it wouldn't prevent
>> the race condition - would it?
>>
>>>
>>> Which one do you prefer?
>>
>> I think we should fix the potential race condition using
>> limited doPrivileged in 9. IMHO that does exactly what we
>> want.
>>
>> best regards,
>>
>> -- daniel
>>>
>>> Regards, Peter
>>>
>>>>
>>>> thanks
>>>> Mandy
>>>>
>>>> On 12/17/2013 7:29 AM, Jason Mehrens wrote:
>>>>> Handlers can be subclassed.  Is it a security concern when
>>>>> doPrivileged is invoking non-final public/protected methods?  For
>>>>> example,
>>>>>
>>>>> @Override
>>>>> public void setOutputStream(OutputStream out) {
>>>>>      LogManager.getLogManager().reset();
>>>>> }
>>>>>
>>>>> @Override
>>>>> public void setLevel(Level l) {
>>>>>         LogManager.getLogManager().reset();
>>>>> }
>>>>>
>>>>> Jason
>>>>>
>>>>> > Date: Mon, 16 Dec 2013 13:14:03 -0800
>>>>> > From: mandy.chung at oracle.com
>>>>> > To: peter.levart at gmail.com
>>>>> > Subject: Re: Theoretical data race on
>>>>> java.util.logging.Handler.sealed
>>>>> > CC: core-libs-dev at openjdk.java.net
>>>>> >
>>>>> > On 12/14/2013 9:38 AM, Peter Levart wrote:
>>>>> > > Hi,
>>>>> > >
>>>>> > > Daniel reminded me of a couple of issues the 4th revision of the
>>>>> patch
>>>>> > > would have when backporting to 7u. So here's another variant that
>>>>> > > tries to be more backport-friendly:
>>>>> > >
>>>>> > >
>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
>>>>>
>>>>>
>>>>> >
>>>>> > This looks good in general.
>>>>> >
>>>>> > SocketHandler line 200 - it looks to me that this is an existing bug
>>>>> > that should call setOutputStream within doPrivileged.
>>>>> >
>>>>> > I think it'd be simpler if SocketHandler no-arg constructor can
>>>>> first
>>>>> > get the port and host from the logging properties so that it doesn't
>>>>> > need to differentiate hostAndPortSet is set and ConfigureAction
>>>>> no-arg
>>>>> > constructor can be removed.
>>>>> >
>>>>> > Daniel/Peter - do we have tests to cover these permission check for
>>>>> > these handlers?
>>>>> >
>>>>> > Mandy
>>>>> >
>>>>> > >
>>>>> > > This variant could be backported by simply replacing a limited
>>>>> variant
>>>>> > > of doPrivileged (introduced in JDK 8) with full variant and still
>>>>> not
>>>>> > > elevate the privilege of Socket creation in SocketHandler. I also
>>>>> > > removed the need to subclass various ConfigureAction(s) with
>>>>> > > annonymous inner subclasses by introducing overloaded
>>>>> constructors to
>>>>> > > ConfigureActions(s) that follow the overloaded constructors of
>>>>> various
>>>>> > > Handlers.
>>>>> > >
>>>>> > > Regards, Peter
>>>>> > >
>>>>> > > On 12/14/2013 12:25 PM, Peter Levart wrote:
>>>>> > >> Hi Mandy,
>>>>> > >>
>>>>> > >> On 12/13/2013 12:37 AM, Mandy Chung wrote:
>>>>> > >>> Hi Peter,
>>>>> > >>>
>>>>> > >>> On 12/8/2013 11:19 AM, Peter Levart wrote:
>>>>> > >>>> H Mandy,
>>>>> > >>>>
>>>>> > >>>> I created an issue for it nevertheless:
>>>>> > >>>>
>>>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8029781
>>>>> > >>>>
>>>>> > >>>> You're right, doPrivileged() is a more straight-forward
>>>>> approach
>>>>> > >>>> than 'sealed' variable. Since this might only be considered for
>>>>> > >>>> inclusion in JDK9 when lambdas are already a tried technology,
>>>>> how
>>>>> > >>>> do you feel about using them for platform code like logging?
>>>>> As far
>>>>> > >>>> as I know (just checked), lambda meta-factory is not using any
>>>>> > >>>> j.u.logging, so there is no danger of initialization loops or
>>>>> similar:
>>>>> > >>>>
>>>>> > >>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
>>>>>
>>>>>
>>>>> > >>>>
>>>>> > >>>
>>>>> > >>> Sorry for the delay to get to this.
>>>>> > >>
>>>>> > >> No rush. We have time before JDK9 gets set-up and running...
>>>>> > >>
>>>>> > >>>
>>>>> > >>> Alan is right that java.lang.invoke.ProxyClassesDumper does use
>>>>> > >>> PlatformLogger which will forward calls to j.u.logging if
>>>>> > >>> -Djava.util.logging.config.file is set or java.util.logging has
>>>>> been
>>>>> > >>> initialized (via other j.u.logging call). It means that it may
>>>>> lead
>>>>> > >>> to recursive initialization. Also the current PlatformLogger
>>>>> > >>> implementation formats the message in the same way as
>>>>> j.u.logging
>>>>> > >>> that may load locale providers and other classes. I am afraid
>>>>> there
>>>>> > >>> are issues to tease out and resolve.
>>>>> > >>
>>>>> > >> It's unfortunate that a lambda debugging feature prevents us from
>>>>> > >> using a basic language feature in j.u.logging code. As far as I
>>>>> know,
>>>>> > >> java.lang.invoke.ProxyClassesDumper is only used if
>>>>> > >> 'jdk.internal.lambda.dumpProxyClasses' system property is set to
>>>>> > >> point to a directory where lambda proxy class files are to be
>>>>> dumped
>>>>> > >> as they are generated - a debugging hook therefore. Wouldn't
>>>>> it be
>>>>> > >> good-enough if error messages about not-being able to set-up/use
>>>>> the
>>>>> > >> dump facility were output to System.err directly - not using
>>>>> > >> PlatformLogger at all?
>>>>> > >>
>>>>> > >>>
>>>>> > >>> The overloads the doPrivileged method makes it cumbersome to use
>>>>> > >>> lambda that causes you to workaround it by adding a new
>>>>> > >>> PrivilegedVoidAction interface which is clever. So I think it
>>>>> isn't
>>>>> > >>> too bad for this patch to use anonymous inner class and have the
>>>>> > >>> doPrivileged call in the constructor.
>>>>> > >>
>>>>> > >> Right. I have prepared a modified webrev which doesn't use
>>>>> lambdas:
>>>>> > >>
>>>>> > >>
>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.04/
>>>>>
>>>>>
>>>>> > >>
>>>>> > >> In attempt to minimize the boilerplate, I haven't just replaced
>>>>> > >> lambdas with anonymous inner classes, but rather turned all
>>>>> private
>>>>> > >> configure() methods into ConfigureAction inner classes. In two
>>>>> > >> occasions (SocketHandler and StreamHandler), they are extended
>>>>> with
>>>>> > >> anonymous inner classes to append some actions. In
>>>>> SocketHandler I
>>>>> > >> kept the mechanics of transporting the checked IOException out of
>>>>> > >> PrivilegedAction by wrapping it with Unchecked IOException and
>>>>> later
>>>>> > >> unwrapping and throwing it, rather than using
>>>>> > >> PrivilegedExceptionAction which would further complicate
>>>>> exception
>>>>> > >> handling, since it declares throwing a general j.l.Exception,
>>>>> but the
>>>>> > >> SocketHandler constructor only declares throwing IOException...
>>>>> > >>
>>>>> > >> I think this could be backported to 7u as-is.
>>>>> > >>
>>>>> > >> Regards, Peter
>>>>> > >>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> Mandy
>>>>> > >>
>>>>> > >
>>>>> >
>>>>
>>>
>>
>



From Alan.Bateman at oracle.com  Wed Dec 18 11:23:23 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Dec 2013 11:23:23 +0000
Subject: RFR: simple javadoc cleanup in java.net
In-Reply-To: <52B0D195.6010206@oracle.com>
References: <52B0D195.6010206@oracle.com>
Message-ID: <52B185AB.6070503@oracle.com>

On 17/12/2013 22:35, roger riggs wrote:
> Please review, an easy one, just 1 less bug on the queue.
>
> Webrev,
>    http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
This looks okay but I think the bug is asking for a link from 
URLStreamHandler#openConnection.

-Alan.


From peter.levart at gmail.com  Wed Dec 18 13:18:58 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Dec 2013 14:18:58 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B18195.5020809@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>,
	<52AF6D1B.8030409@oracle.com>		<52B07B1C.80806@oracle.com>
	<52B0839B.6020006@gmail.com> <52B0C9E5.7060506@oracle.com>
	<52B0E480.30402@gmail.com> <52B18195.5020809@oracle.com>
Message-ID: <52B1A0C2.3080901@gmail.com>

On 12/18/2013 12:05 PM, Daniel Fuchs wrote:
>> But then we have another problem with doPrivileged approach, since it is
>> even more restrictive than 'sealed' field approach. Currently the
>> Handler's subclass that overrides a setter and calls super, works:
>>
>>
>> @Override
>> public void setOutputStream(OutputStream out) {
>>      super.setOutputStream(out);
>> }
>>
>>
>> With doPrivileged wrapping setOutputStream in the superclass
>> constructor, it will throw SecurityException if the subclass protection
>> domain does not have the "control" permission...
>>
>> Can this break custom handlers in some environment?
>
> Good question. It may yes - but on the other hand, a subclass of
> handler that override such methods and call the super.method would
> *need* to have the control permission too - wouldn't it?
>
> Otherwise calling these methods when sealed is back to true would
> always fail...

There might be no need to call the overridden setters after the Handler 
instance is constructed. Apart from "setLevel", Handler setters are only 
called by Handlers themselves in construction phase and by user code... 
If user code doesn't need to call the overridden setters after handlers 
are constructed, user code doesn't need the "control" permission.

But than again, user would *need* to have "control" permission anyway to 
make use of a newly constructed Handler. If all she can do is 
instantiate new Handler instances and not add them to Loggers, what good 
does it make?

Regards, Peter

>
> best regards,
>
> -- daniel 



From peter.levart at gmail.com  Wed Dec 18 13:55:24 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Dec 2013 14:55:24 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B08D2B.7050300@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com>
Message-ID: <52B1A94C.3090103@gmail.com>

On 12/17/2013 06:43 PM, Mandy Chung wrote:
> Can you check what methods are called by the constructors whose access 
> are denied in the current implementation but granted in the patch?  I 
> have to take another look to make sure but I believe they only calls 
> the methods in the handler classes that calls Handler.checkPermission.
>
> Mandy

Methods that are called by various Handler constructors and would be 
elevated by doPrivileged are:
- Handler's own setters, protected by Handler.checkPermission - 
"control" permission required,
- LogManager.getLevelProperty - no special permission required
- LogManager.getFilterProperty - loads class configured in properties 
from system class loader and instantiates it. (since this is done by 
system class - LogManager, no special permission required besides those 
that might be imposed by constructor of the Filter (sub)class)
- LogManager.getFormatterProperty - the same as getFilterProperty
- LogManager.getStringProperty,getIntProperty - no special permission 
required

That's about it. So the only methods that are not known and would be 
elevated by doPrivileged are no-args constructors of Filter and 
Formatter subclasses the names of which are obtained from logging 
properties and which must be loadable by system class loader.


Regards, Peter



From roger.riggs at oracle.com  Wed Dec 18 14:35:46 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 18 Dec 2013 09:35:46 -0500
Subject: RFR: simple javadoc cleanup in java.net
In-Reply-To: <52B185AB.6070503@oracle.com>
References: <52B0D195.6010206@oracle.com> <52B185AB.6070503@oracle.com>
Message-ID: <52B1B2C2.7000409@oracle.com>

Thanks Alan,

I corrected the webrev to link both locations that refer to ProxySelector.
    http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/

Roger

On 12/18/2013 6:23 AM, Alan Bateman wrote:
> On 17/12/2013 22:35, roger riggs wrote:
>> Please review, an easy one, just 1 less bug on the queue.
>>
>> Webrev,
>> http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
> This looks okay but I think the bug is asking for a link from 
> URLStreamHandler#openConnection.
>
> -Alan.



From sergey.lugovoy at oracle.com  Wed Dec 18 14:38:22 2013
From: sergey.lugovoy at oracle.com (Serge)
Date: Wed, 18 Dec 2013 18:38:22 +0400
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <52A1D7A8.5060700@oracle.com>
References: <1664385.xpoWiRqfVs@workland>
	<2118617.k6hklsBbE0@workland>		
	<52A1D7A8.5060700@oracle.com>
Message-ID: <52B1B35E.40209@oracle.com>

Hi all.
Please review the second fix
http://cr.openjdk.java.net/~yan/8029451/webrev.03 

for
https://bugs.openjdk.java.net/browse/JDK-8029451

As suggest Martin, I replaced  "a name=" to "p id="
in java/util/ArrayList.java.
In java/util/zip/package.html I removed the tags "br" and wrapped text 
in tags "p".
This tag due to its padding doesn't gives stick together rows, as required.


On 12/06/2013 05:56 PM, roger riggs wrote:
> +1,
>
> It can be used with any tag (not just 
        , including 
        , 
          , 
        • , 
> 
          , etc.)
>
>
>
> On 12/6/2013 1:09 AM, Martin Buchholz wrote:
>> In jsr166-land we recently started using 
          , which I 
>> recommend,
>> e.g.
>>
>> AbstractQueuedSynchronizer.java:122: * 
          Because checks in
>> acquire are invoked before
>>
>>
>> On Thu, Dec 5, 2013 at 3:22 AM, Paul Sandoz  
>> wrote:
>>
>>> On Dec 5, 2013, at 6:30 AM, Sergey Lugovoy 
>>> wrote:
>>>
>>>> Hi all,
>>>> please review the fix
>>>> http://cr.openjdk.java.net/~yan/8029451/webrev.01/
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8029451
>>>>
>>>> This patch cleanup tidy warnings for generated html documentation, 
>>>> and do
>>>> not affect the appearance of the documentation.
>>>>
>>> The following:
>>>
>>> --- old/src/share/classes/java/util/ArrayList.java 2013-12-04
>>> 17:00:04.849173427 +0000
>>> +++ new/src/share/classes/java/util/ArrayList.java 2013-12-04
>>> 17:00:04.657173433 +0000
>>> @@ -70,9 +70,9 @@
>>>    * unsynchronized access to the list:
          >>>    *   List list = Collections.synchronizedList(new 
>>> ArrayList(...));
          
>>>    *
>>> - * 
          
>>> + * 
           
>>>    * The iterators returned by this class's {@link #iterator() 
>>> iterator} and
>>> - * {@link #listIterator(int) listIterator} methods are
>>> fail-fast:
>>> + * {@link #listIterator(int) listIterator} methods are 
>>> fail-fast:
>>>    * if the list is structurally modified at any time after the 
>>> iterator is
>>>    * created, in any way except through the iterator's own
>>>    * {@link ListIterator#remove() remove} or
>>>
>>> effectively reverts:
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/diff/94e1a4b10811/src/share/classes/java/util/ArrayList.java 
>>>
>>>
>>> Any reason for that? and similar changes to Vector. I don't know 
>>> whether
>>> the addition of text content that is a space perturbs the formatting.
>>>
>>>
>>> ---
>>> old/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java 
>>>
>>>         2013-12-04 17:00:07.793173340 +0000
>>> +++
>>> new/src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java 
>>>
>>>         2013-12-04 17:00:07.637173345 +0000
>>> @@ -80,7 +80,7 @@
>>>    * {@link ReadLock#tryLock()} and {@link WriteLock#tryLock()} methods
>>>    * do not honor this fair setting and will immediately acquire the 
>>> lock
>>>    * if it is possible, regardless of waiting threads.)
>>> - * 
          
>>> + * 
          
>>>    * 
        
>>>
>>> Just remove 
         instead of replacing?
>>>
>>> Paul.
>>>
>



From Alan.Bateman at oracle.com  Wed Dec 18 14:40:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Dec 2013 14:40:56 +0000
Subject: RFR: simple javadoc cleanup in java.net
In-Reply-To: <52B1B2C2.7000409@oracle.com>
References: <52B0D195.6010206@oracle.com> <52B185AB.6070503@oracle.com>
	<52B1B2C2.7000409@oracle.com>
Message-ID: <52B1B3F8.5030602@oracle.com>

On 18/12/2013 14:35, roger riggs wrote:
> Thanks Alan,
>
> I corrected the webrev to link both locations that refer to 
> ProxySelector.
>    http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
Looks good.

-Alan


From tristan.yan at oracle.com  Wed Dec 18 14:51:33 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Wed, 18 Dec 2013 22:51:33 +0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <52A8DA41.1020909@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>	<529FD0A9.9020400@oracle.com>
	<52A7C98E.7000200@oracle.com> <52A8DA41.1020909@oracle.com>
Message-ID: <52B1B675.8090908@oracle.com>

Hi Everyone
Please review the code fix for bug JDK-7168267

http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01/ 


This is a cleanup for RMI tests. trying to use real timeout to replace a 
fixed number of loop.
Thank you

Tristan


On 12/12/2013 05:33 AM, Stuart Marks wrote:
> On 12/10/13 6:10 PM, Tristan Yan wrote:
>> /Hi everyone
>> I am working on bug JDK-7168267
>>
>
> Correct link is
>
> https://bugs.openjdk.java.net/browse/JDK-7168267
>
>> Root Cause:
>> - Per Stuart's comment, this is a clean up bug.
>>
>> Suggested Fix:
>> - Will use timeout to replace loop.
>
> We should probably look at specific cases for this. There are places 
> where the test is waiting for some external service to become ready 
> (e.g., rmiregistry). There's no notification for things like this so 
> wait-with-timeout cannot be used. Pretty much the only thing that can 
> be done is to poll reasonably often until the service is ready, or 
> until the timeout is exceeded.
>
>> - Also I am fixing two test's performance
>> java/rmi/activation/Activatable/forceLogSnapshot - method 
>> waitAllStarted is
>> using sleep to poll 50 restartedObject to be true, we can use modern
>> CountDownLatch to implement blocking-time wait.
>> java/rmi/activation/Activatable/checkAnnotations - We can subclass
>> ByteArrayOutputStream which support notification when data was 
>> written. Also use
>> two thread wait output string and error string to be not null.
>
> These sound reasonble. Go ahead and file sub-tasks for these and then 
> choose one to work on first. (I think it will get too confusing if we 
> try to work on them all simultaneously.) Either post a detailed 
> description of what you intend to do, or if it's simple enough, just 
> post a webrev.
>
> s'marks
>
>>
>> Please let me know if you have any comments or suggestions.
>> / /
>> Thank you
>> Tristan
>>
>> On 12/05/2013 09:02 AM, Stuart Marks wrote:
>> /
>>> /On 12/3/13 11:05 PM, Tristan Yan wrote:
>>> /
>>>> /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. 
>>>> This bug is
>>>> asking performance improvement for RMI test. Because this would 
>>>> involve
>>>> different RMI tests. I?d like to use this cr as an umbrella bug, 
>>>> create sub-cr
>>>> for different test. Then I can make progress on sub-cr. Please let 
>>>> me know your
>>>> opinion on this.
>>>> /
>>> /
>>> Actually JDK-7168267 is more about various test cleanups, and 
>>> JDK-8005436 is
>>> more about performance. Both bugs, though, make general statements 
>>> about "the
>>> RMI tests" and don't have much information about specific actions 
>>> that need to
>>> be taken. I've added some notes to JDK-7168267 about some cleanups 
>>> that could
>>> be done.
>>> / /
>>> If there are specific actions for either of these bugs, then yes, 
>>> creating
>>> Sub-Tasks of these bugs and fixing them individually is the right 
>>> thing to do.
>>> / /
>>> s'marks
>>> /
>> /
>> /



From daniel.fuchs at oracle.com  Wed Dec 18 15:02:21 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Dec 2013 16:02:21 +0100
Subject: RFR: 8030192 - [TEST_BUG] java/util/logging/TestLoggerBundleSync.java
	failed with NPE
Message-ID: <52B1B8FD.5060303@oracle.com>

Hi

Please find below a fix for:

8030192 - [TEST_BUG] java/util/logging/TestLoggerBundleSync.java
           failed with NPE
https://bugs.openjdk.java.net/browse/JDK-8030192


http://cr.openjdk.java.net/~dfuchs/webrev_8030192/webrev.00/


There were two issues in the test:

1. The message that was generated when the test failed
    caused a NPE.

2. The test failed because it didn't hold long enough on
    its logger, which got eagerly gc'ed before the end
    of the test.

I managed to reproduce the issue quite consistently on my machine,
when running the test in a while loop (failed usually after ~10 to
20mins). After changing the test it ran for hours without failing.

I intend to push this fix in JDK 9.

best regards,

-- daniel


From tristan.yan at oracle.com  Wed Dec 18 15:37:02 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Wed, 18 Dec 2013 23:37:02 +0800
Subject: RFR for JDK-8030057: speed up forceLogSnapshot and checkAnnotations
Message-ID: <52B1C11E.4040601@oracle.com>

Hi Everyone

Please help to review the code change for bug JDK-8030057.


http://cr.openjdk.java.net/~tyan/JDK-8030057/webrev.00/ 

Description:

Performance improvement for two RMI tests

java/rmi/activation/Activatable/forceLogSnapshot

method waitAllStarted is using recursive sleep to poll 50 
restartedObject to be true, we can use modern CountDownLatch to 
implement blocking-time wait.

Also suggest shorten waiting time to 5 seconds.

java/rmi/activation/Activatable/checkAnnotations

We can subclass ByteArrayOutputStream which support notification when 
data was written. Also use two thread wait output string and error 
string to be not null

Thank you
Tristan


From roger.riggs at oracle.com  Wed Dec 18 15:43:04 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 18 Dec 2013 10:43:04 -0500
Subject: RFR: 8029451 : Tidy warnings cleanup for java.util package
In-Reply-To: <52B1B35E.40209@oracle.com>
References: <1664385.xpoWiRqfVs@workland>
	<2118617.k6hklsBbE0@workland>		
	<52A1D7A8.5060700@oracle.com> <52B1B35E.40209@oracle.com>
Message-ID: <52B1C288.7030303@oracle.com>

Hi Sergey,

java/util/Vector.java could use the id=xxx idiom instead of 

In java/util/zip/package.html I would omit the extra 
         tags;
the style sheet should be providing the spacing.

The rest looks fine:  (Not a Reviewer)

Roger


On 12/18/2013 9:38 AM, Serge wrote:
> Hi all.
> Please review the second fix
> http://cr.openjdk.java.net/~yan/8029451/webrev.03 
> 
> for
> https://bugs.openjdk.java.net/browse/JDK-8029451
>
> As suggest Martin, I replaced  "a name=" to "p id="
> in java/util/ArrayList.java.
> In java/util/zip/package.html I removed the tags "br" and wrapped text 
> in tags "p".
> This tag due to its padding doesn't gives stick together rows, as 
> required.
>
>
> On 12/06/2013 05:56 PM, roger riggs wrote:
>> +1,
>>
>> It can be used with any tag (not just 
        , including 
        , 
        
>>>>
>>>> Just remove 
         instead of replacing?
>>>>
>>>> Paul.
>>>>
>>
>



From chris.hegarty at oracle.com  Wed Dec 18 16:07:01 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 18 Dec 2013 16:07:01 +0000
Subject: RFR: simple javadoc cleanup in java.net
In-Reply-To: <52B1B2C2.7000409@oracle.com>
References: <52B0D195.6010206@oracle.com> <52B185AB.6070503@oracle.com>
	<52B1B2C2.7000409@oracle.com>
Message-ID: <229B1C43-A6FB-4F31-ADDD-99E9CB6708C7@oracle.com>

On 18 Dec 2013, at 14:35, roger riggs  wrote:

> Thanks Alan,
> 
> I corrected the webrev to link both locations that refer to ProxySelector.
>   http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/

Looks good. Thanks Roger.

-Chris.

> 
> Roger
> 
> On 12/18/2013 6:23 AM, Alan Bateman wrote:
>> On 17/12/2013 22:35, roger riggs wrote:
>>> Please review, an easy one, just 1 less bug on the queue.
>>> 
>>> Webrev,
>>> http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
>> This looks okay but I think the bug is asking for a link from URLStreamHandler#openConnection.
>> 
>> -Alan.
> 



From peter.levart at gmail.com  Wed Dec 18 17:03:49 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Dec 2013 18:03:49 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B08D2B.7050300@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com>
Message-ID: <52B1D575.6010308@gmail.com>

On 12/17/2013 06:43 PM, Mandy Chung wrote:
> Can you check what methods are called by the constructors whose access 
> are denied in the current implementation but granted in the patch?  I 
> have to take another look to make sure but I believe they only calls 
> the methods in the handler classes that calls Handler.checkPermission.
>
> Mandy

Hi Mandy, Daniel,

Here's yet another variant that reduces the doPrivileged code to just 
Handler's setters. This way no LogManager methods are invoked under 
elevated privilege:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.06/

I also factored-out common code into a single package-private 
Handler.configure() method + two package-private getters that provide 
this method with different defaults for different Handler subclasses. 
configure() is in this variant called only in immediate Handler 
subclasses: MemoryHandler & StreamHandler and not in SocketHandler or 
ConsoleHandler. Each property is only set once this way at construction 
time - current code sets each property twice in SocketHandler or 
ConsoleHandler.

SocketHandler's output stream is set with privileged action in both 
cases: whether constructed with configured or specified host/port.


Regards, Peter



From mandy.chung at oracle.com  Wed Dec 18 20:35:21 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Dec 2013 12:35:21 -0800
Subject: RFR:
	java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
	failing again
In-Reply-To: <52B03C17.5040204@oracle.com>
References: <52B03C17.5040204@oracle.com>
Message-ID: <52B20709.6040007@oracle.com>


On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for what I believe is a test bug.
> I plan to push this in JDK 9 dev.
>
> https://bugs.openjdk.java.net/browse/JDK-8030187
>
> This seems to be a very intermittent failure.
> It looks as if a logger held in a local variable can be
> arbitrarily garbage collected if that variable is no longer
> used.
> To prevent arbitrary garbage collection of such loggers, the fix
> makes sure to use the variable again at the end of the test.
>

Looks like running the test in -Xcomp and also with jtreg creates 
pressure to the young gen and more object allocation failure and so 
unreachable objects get collected in the middle of a small method body 
(like in this case).

You added code to reference the local variables referencing the 
loggers.  Would it be simpler to have this test  just to hold a strong 
reference to the logger?

Mandy



> In the event that my analysis were wrong, I have also added
> some debug traces that should help if this test fails again in
> similar situations.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8030187/webrev.00/
>
> best regards,
>
> -- daniel



From mandy.chung at oracle.com  Wed Dec 18 20:43:22 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Dec 2013 12:43:22 -0800
Subject: RFR: 8030192 - [TEST_BUG]
	java/util/logging/TestLoggerBundleSync.java failed with NPE
In-Reply-To: <52B1B8FD.5060303@oracle.com>
References: <52B1B8FD.5060303@oracle.com>
Message-ID: <52B208EA.3050502@oracle.com>


On 12/18/2013 7:02 AM, Daniel Fuchs wrote:
> Hi
>
> Please find below a fix for:
>
> 8030192 - [TEST_BUG] java/util/logging/TestLoggerBundleSync.java
>           failed with NPE
> https://bugs.openjdk.java.net/browse/JDK-8030192
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8030192/webrev.00/
>

The patch looks fine.   This test verifies the case when some loggers 
are GC'ed and thus the logger is kept in a local variable. Nit: typo in 
line 268: s/explicitely/explicitly/.

Mandy


From mandy.chung at oracle.com  Wed Dec 18 22:13:35 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Dec 2013 14:13:35 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B1A94C.3090103@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1A94C.3090103@gmail.com>
Message-ID: <52B21E0F.2040802@oracle.com>


On 12/18/2013 5:55 AM, Peter Levart wrote:
> On 12/17/2013 06:43 PM, Mandy Chung wrote:
>> Can you check what methods are called by the constructors whose 
>> access are denied in the current implementation but granted in the 
>> patch?  I have to take another look to make sure but I believe they 
>> only calls the methods in the handler classes that calls 
>> Handler.checkPermission.
>>
>> Mandy
>
> Methods that are called by various Handler constructors and would be 
> elevated by doPrivileged are:
> - Handler's own setters, protected by Handler.checkPermission - 
> "control" permission required,
> - LogManager.getLevelProperty - no special permission required
> - LogManager.getFilterProperty - loads class configured in properties 
> from system class loader and instantiates it. (since this is done by 
> system class - LogManager, no special permission required besides 
> those that might be imposed by constructor of the Filter (sub)class)
> - LogManager.getFormatterProperty - the same as getFilterProperty
> - LogManager.getStringProperty,getIntProperty - no special permission 
> required
>
> That's about it. So the only methods that are not known and would be 
> elevated by doPrivileged are no-args constructors of Filter and 
> Formatter subclasses the names of which are obtained from logging 
> properties and which must be loadable by system class loader.
>

Thanks Peter.   The use of limited doPrivileged is okay then.

Mandy


From mandy.chung at oracle.com  Wed Dec 18 22:55:30 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Dec 2013 14:55:30 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B1D575.6010308@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
Message-ID: <52B227E2.4000809@oracle.com>


On 12/18/2013 9:03 AM, Peter Levart wrote:
> Hi Mandy, Daniel,
>
> Here's yet another variant that reduces the doPrivileged code to just 
> Handler's setters. This way no LogManager methods are invoked under 
> elevated privilege:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.06/
>

This version looks good.  I like the refactoring to have the subclass to 
call the common code Handler.configure method.  It may be better to have 
the configure method (or a new one) that takes the default Level and 
default Formatter instead of the package-private getters.

I don't see why the handler constructors are designed to call the 
overridden methods rather than the initialization and if a subclass has 
its custom field, it should initialize its custom fields in its 
constructor implementation.    Anyway this would be a separate clean up 
task from this one.

Can you also add a sanity test to verify that these handlers can be 
constructed successfully with a security manager installed?

thanks
Mandy


From lowasser at google.com  Wed Dec 18 23:51:34 2013
From: lowasser at google.com (Louis Wasserman)
Date: Wed, 18 Dec 2013 15:51:34 -0800
Subject: Bug in Long.parseUnsignedLong
Message-ID: 

The Javadoc of Long.parseUnsignedLong specifies that it should throw a
NumberFormatException if "the value represented by the string is larger
than the largest unsigned long, 2^64-1."

This does not appear to be happening:

-- 
Louis Wasserman


From lowasser at google.com  Wed Dec 18 23:52:35 2013
From: lowasser at google.com (Louis Wasserman)
Date: Wed, 18 Dec 2013 15:52:35 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
Message-ID: 

Derp.  Here is the test case:

import java.math.BigInteger;

public class UnsignedLongBug {
  public static void main(String[] args) {
    try {
      String input = "1234567890abcdef1";
      System.out.println(Long.parseUnsignedLong(input, 16));
      BigInteger maxUnsignedLong =
BigInteger.ONE.shiftLeft(64).subtract(BigInteger.ONE);
      BigInteger inputValue = new BigInteger(input, 16);
      System.out.println(maxUnsignedLong.compareTo(inputValue));
      throw new AssertionError();
    } catch (NumberFormatException expected) {
      System.out.println("Correct");
    }
  }
}


On Wed, Dec 18, 2013 at 3:51 PM, Louis Wasserman wrote:

> The Javadoc of Long.parseUnsignedLong specifies that it should throw a
> NumberFormatException if "the value represented by the string is larger
> than the largest unsigned long, 2^64-1."
>
> This does not appear to be happening:
>
> --
> Louis Wasserman
>



-- 
Louis Wasserman


From xuelei.fan at oracle.com  Thu Dec 19 00:47:48 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 19 Dec 2013 00:47:48 +0000
Subject: hg: jdk8/tl/jdk: 7093640: Enable client-side TLS 1.2 by default
Message-ID: <20131219004818.2913462DC3@hg.openjdk.java.net>

Changeset: 8d35f0985dd7
Author:    xuelei
Date:      2013-12-18 16:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d35f0985dd7

7093640: Enable client-side TLS 1.2 by default
Reviewed-by: weijun, mullan, wetmore

! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java



From bhavesh.x.patel at oracle.com  Thu Dec 19 03:50:02 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 19 Dec 2013 03:50:02 +0000
Subject: hg: jdk8/tl/langtools: 8016549: jdk7 javadocs are hard to read
Message-ID: <20131219035007.774AF62DC7@hg.openjdk.java.net>

Changeset: b8ebde062692
Author:    bpatel
Date:      2013-12-18 19:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b8ebde062692

8016549: jdk7 javadocs are hard to read
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! test/com/sun/javadoc/AccessH1/AccessH1.java
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java
! test/tools/javadoc/api/basic/APITest.java



From tristan.yan at oracle.com  Thu Dec 19 06:25:44 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Thu, 19 Dec 2013 14:25:44 +0800
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
Message-ID: <52B29168.9070302@oracle.com>

Hi Everyone

Please help to review the fix for JDK-8030284.

http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/ 


This is a one line fix that add -Xss to prevent StackOverflowError.

Thank you
Tristan


From joe.darcy at oracle.com  Thu Dec 19 07:59:05 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 18 Dec 2013 23:59:05 -0800
Subject: FYI, regression test exclusion as temporary part of JDK_MINOR_VERSION
	increment for JDK 9
Message-ID: <52B2A749.2010400@oracle.com>

Hello,

Already out for review on the build-dev list is a change to increment 
JDK_MINOR_VERSION from 8 to 9 as part of getting JDK 9 underway. 
However, due to HotSpot bug

     JDK-8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp

(also out for review) a number of jdk and langtools regression tests 
fail after the increment. As shown in the patch below, my proposed 
change for incrementing JDK_MINOR_VERSION includes excluding (in one way 
or another) a number of regression tests in the jdk and langtools 
repositories. Since langtools doesn't have a problem list file, I'm 
proposing to @ignore the tests until the HotSpot but is fixed.

Thanks,

-Joe

--- old/common/autoconf/version-numbers    2013-12-18 09:12:06.000000000 
-0800
+++ new/common/autoconf/version-numbers    2013-12-18 09:12:06.000000000 
-0800
@@ -24,7 +24,7 @@
  #

  JDK_MAJOR_VERSION=1
-JDK_MINOR_VERSION=8
+JDK_MINOR_VERSION=9
  JDK_MICRO_VERSION=0
  JDK_UPDATE_VERSION=
  LAUNCHER_NAME=openjdk
--- old/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 
2013-12-18 09:12:07.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 
2013-12-18 09:12:07.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters AnnotationTest.java
--- old/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 
2013-12-18 09:12:07.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 
2013-12-18 09:12:07.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters AnonymousClass.java
--- old/langtools/test/tools/javac/MethodParameters/CaptureTest.java 
2013-12-18 09:12:07.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/CaptureTest.java 
2013-12-18 09:12:07.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8015701
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary Test method parameter attribute generation with captured 
locals.
   * @compile -parameters CaptureTest.java
   * @run main CaptureTest
--- old/langtools/test/tools/javac/MethodParameters/Constructors.java 
2013-12-18 09:12:08.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/Constructors.java 
2013-12-18 09:12:08.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters Constructors.java
--- old/langtools/test/tools/javac/MethodParameters/EnumTest.java 
2013-12-18 09:12:08.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/EnumTest.java 
2013-12-18 09:12:08.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582 8008658
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters EnumTest.java
--- old/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 
2013-12-18 09:12:09.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 
2013-12-18 09:12:09.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters InstanceMethods.java
--- old/langtools/test/tools/javac/MethodParameters/LambdaTest.java 
2013-12-18 09:12:09.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/LambdaTest.java 
2013-12-18 09:12:09.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters LambdaTest.java
--- old/langtools/test/tools/javac/MethodParameters/LocalClassTest.java 
2013-12-18 09:12:09.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/LocalClassTest.java 
2013-12-18 09:12:09.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582 8008658
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters LocalClassTest.java
--- old/langtools/test/tools/javac/MethodParameters/MemberClassTest.java 
2013-12-18 09:12:10.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/MemberClassTest.java 
2013-12-18 09:12:10.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582 8008658
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters MemberClassTest.java
--- old/langtools/test/tools/javac/MethodParameters/StaticMethods.java 
2013-12-18 09:12:10.000000000 -0800
+++ new/langtools/test/tools/javac/MethodParameters/StaticMethods.java 
2013-12-18 09:12:10.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters StaticMethods.java
--- 
old/langtools/test/tools/javac/MethodParameters/UncommonParamNames.java 
2013-12-18 09:12:10.000000000 -0800
+++ 
new/langtools/test/tools/javac/MethodParameters/UncommonParamNames.java 
2013-12-18 09:12:10.000000000 -0800
@@ -24,6 +24,7 @@
  /*
   * @test
   * @bug 8006582
+ * @ignore 8030656 Bad version check for parameter information in 
src/share/vm/classfile/javaClasses.cpp
   * @summary javac should generate method parameters correctly.
   * @build Tester
   * @compile -parameters UncommonParamNames.java
--- old/jdk/test/ProblemList.txt    2013-12-18 09:12:11.000000000 -0800
+++ new/jdk/test/ProblemList.txt    2013-12-18 09:12:11.000000000 -0800
@@ -123,6 +123,11 @@
  # 8029415
  java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java 
generic-all

+# 8030656
+java/lang/reflect/Parameter/GetAnnotatedTypeTest.java generic-all
+java/lang/reflect/Parameter/WithParameters.java generic-all
+java/lang/reflect/Parameter/BadClassFiles.java generic-all
+
  ############################################################################

  # jdk_management



From masayoshi.okutsu at oracle.com  Thu Dec 19 08:04:54 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 19 Dec 2013 17:04:54 +0900
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B16E53.7090705@oracle.com>
References: <52B16E53.7090705@oracle.com>
Message-ID: <52B2A8A6.4020903@oracle.com>

On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
> Hi,
>
> Please help to review a fix [1] for 8025051 bug [2]. The following fix 
> includes:

Common to all modified files:
- All year ranges in the copyright header should be modified accordingly.

>  - The translation of time zone generic names were added to all locales.

I haven't fully reviewed translations, especially all \uxxxx strings. 
But I noticed the following.

Common to all TimeZoneNames_*.java:
- The same generic abbreviation is used for the long name in MET. I 
thought this was fixed in the root properties...
- Some generic names don't match the style of their standard and/or 
daylight time names.

src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
- Some generic names use "Normalzeit". Is that OK?

src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
- "Chuuk Time" isn't translated.

>  - Time Zone names were updated according to the latest translations.
>  - Added tz names regression test 
> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
> across all locales. This test compares short/long 
> standard/daylight/generic names with translations stored in 
> .properties files.

test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:

- lines 33, 34: unused imports?
- line 75: Should it be detected as an error?
- line 108: IOException should be used as a cause. (OK to assume "not 
found"?)
- lines 118 -121: Locale.getDefault() has to be replaced with 
Locale.ROOT. Regression tests are run in different locales.

>  - Tests updates to address current changes ( 
> GenericTimeZoneNamesTest.sh and Bug6317929.java).

The TODO comment in GenericTimeZoneNamesTest.sh should fully been removed.

>
> The following fix was tested with JPRT build and the 'jdk_util' test 
> set succeeded (new test is included in this test set).

Have you executed all date-time related regression tests (including 
java.time and java.text)?

Thanks,
Masayoshi

>
> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>



From chris.hegarty at oracle.com  Thu Dec 19 09:05:27 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Dec 2013 09:05:27 +0000
Subject: FYI,
	regression test exclusion as temporary part of JDK_MINOR_VERSION
	increment for JDK 9
In-Reply-To: <52B2A749.2010400@oracle.com>
References: <52B2A749.2010400@oracle.com>
Message-ID: <989327E0-9C2B-426E-828A-04BED0F29CA0@oracle.com>

Looks good to me Joe.

This change, to me at least, demonstrates the power of the ProblemList.txt. It is a really useful mechanism.

-Chris.

On 19 Dec 2013, at 07:59, Joe Darcy  wrote:

> Hello,
> 
> Already out for review on the build-dev list is a change to increment JDK_MINOR_VERSION from 8 to 9 as part of getting JDK 9 underway. However, due to HotSpot bug
> 
>    JDK-8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
> 
> (also out for review) a number of jdk and langtools regression tests fail after the increment. As shown in the patch below, my proposed change for incrementing JDK_MINOR_VERSION includes excluding (in one way or another) a number of regression tests in the jdk and langtools repositories. Since langtools doesn't have a problem list file, I'm proposing to @ignore the tests until the HotSpot but is fixed.
> 
> Thanks,
> 
> -Joe
> 
> --- old/common/autoconf/version-numbers    2013-12-18 09:12:06.000000000 -0800
> +++ new/common/autoconf/version-numbers    2013-12-18 09:12:06.000000000 -0800
> @@ -24,7 +24,7 @@
> #
> 
> JDK_MAJOR_VERSION=1
> -JDK_MINOR_VERSION=8
> +JDK_MINOR_VERSION=9
> JDK_MICRO_VERSION=0
> JDK_UPDATE_VERSION=
> LAUNCHER_NAME=openjdk
> --- old/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/AnnotationTest.java 2013-12-18 09:12:07.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters AnnotationTest.java
> --- old/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/AnonymousClass.java 2013-12-18 09:12:07.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters AnonymousClass.java
> --- old/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/CaptureTest.java 2013-12-18 09:12:07.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8015701
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary Test method parameter attribute generation with captured locals.
>  * @compile -parameters CaptureTest.java
>  * @run main CaptureTest
> --- old/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/Constructors.java 2013-12-18 09:12:08.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters Constructors.java
> --- old/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/EnumTest.java 2013-12-18 09:12:08.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582 8008658
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters EnumTest.java
> --- old/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 2013-12-18 09:12:09.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/InstanceMethods.java 2013-12-18 09:12:09.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters InstanceMethods.java
> --- old/langtools/test/tools/javac/MethodParameters/LambdaTest.java 2013-12-18 09:12:09.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/LambdaTest.java 2013-12-18 09:12:09.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters LambdaTest.java
> --- old/langtools/test/tools/javac/MethodParameters/LocalClassTest.java 2013-12-18 09:12:09.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/LocalClassTest.java 2013-12-18 09:12:09.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582 8008658
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters LocalClassTest.java
> --- old/langtools/test/tools/javac/MethodParameters/MemberClassTest.java 2013-12-18 09:12:10.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/MemberClassTest.java 2013-12-18 09:12:10.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582 8008658
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters MemberClassTest.java
> --- old/langtools/test/tools/javac/MethodParameters/StaticMethods.java 2013-12-18 09:12:10.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/StaticMethods.java 2013-12-18 09:12:10.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters StaticMethods.java
> --- old/langtools/test/tools/javac/MethodParameters/UncommonParamNames.java 2013-12-18 09:12:10.000000000 -0800
> +++ new/langtools/test/tools/javac/MethodParameters/UncommonParamNames.java 2013-12-18 09:12:10.000000000 -0800
> @@ -24,6 +24,7 @@
> /*
>  * @test
>  * @bug 8006582
> + * @ignore 8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp
>  * @summary javac should generate method parameters correctly.
>  * @build Tester
>  * @compile -parameters UncommonParamNames.java
> --- old/jdk/test/ProblemList.txt    2013-12-18 09:12:11.000000000 -0800
> +++ new/jdk/test/ProblemList.txt    2013-12-18 09:12:11.000000000 -0800
> @@ -123,6 +123,11 @@
> # 8029415
> java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java generic-all
> 
> +# 8030656
> +java/lang/reflect/Parameter/GetAnnotatedTypeTest.java generic-all
> +java/lang/reflect/Parameter/WithParameters.java generic-all
> +java/lang/reflect/Parameter/BadClassFiles.java generic-all
> +
> ############################################################################
> 
> # jdk_management
> 



From david.holmes at oracle.com  Thu Dec 19 10:13:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Dec 2013 20:13:48 +1000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <529EEF4B.4000103@oracle.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
	<529EEF4B.4000103@oracle.com>
Message-ID: <52B2C6DC.6050708@oracle.com>

On 4/12/2013 7:00 PM, Alan Bateman wrote:
> On 04/12/2013 08:24, Jeroen Frijters wrote:
>> Hi,
>>
>> I'd like to propose to change Class.checkInitted() to check if the VM
>> initialization has completed by using sun.misc.VM.isBooted() instead
>> of System.out != null.
> This should be changed (I can only guess that whoever added this wasn't
> aware of VM.isBooted).

Not necessarily. The question is, are there any code paths that lead to 
checkInitted being called after  setOut0(newPrintStream(fdOut, 
props.getProperty("sun.stdout.encoding"))) but before the call to 
sun.misc.VM.booted(). If so these would fail under the proposed change.

The initialization sequence is fragile and intimately tied to the 
Hotspot VM - ie the VM initialization process initiates the core class 
initialization. In a "normal" initialization System is initialized 
before Class and Class must be initialized before checkInitted can be 
called, so this doesn't trigger initialization of System.

I also don't see how System.out being null can be valid 
post-initialization state given the call to 
setOut0(newPrintStream(fdOut, props.getProperty("sun.stdout.encoding")))

David
-----

> -Alan.
>


From daniel.fuchs at oracle.com  Thu Dec 19 11:04:42 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Dec 2013 12:04:42 +0100
Subject: RFR:
	java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
	failing again
In-Reply-To: <52B20709.6040007@oracle.com>
References: <52B03C17.5040204@oracle.com> <52B20709.6040007@oracle.com>
Message-ID: <52B2D2CA.1010907@oracle.com>

On 12/18/13 9:35 PM, Mandy Chung wrote:
>
> On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a fix for what I believe is a test bug.
>> I plan to push this in JDK 9 dev.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8030187
>>
>> This seems to be a very intermittent failure.
>> It looks as if a logger held in a local variable can be
>> arbitrarily garbage collected if that variable is no longer
>> used.
>> To prevent arbitrary garbage collection of such loggers, the fix
>> makes sure to use the variable again at the end of the test.
>>
>
> Looks like running the test in -Xcomp and also with jtreg creates
> pressure to the young gen and more object allocation failure and so
> unreachable objects get collected in the middle of a small method body
> (like in this case).
>
> You added code to reference the local variables referencing the
> loggers.  Would it be simpler to have this test  just to hold a strong
> reference to the logger?

Hmmm. I don't think it would be simpler. I could have added an
array list of loggers and cleared that at the end of the test.
It would just have been another way of making sure that the
loggers weren't gc'ed.

-- daniel


>
> Mandy
>
>
>
>> In the event that my analysis were wrong, I have also added
>> some debug traces that should help if this test fails again in
>> similar situations.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8030187/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>



From jeroen at sumatra.nl  Thu Dec 19 11:19:16 2013
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Thu, 19 Dec 2013 11:19:16 +0000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <52B2C6DC.6050708@oracle.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
	<529EEF4B.4000103@oracle.com> <52B2C6DC.6050708@oracle.com>
Message-ID: <2818b919cc8b4955a1f22abc3afb10bf@mane.sumatrasoftware.com>

System.out can be null, because System.setOut(null) is legal.

Regards,
Jeroen

> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Thursday, December 19, 2013 11:14
> To: Alan Bateman
> Cc: Jeroen Frijters; core-libs-dev at openjdk.java.net
> Subject: Re: Request: Remove System.out check from Class.checkInitted()
> 
> On 4/12/2013 7:00 PM, Alan Bateman wrote:
> > On 04/12/2013 08:24, Jeroen Frijters wrote:
> >> Hi,
> >>
> >> I'd like to propose to change Class.checkInitted() to check if the VM
> >> initialization has completed by using sun.misc.VM.isBooted() instead
> >> of System.out != null.
> > This should be changed (I can only guess that whoever added this
> > wasn't aware of VM.isBooted).
> 
> Not necessarily. The question is, are there any code paths that lead to
> checkInitted being called after  setOut0(newPrintStream(fdOut,
> props.getProperty("sun.stdout.encoding"))) but before the call to
> sun.misc.VM.booted(). If so these would fail under the proposed change.
> 
> The initialization sequence is fragile and intimately tied to the
> Hotspot VM - ie the VM initialization process initiates the core class
> initialization. In a "normal" initialization System is initialized
> before Class and Class must be initialized before checkInitted can be
> called, so this doesn't trigger initialization of System.
> 
> I also don't see how System.out being null can be valid post-
> initialization state given the call to setOut0(newPrintStream(fdOut,
> props.getProperty("sun.stdout.encoding")))
> 
> David
> -----
> 
> > -Alan.
> >


From david.holmes at oracle.com  Thu Dec 19 11:53:18 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Dec 2013 21:53:18 +1000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <2818b919cc8b4955a1f22abc3afb10bf@mane.sumatrasoftware.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
	<529EEF4B.4000103@oracle.com> <52B2C6DC.6050708@oracle.com>
	<2818b919cc8b4955a1f22abc3afb10bf@mane.sumatrasoftware.com>
Message-ID: <52B2DE2E.5030200@oracle.com>

On 19/12/2013 9:19 PM, Jeroen Frijters wrote:
> System.out can be null, because System.setOut(null) is legal.

Ah I see. That isn't an initialization issue but a post-initialization 
issue.

Thanks,
David

> Regards,
> Jeroen
>
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Thursday, December 19, 2013 11:14
>> To: Alan Bateman
>> Cc: Jeroen Frijters; core-libs-dev at openjdk.java.net
>> Subject: Re: Request: Remove System.out check from Class.checkInitted()
>>
>> On 4/12/2013 7:00 PM, Alan Bateman wrote:
>>> On 04/12/2013 08:24, Jeroen Frijters wrote:
>>>> Hi,
>>>>
>>>> I'd like to propose to change Class.checkInitted() to check if the VM
>>>> initialization has completed by using sun.misc.VM.isBooted() instead
>>>> of System.out != null.
>>> This should be changed (I can only guess that whoever added this
>>> wasn't aware of VM.isBooted).
>>
>> Not necessarily. The question is, are there any code paths that lead to
>> checkInitted being called after  setOut0(newPrintStream(fdOut,
>> props.getProperty("sun.stdout.encoding"))) but before the call to
>> sun.misc.VM.booted(). If so these would fail under the proposed change.
>>
>> The initialization sequence is fragile and intimately tied to the
>> Hotspot VM - ie the VM initialization process initiates the core class
>> initialization. In a "normal" initialization System is initialized
>> before Class and Class must be initialized before checkInitted can be
>> called, so this doesn't trigger initialization of System.
>>
>> I also don't see how System.out being null can be valid post-
>> initialization state given the call to setOut0(newPrintStream(fdOut,
>> props.getProperty("sun.stdout.encoding")))
>>
>> David
>> -----
>>
>>> -Alan.
>>>


From Alan.Bateman at oracle.com  Thu Dec 19 11:59:10 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Dec 2013 11:59:10 +0000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <52B2C6DC.6050708@oracle.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
	<529EEF4B.4000103@oracle.com> <52B2C6DC.6050708@oracle.com>
Message-ID: <52B2DF8E.6020202@oracle.com>

On 19/12/2013 10:13, David Holmes wrote:
>
> Not necessarily. The question is, are there any code paths that lead 
> to checkInitted being called after  setOut0(newPrintStream(fdOut, 
> props.getProperty("sun.stdout.encoding"))) but before the call to 
> sun.misc.VM.booted(). If so these would fail under the proposed change.
>
> The initialization sequence is fragile and intimately tied to the 
> Hotspot VM - ie the VM initialization process initiates the core class 
> initialization. In a "normal" initialization System is initialized 
> before Class and Class must be initialized before checkInitted can be 
> called, so this doesn't trigger initialization of System.
>
> I also don't see how System.out being null can be valid 
> post-initialization state given the call to 
> setOut0(newPrintStream(fdOut, props.getProperty("sun.stdout.encoding")))
It would be unusual to change it later with System.setOut but it is 
possible.

In any case, using VM.isBooted is the normal way to check if system 
initialization has completed.

-Alan.


From dl at cs.oswego.edu  Thu Dec 19 12:04:08 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 19 Dec 2013 07:04:08 -0500
Subject: New default for ForkJoinPool.commonPool on systems with
	SecurityManagers
Message-ID: <52B2E0B8.3040708@cs.oswego.edu>

[Cross-posting on core-libs-dev and concurrency-interest.]

The ForkJoinPool common pool is used in JDK8 for
all parallel Stream operations, parallel sorting, etc.
When designing this, we knew that in some managed environments,
administrators might want to limit or disable parallelism,
so we support a way to do so using system property
java.util.concurrent.ForkJoinPool.common.parallelism.

But we hadn't provided a way to allow only "innocuous" parallelism;
performed by worker threads that are happy to help sort
data etc, but cannot do anything (like open a file) that
needs a Permission. We allowed people to create a special
ForkJoinWorkerThreadFactory and use for the default via property
java.util.concurrent.ForkJoinPool.common.threadFactory.
But it is not at all easy for people running Java EE and other
managed platforms to define a suitable factory.

So we added an extra-conservative safe-out-of-the-box default:
If not already overridden by system properties,
and a SecurityManager is present, the default is now
to use instances of an internal (non-public)
InnocuousForkJoinWorkerThread class. Each worker
has no Permssions set, is not a member of any user-defined
ThreadGroup, and erases all ThreadLocals after running
any externally-submitted task.

Thanks especially to Chris Hegarty and Alan Bateman for helping
to figure out what "innocuous" should entail.

Even though it is running very late in the release process,
this seems like such a good idea that we hope to get it
in for JDK8. The internal mechanics to  support this currently
require  quite a lot of encapsulation breakage.
Someday we might want to try to generalize the idea of
innocuous threads in a way that could be more tastefully supported.

This is currently committed in 166 CVS, and Chris Hegarty will
soon put out a webrev for OpenJDK.

This support was also added to the jsr166e version so people can
also experiment with it even if not yet able to use JDK8.
Although I believe that this will only work if jsr166e.jar
is in bootclasspath.

Also note that extra-paranoid and/or mean-spirited
administrators can still disable all parallelism.

-Doug




From david.holmes at oracle.com  Thu Dec 19 12:06:06 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Dec 2013 22:06:06 +1000
Subject: Request: Remove System.out check from Class.checkInitted()
In-Reply-To: <52B2DF8E.6020202@oracle.com>
References: <18a57ff5289e4af9bd80166fbe44e1c4@mane.sumatrasoftware.com>
	<529EEF4B.4000103@oracle.com> <52B2C6DC.6050708@oracle.com>
	<52B2DF8E.6020202@oracle.com>
Message-ID: <52B2E12E.3040908@oracle.com>

On 19/12/2013 9:59 PM, Alan Bateman wrote:
> On 19/12/2013 10:13, David Holmes wrote:
>>
>> Not necessarily. The question is, are there any code paths that lead
>> to checkInitted being called after  setOut0(newPrintStream(fdOut,
>> props.getProperty("sun.stdout.encoding"))) but before the call to
>> sun.misc.VM.booted(). If so these would fail under the proposed change.
>>
>> The initialization sequence is fragile and intimately tied to the
>> Hotspot VM - ie the VM initialization process initiates the core class
>> initialization. In a "normal" initialization System is initialized
>> before Class and Class must be initialized before checkInitted can be
>> called, so this doesn't trigger initialization of System.
>>
>> I also don't see how System.out being null can be valid
>> post-initialization state given the call to
>> setOut0(newPrintStream(fdOut, props.getProperty("sun.stdout.encoding")))
> It would be unusual to change it later with System.setOut but it is
> possible.
>
> In any case, using VM.isBooted is the normal way to check if system
> initialization has completed.

Yes but it may not be sufficient in this case. As I said we have to be 
sure checkInitted can not be called by anything between the setting of 
out to non-null and the call to booted().

David

> -Alan.


From tristan.yan at oracle.com  Thu Dec 19 12:16:37 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Thu, 19 Dec 2013 20:16:37 +0800
Subject: Demo for Parallel Core Collection API
In-Reply-To: <36B4EDF7-15DE-482C-AFB7-511A03BCDC92@oracle.com>
References: 
	<2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com>
	
	<36B4EDF7-15DE-482C-AFB7-511A03BCDC92@oracle.com>
Message-ID: <52B2E3A5.3070807@oracle.com>

Hi Paul And Everyone
Sorry for getting back late.
I took Paul's suggestion and have written other two demos which presents 
usage of parallel computation. One is using Monte-Carlo to calculate 
value of PI. Other is find a big prime by given length. Please review it.
http://cr.openjdk.java.net/~tyan/sample/webrev.00/ 

There is another demo which present mandelbrot set was designed 
Alexander Kouznetsov has been already in reviewing. It's not my code 
review request.
Thank you very much
Tristan


On 10/15/2013 11:20 PM, Paul Sandoz wrote:
>
> On Oct 15, 2013, at 4:35 PM, Tristan Yan  > wrote:
>
>> Hi Paul
>> you have comments "suggest that all streams are sequential. There is 
>> an inconsistency in the use and in some cases it is embedded in other 
>> stream usages."
>>
>> We do not really understand what exactly is meant, could you 
>> elaborate a little bit. Is it because we want to show ppl that we 
>> should use stream more than parallelStream?
>
> Going parallel is easy to do but not always the right thing to do. 
> Going parallel almost always requires more work with the expectation 
> that work will complete sooner than the work required to get the same 
> result sequentially. There are a number of factors that affect whether 
> parallel is faster than sequential. Two of those factors are N, the 
> size of the data, and Q the cost of processing an element in the 
> pipeline. N * Q is a simple cost model, the large that product the 
> better the chances of parallel speed up. N is easy to know, Q not so 
> easy but can often be intuitively guessed. (Note that there are other 
> factors such as the properties of the stream source and operations 
> that Brian and I talked about in our J1 presentation.)
>
> Demo code that just makes everything (or most streams) parallel is 
> sending out the wrong message.
>
> So i think the demo code should present two general things:
>
> 1) various stream functionality, as you have done;
>
> 2) parallel vs. sequential for various cases where it is known that 
> parallel is faster on a multi-core system.
>
> For 2) i strongly recommend measuring using jmh [1]. The data sets you 
> have may or may not be amenable to parallel processing, it's worth 
> investigating though.
>
> I have ideas for other parallel demos. One is creating probably primes 
> (now that SecureRandom is replaced with ThreadLocalRandom), creating a 
> probably prime that is a BigInteger is an relatively expensive 
> operation so Q should be high. Another more advanced demo is a 
> Monte-Carlo calculation of PI using SplittableRandom and a special 
> Spliterator, in this case N should be largish. But there are other 
> simpler demonstrations like sum of squares etc to get across that N 
> should be large. Another demo could be calculation of a mandelbrot 
> set, which is embarrassingly parallel over an area in the complex plane.
>
> So while you should try and fit some parallel vs. sequential execution 
> into your existing demos i do think it worth having a separate set of 
> demos that get across the the simple cost model of N * Q. So feel free 
> to use some of those ideas previously mentioned, i find those ideas 
> fun so perhaps others will too :-)
>
> Paul.
>
> [1] http://openjdk.java.net/projects/code-tools/jmh/
>
> On Oct 15, 2013, at 4:37 PM, Tristan Yan  > wrote:
>
>> Also there is one more question I missed
>>
>> You suggested ""ParallelCore" is not a very descriptive name. Suggest 
>> "streams"."
>> 1) yes we agree this demo is not for parallel computation per se
>> 2) but we do not have a clear demo for parallel computation
>> 3) if we are to rename this, we need to develop another one, do you 
>> have a scenario for that?
>



From chris.hegarty at oracle.com  Thu Dec 19 12:55:43 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 19 Dec 2013 12:55:43 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131219125715.AF96762DD6@hg.openjdk.java.net>

Changeset: e2bdddb8bedf
Author:    dl
Date:      2013-12-19 10:31 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2bdddb8bedf

8026155: Enhance ForkJoin pool
Reviewed-by: chegar, alanb, ahgross

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java

Changeset: c841815be720
Author:    chegar
Date:      2013-12-19 10:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c841815be720

Merge




From Alan.Bateman at oracle.com  Thu Dec 19 14:08:33 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Dec 2013 14:08:33 +0000
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52AC401B.1010405@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>
Message-ID: <52B2FDE1.8070000@oracle.com>

On 14/12/2013 11:25, Peter Levart wrote:
>
> It's unfortunate that a lambda debugging feature prevents us from 
> using a basic language feature in j.u.logging code. As far as I know, 
> java.lang.invoke.ProxyClassesDumper is only used if 
> 'jdk.internal.lambda.dumpProxyClasses' system property is set to point 
> to a directory where lambda proxy class files are to be dumped as they 
> are generated - a debugging hook therefore. Wouldn't it be good-enough 
> if error messages about not-being able to set-up/use the dump facility 
> were output to System.err directly - not using PlatformLogger at all?
It is unfortunate although my comment was mostly thinking about the 
String.format usages when generating proxy classes. It may be that they 
can be changed (we've had to back off on at least one case of using 
method handles because of this).

-Alan


From paul.sandoz at oracle.com  Thu Dec 19 14:51:19 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Dec 2013 15:51:19 +0100
Subject: RFR of lang level code migration patches
Message-ID: 

Hi,

Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback.

This is motivated from Brian's patches to lang tools.

I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code migration. It's easy to pick off other packages over time. This makes for more of a low-brow effort [*], perfect when one has a cold.

Use <> syntax:
http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/

Replace for with for-each 
http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/

Replace while with for-each
http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/

Compress catches
http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/

Use switch for strings; not sure this one is worth it
http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/

I ran all the j.u. tests locally and there were no regressions. Yet to run a JPRT job.

Paul.

[*] although one needs to be vigilant since sometimes the IDE can refactor incorrectly and sometimes code is arranged in a certain way for a reason (which one reason for leaving j.u.concurrent packages alone for now).

From daniel.fuchs at oracle.com  Thu Dec 19 15:07:54 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Dec 2013 16:07:54 +0100
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: <52B30BCA.2040805@oracle.com>

Hi Paul,

I looked at the modifications in java.util.logging and they
look both sensible and desirable.

Had to look at the code for Objects.toString(Object,Object) as
I had never used that before :-)


Thanks for taking care of that,

-- daniel

On 12/19/13 3:51 PM, Paul Sandoz wrote:
> Hi,
>
> Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback.
>
> This is motivated from Brian's patches to lang tools.
>
> I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code migration. It's easy to pick off other packages over time. This makes for more of a low-brow effort [*], perfect when one has a cold.
>
> Use <> syntax:
> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>
> Replace for with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>
> Replace while with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>
> Use switch for strings; not sure this one is worth it
> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>
> I ran all the j.u. tests locally and there were no regressions. Yet to run a JPRT job.
>
> Paul.
>
> [*] although one needs to be vigilant since sometimes the IDE can refactor incorrectly and sometimes code is arranged in a certain way for a reason (which one reason for leaving j.u.concurrent packages alone for now).
>



From peter.levart at gmail.com  Thu Dec 19 15:49:54 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Dec 2013 16:49:54 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B227E2.4000809@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
	<52B227E2.4000809@oracle.com>
Message-ID: <52B315A2.7010403@gmail.com>

On 12/18/2013 11:55 PM, Mandy Chung wrote:
>
> On 12/18/2013 9:03 AM, Peter Levart wrote:
>> Hi Mandy, Daniel,
>>
>> Here's yet another variant that reduces the doPrivileged code to just 
>> Handler's setters. This way no LogManager methods are invoked under 
>> elevated privilege:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.06/ 
>>
>>
>
> This version looks good.  I like the refactoring to have the subclass 
> to call the common code Handler.configure method.  It may be better to 
> have the configure method (or a new one) that takes the default Level 
> and default Formatter instead of the package-private getters.
>
> I don't see why the handler constructors are designed to call the 
> overridden methods rather than the initialization and if a subclass 
> has its custom field, it should initialize its custom fields in its 
> constructor implementation.    Anyway this would be a separate clean 
> up task from this one.
>
> Can you also add a sanity test to verify that these handlers can be 
> constructed successfully with a security manager installed?
>

Hi Mandy, Daniel,

I didn't like the package-protected getters either. So here's another 
variant that replaces Handler.configure() method with a 
package-protected constructor which is chained from JDK subclasses:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/

I filed another bug that is fixed by this patch:

     https://bugs.openjdk.java.net/browse/JDK-8030801

And I created a test (see webrev.07) that almost passes when run against 
unchanged JDK 8 (the failure is just at the end when calling new 
SocketHandler(host, port) - access denied 
("java.util.logging.LoggingPermission" "control")). If I comment-out the 
System.setSecurityManager() from the test, it passes with unchanged 
code. This is to verify the test itself. When run against the patched 
JDK 8, it passes even when SecurityManager is active - this verifies two 
things:
- the behaviour of patched code is analogous to unpatched code as far as 
defaults and configured handler properties is concerned and it conforms 
to javadoc
- the patched code does not require any new permissions - it actually 
requires less, because it fixes bug 8030801.

All java/util/logging jtreg tests pass with patched code. I hope that 
"localhost" is a resolvable name on all environments and that new 
ServerSocket(0) creates a server socket bound at least to the IP address 
that "localhost" resolves to. Is this reasonable to assume?


Regards, Peter



From daniel.fuchs at oracle.com  Thu Dec 19 16:24:07 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Dec 2013 17:24:07 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B315A2.7010403@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
	<52B227E2.4000809@oracle.com> <52B315A2.7010403@gmail.com>
Message-ID: <52B31DA7.3020903@oracle.com>

Hi Peter,

Good idea to add a package constructor in Handler.
It looks much cleaner than the configure method.

Good tests too - thanks for adding that!

To access files with JPRT there is a simpler manner (though what
you have looks good).
JPRT sets a system property "test.src" which point at the
directory where the sources are located.

So you could have used something like:

System.setProperty(CONFIG_FILE_PROPERTY,
    new File(System.getProperty("test.src", "."),
             this.getClass().getSimpleName()+".props")
             .getAbsolutePath());

best regards,

-- daniel

On 12/19/13 4:49 PM, Peter Levart wrote:
> On 12/18/2013 11:55 PM, Mandy Chung wrote:
>>
>> On 12/18/2013 9:03 AM, Peter Levart wrote:
>>> Hi Mandy, Daniel,
>>>
>>> Here's yet another variant that reduces the doPrivileged code to just
>>> Handler's setters. This way no LogManager methods are invoked under
>>> elevated privilege:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.06/
>>>
>>>
>>
>> This version looks good.  I like the refactoring to have the subclass
>> to call the common code Handler.configure method.  It may be better to
>> have the configure method (or a new one) that takes the default Level
>> and default Formatter instead of the package-private getters.
>>
>> I don't see why the handler constructors are designed to call the
>> overridden methods rather than the initialization and if a subclass
>> has its custom field, it should initialize its custom fields in its
>> constructor implementation.    Anyway this would be a separate clean
>> up task from this one.
>>
>> Can you also add a sanity test to verify that these handlers can be
>> constructed successfully with a security manager installed?
>>
>
> Hi Mandy, Daniel,
>
> I didn't like the package-protected getters either. So here's another
> variant that replaces Handler.configure() method with a
> package-protected constructor which is chained from JDK subclasses:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/
>
> I filed another bug that is fixed by this patch:
>
>      https://bugs.openjdk.java.net/browse/JDK-8030801
>
> And I created a test (see webrev.07) that almost passes when run against
> unchanged JDK 8 (the failure is just at the end when calling new
> SocketHandler(host, port) - access denied
> ("java.util.logging.LoggingPermission" "control")). If I comment-out the
> System.setSecurityManager() from the test, it passes with unchanged
> code. This is to verify the test itself. When run against the patched
> JDK 8, it passes even when SecurityManager is active - this verifies two
> things:
> - the behaviour of patched code is analogous to unpatched code as far as
> defaults and configured handler properties is concerned and it conforms
> to javadoc
> - the patched code does not require any new permissions - it actually
> requires less, because it fixes bug 8030801.
>
> All java/util/logging jtreg tests pass with patched code. I hope that
> "localhost" is a resolvable name on all environments and that new
> ServerSocket(0) creates a server socket bound at least to the IP address
> that "localhost" resolves to. Is this reasonable to assume?
>
>
> Regards, Peter
>



From roger.riggs at oracle.com  Thu Dec 19 16:26:49 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 19 Dec 2013 11:26:49 -0500
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
Message-ID: <52B31E49.9020900@oracle.com>

Created JDK-8030814  
to track this issue.

Roger


On 12/18/2013 6:52 PM, Louis Wasserman wrote:
> Derp.  Here is the test case:
>
> import java.math.BigInteger;
>
> public class UnsignedLongBug {
>    public static void main(String[] args) {
>      try {
>        String input = "1234567890abcdef1";
>        System.out.println(Long.parseUnsignedLong(input, 16));
>        BigInteger maxUnsignedLong =
> BigInteger.ONE.shiftLeft(64).subtract(BigInteger.ONE);
>        BigInteger inputValue = new BigInteger(input, 16);
>        System.out.println(maxUnsignedLong.compareTo(inputValue));
>        throw new AssertionError();
>      } catch (NumberFormatException expected) {
>        System.out.println("Correct");
>      }
>    }
> }
>
>
> On Wed, Dec 18, 2013 at 3:51 PM, Louis Wasserman wrote:
>
>> The Javadoc of Long.parseUnsignedLong specifies that it should throw a
>> NumberFormatException if "the value represented by the string is larger
>> than the largest unsigned long, 2^64-1."
>>
>> This does not appear to be happening:
>>
>> --
>> Louis Wasserman
>>
>
>



From mandy.chung at oracle.com  Thu Dec 19 16:39:36 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Dec 2013 08:39:36 -0800
Subject: RFR:
	java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
	failing again
In-Reply-To: <52B2D2CA.1010907@oracle.com>
References: <52B03C17.5040204@oracle.com> <52B20709.6040007@oracle.com>
	<52B2D2CA.1010907@oracle.com>
Message-ID: <52B32148.7030307@oracle.com>


On 12/19/2013 3:04 AM, Daniel Fuchs wrote:
> On 12/18/13 9:35 PM, Mandy Chung wrote:
>>
>> On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a fix for what I believe is a test bug.
>>> I plan to push this in JDK 9 dev.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8030187
>>>
>>> This seems to be a very intermittent failure.
>>> It looks as if a logger held in a local variable can be
>>> arbitrarily garbage collected if that variable is no longer
>>> used.
>>> To prevent arbitrary garbage collection of such loggers, the fix
>>> makes sure to use the variable again at the end of the test.
>>>
>>
>> Looks like running the test in -Xcomp and also with jtreg creates
>> pressure to the young gen and more object allocation failure and so
>> unreachable objects get collected in the middle of a small method body
>> (like in this case).
>>
>> You added code to reference the local variables referencing the
>> loggers.  Would it be simpler to have this test  just to hold a strong
>> reference to the logger?
>
> Hmmm. I don't think it would be simpler. I could have added an
> array list of loggers and cleared that at the end of the test.
> It would just have been another way of making sure that the
> loggers weren't gc'ed.

Are you concerned that a static/instance field holding the loggers gets 
GC'ed if not referenced before the test method returns?   They should be 
only collected when the class/instance becomes unreachable and it 
shouldn't be an issue (as do in other tests).

I'm fine with what you have.

Mandy


From brian.goetz at oracle.com  Thu Dec 19 16:44:59 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 19 Dec 2013 11:44:59 -0500
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: <52B3228B.6040303@oracle.com>

+1 on all changes, except perhaps for this one in Collections.copy:

  ListIterator di=dest.listIterator();
               ListIterator si=src.listIterator();
               for (int i=0; i Hi,
>
> Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback.
>
> This is motivated from Brian's patches to lang tools.
>
> I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code migration. It's easy to pick off other packages over time. This makes for more of a low-brow effort [*], perfect when one has a cold.
>
> Use <> syntax:
> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>
> Replace for with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>
> Replace while with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>
> Use switch for strings; not sure this one is worth it
> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>
> I ran all the j.u. tests locally and there were no regressions. Yet to run a JPRT job.
>
> Paul.
>
> [*] although one needs to be vigilant since sometimes the IDE can refactor incorrectly and sometimes code is arranged in a certain way for a reason (which one reason for leaving j.u.concurrent packages alone for now).
>


From martinrb at google.com  Thu Dec 19 16:48:04 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Dec 2013 08:48:04 -0800
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: 

(as always) Please don't modify jsr166 classes (ArrayDeque) here, since
they are maintained upstream in jsr166 CVS.  Since jsr166 targets a variety
of java runtimes in general, it tends to be a late adopter of new language
features.  Although it's probably time to start using jdk7 features.


On Thu, Dec 19, 2013 at 6:51 AM, Paul Sandoz  wrote:

> Hi,
>
> Here are some patches that migrate some code to use more up to date
> language features. I will create a bug later on after feedback.
>
> This is motivated from Brian's patches to lang tools.
>
> I focused just on java.util, minus the concurrent packages, and i used the
> IDE to assist in the code migration. It's easy to pick off other packages
> over time. This makes for more of a low-brow effort [*], perfect when one
> has a cold.
>
> Use <> syntax:
> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>
> Replace for with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>
> Replace while with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>
> Use switch for strings; not sure this one is worth it
> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>
> I ran all the j.u. tests locally and there were no regressions. Yet to run
> a JPRT job.
>
> Paul.
>
> [*] although one needs to be vigilant since sometimes the IDE can refactor
> incorrectly and sometimes code is arranged in a certain way for a reason
> (which one reason for leaving j.u.concurrent packages alone for now).
>


From brian.burkhalter at oracle.com  Thu Dec 19 17:05:51 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Dec 2013 09:05:51 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <52B31E49.9020900@oracle.com>
References: 
	
	<52B31E49.9020900@oracle.com>
Message-ID: <3906DE45-32C2-47F1-B375-E4735EB4872A@oracle.com>

Thanks, you saved me the trouble. I already verified it yesterday myself.

Brian

On Dec 19, 2013, at 8:26 AM, roger riggs wrote:

> Created JDK-8030814  to track this issue.



From brian.goetz at oracle.com  Thu Dec 19 17:19:40 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 19 Dec 2013 12:19:40 -0500
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
	
Message-ID: <52B32AAC.3050300@oracle.com>

Paul deliberately stayed away from the JUC classes.  Can we get a 
definitive list of non-JUC classes that primarily live in the JSR166 CVS?

On 12/19/2013 11:48 AM, Martin Buchholz wrote:
> (as always) Please don't modify jsr166 classes (ArrayDeque) here, since
> they are maintained upstream in jsr166 CVS.  Since jsr166 targets a variety
> of java runtimes in general, it tends to be a late adopter of new language
> features.  Although it's probably time to start using jdk7 features.
>
>
> On Thu, Dec 19, 2013 at 6:51 AM, Paul Sandoz  wrote:
>
>> Hi,
>>
>> Here are some patches that migrate some code to use more up to date
>> language features. I will create a bug later on after feedback.
>>
>> This is motivated from Brian's patches to lang tools.
>>
>> I focused just on java.util, minus the concurrent packages, and i used the
>> IDE to assist in the code migration. It's easy to pick off other packages
>> over time. This makes for more of a low-brow effort [*], perfect when one
>> has a cold.
>>
>> Use <> syntax:
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>>
>> Replace for with for-each
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>>
>> Replace while with for-each
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>>
>> Compress catches
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>>
>> Use switch for strings; not sure this one is worth it
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>>
>> I ran all the j.u. tests locally and there were no regressions. Yet to run
>> a JPRT job.
>>
>> Paul.
>>
>> [*] although one needs to be vigilant since sometimes the IDE can refactor
>> incorrectly and sometimes code is arranged in a certain way for a reason
>> (which one reason for leaving j.u.concurrent packages alone for now).
>>


From chris.hegarty at oracle.com  Thu Dec 19 17:21:10 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Dec 2013 17:21:10 +0000
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: <6F6D6F9B-2C35-46DD-BDED-1A3779E4C469@oracle.com>

I looked over the patch files, and they look good to me.

Limiting each webrev to a single language feature makes reviewing quite straight forward.

-Chris.

On 19 Dec 2013, at 14:51, Paul Sandoz  wrote:

> Hi,
> 
> Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback.
> 
> This is motivated from Brian's patches to lang tools.
> 
> I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code migration. It's easy to pick off other packages over time. This makes for more of a low-brow effort [*], perfect when one has a cold.
> 
> Use <> syntax:
> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
> 
> Replace for with for-each 
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
> 
> Replace while with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
> 
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
> 
> Use switch for strings; not sure this one is worth it
> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
> 
> I ran all the j.u. tests locally and there were no regressions. Yet to run a JPRT job.
> 
> Paul.
> 
> [*] although one needs to be vigilant since sometimes the IDE can refactor incorrectly and sometimes code is arranged in a certain way for a reason (which one reason for leaving j.u.concurrent packages alone for now).



From martinrb at google.com  Thu Dec 19 17:33:11 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Dec 2013 09:33:11 -0800
Subject: RFR of lang level code migration patches
In-Reply-To: <52B32AAC.3050300@oracle.com>
References: 
	
	<52B32AAC.3050300@oracle.com>
Message-ID: 

To a high degree of accuracy, the following command gives you the list of
upstream-maintained jsr166 files.
(You can also check out jsr166 CVS yourself and poke around in src/main and
src/jtreg.)

openjdk8/jdk $ find -name '*.java' | xargs grep -lF
http://creativecommons.org/publicdomain/zero/1.0/ | sort
./src/share/classes/java/util/AbstractQueue.java
./src/share/classes/java/util/ArrayDeque.java
./src/share/classes/java/util/ArrayPrefixHelpers.java
./src/share/classes/java/util/Deque.java
./src/share/classes/java/util/NavigableMap.java
./src/share/classes/java/util/NavigableSet.java
./src/share/classes/java/util/Queue.java
./src/share/classes/java/util/concurrent/AbstractExecutorService.java
./src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
./src/share/classes/java/util/concurrent/BlockingDeque.java
./src/share/classes/java/util/concurrent/BlockingQueue.java
./src/share/classes/java/util/concurrent/BrokenBarrierException.java
./src/share/classes/java/util/concurrent/Callable.java
./src/share/classes/java/util/concurrent/CancellationException.java
./src/share/classes/java/util/concurrent/CompletableFuture.java
./src/share/classes/java/util/concurrent/CompletionException.java
./src/share/classes/java/util/concurrent/CompletionService.java
./src/share/classes/java/util/concurrent/CompletionStage.java
./src/share/classes/java/util/concurrent/ConcurrentHashMap.java
./src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
./src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
./src/share/classes/java/util/concurrent/ConcurrentMap.java
./src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
./src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
./src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
./src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
./src/share/classes/java/util/concurrent/CountDownLatch.java
./src/share/classes/java/util/concurrent/CountedCompleter.java
./src/share/classes/java/util/concurrent/CyclicBarrier.java
./src/share/classes/java/util/concurrent/DelayQueue.java
./src/share/classes/java/util/concurrent/Delayed.java
./src/share/classes/java/util/concurrent/Exchanger.java
./src/share/classes/java/util/concurrent/ExecutionException.java
./src/share/classes/java/util/concurrent/Executor.java
./src/share/classes/java/util/concurrent/ExecutorCompletionService.java
./src/share/classes/java/util/concurrent/ExecutorService.java
./src/share/classes/java/util/concurrent/Executors.java
./src/share/classes/java/util/concurrent/ForkJoinPool.java
./src/share/classes/java/util/concurrent/ForkJoinTask.java
./src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
./src/share/classes/java/util/concurrent/Future.java
./src/share/classes/java/util/concurrent/FutureTask.java
./src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
./src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
./src/share/classes/java/util/concurrent/LinkedTransferQueue.java
./src/share/classes/java/util/concurrent/Phaser.java
./src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
./src/share/classes/java/util/concurrent/RecursiveAction.java
./src/share/classes/java/util/concurrent/RecursiveTask.java
./src/share/classes/java/util/concurrent/RejectedExecutionException.java
./src/share/classes/java/util/concurrent/RejectedExecutionHandler.java
./src/share/classes/java/util/concurrent/RunnableFuture.java
./src/share/classes/java/util/concurrent/RunnableScheduledFuture.java
./src/share/classes/java/util/concurrent/ScheduledExecutorService.java
./src/share/classes/java/util/concurrent/ScheduledFuture.java
./src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
./src/share/classes/java/util/concurrent/Semaphore.java
./src/share/classes/java/util/concurrent/SynchronousQueue.java
./src/share/classes/java/util/concurrent/ThreadFactory.java
./src/share/classes/java/util/concurrent/ThreadLocalRandom.java
./src/share/classes/java/util/concurrent/ThreadPoolExecutor.java
./src/share/classes/java/util/concurrent/TimeUnit.java
./src/share/classes/java/util/concurrent/TimeoutException.java
./src/share/classes/java/util/concurrent/TransferQueue.java
./src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
./src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
./src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
./src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
./src/share/classes/java/util/concurrent/atomic/AtomicLong.java
./src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
./src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
./src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java
./src/share/classes/java/util/concurrent/atomic/AtomicReference.java
./src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
./src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
./src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
./src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
./src/share/classes/java/util/concurrent/atomic/DoubleAdder.java
./src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
./src/share/classes/java/util/concurrent/atomic/LongAdder.java
./src/share/classes/java/util/concurrent/atomic/Striped64.java
./src/share/classes/java/util/concurrent/atomic/package-info.java
./src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java
./src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
./src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
./src/share/classes/java/util/concurrent/locks/Condition.java
./src/share/classes/java/util/concurrent/locks/Lock.java
./src/share/classes/java/util/concurrent/locks/LockSupport.java
./src/share/classes/java/util/concurrent/locks/ReadWriteLock.java
./src/share/classes/java/util/concurrent/locks/ReentrantLock.java
./src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
./src/share/classes/java/util/concurrent/locks/StampedLock.java
./src/share/classes/java/util/concurrent/locks/package-info.java
./src/share/classes/java/util/concurrent/package-info.java
./test/java/util/PriorityQueue/NoNulls.java
./test/java/util/PriorityQueue/PriorityQueueSort.java
./test/java/util/Random/DistinctSeeds.java
./test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java
./test/java/util/concurrent/BlockingQueue/LoopHelpers.java
./test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java
./test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java
./test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java
./test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java
./test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java
./test/java/util/concurrent/CompletableFuture/Basic.java
./test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java
./test/java/util/concurrent/ConcurrentHashMap/MapCheck.java
./test/java/util/concurrent/ConcurrentHashMap/MapLoops.java
./test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
./test/java/util/concurrent/ConcurrentQueues/GCRetention.java
./test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java
./test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java
./test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
./test/java/util/concurrent/Exchanger/ExchangeLoops.java
./test/java/util/concurrent/Exchanger/LoopHelpers.java
./test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java
./test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java
./test/java/util/concurrent/FutureTask/CancelledFutureLoops.java
./test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
./test/java/util/concurrent/FutureTask/LoopHelpers.java
./test/java/util/concurrent/Phaser/Arrive.java
./test/java/util/concurrent/Phaser/Basic.java
./test/java/util/concurrent/Phaser/FickleRegister.java
./test/java/util/concurrent/Phaser/PhaseOverflow.java
./test/java/util/concurrent/Phaser/TieredArriveLoops.java
./test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java
./test/java/util/concurrent/Semaphore/PermitOverflow.java
./test/java/util/concurrent/Semaphore/RacingReleases.java
./test/java/util/concurrent/atomic/DoubleAdderDemo.java
./test/java/util/concurrent/atomic/LongAdderDemo.java
./test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java
./test/java/util/concurrent/forkjoin/Integrate.java
./test/java/util/concurrent/forkjoin/NQueensCS.java
./test/java/util/concurrent/forkjoin/ThreadLessCommon.java
./test/java/util/concurrent/forkjoin/ThrowingRunnable.java
./test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
./test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java
./test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java
./test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java
./test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
./test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java
./test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java
./test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java
./test/java/util/concurrent/locks/StampedLock/Basic.java


On Thu, Dec 19, 2013 at 9:19 AM, Brian Goetz  wrote:

> Paul deliberately stayed away from the JUC classes.  Can we get a
> definitive list of non-JUC classes that primarily live in the JSR166 CVS?
>
>
> On 12/19/2013 11:48 AM, Martin Buchholz wrote:
>
>> (as always) Please don't modify jsr166 classes (ArrayDeque) here, since
>> they are maintained upstream in jsr166 CVS.  Since jsr166 targets a
>> variety
>> of java runtimes in general, it tends to be a late adopter of new language
>> features.  Although it's probably time to start using jdk7 features.
>>
>>
>> On Thu, Dec 19, 2013 at 6:51 AM, Paul Sandoz 
>> wrote:
>>
>>  Hi,
>>>
>>> Here are some patches that migrate some code to use more up to date
>>> language features. I will create a bug later on after feedback.
>>>
>>> This is motivated from Brian's patches to lang tools.
>>>
>>> I focused just on java.util, minus the concurrent packages, and i used
>>> the
>>> IDE to assist in the code migration. It's easy to pick off other packages
>>> over time. This makes for more of a low-brow effort [*], perfect when one
>>> has a cold.
>>>
>>> Use <> syntax:
>>> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>>>
>>> Replace for with for-each
>>> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>>>
>>> Replace while with for-each
>>> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>>>
>>> Compress catches
>>> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>>>
>>> Use switch for strings; not sure this one is worth it
>>> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>>>
>>> I ran all the j.u. tests locally and there were no regressions. Yet to
>>> run
>>> a JPRT job.
>>>
>>> Paul.
>>>
>>> [*] although one needs to be vigilant since sometimes the IDE can
>>> refactor
>>> incorrectly and sometimes code is arranged in a certain way for a reason
>>> (which one reason for leaving j.u.concurrent packages alone for now).
>>>
>>>


From paul.sandoz at oracle.com  Thu Dec 19 17:36:12 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Dec 2013 18:36:12 +0100
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
Message-ID: <72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>

Hi,

I think the logic for overflow when using the compareUnsigned is incorrect in Long:

                long first = parseLong(s.substring(0, len - 1), radix);
                int second = Character.digit(s.charAt(len - 1), radix);
                if (second < 0) {
                    throw new NumberFormatException("Bad digit at end of " + s);
                }
                long result = first * radix + second;
                if (compareUnsigned(result, first) < 0) {

Take for example a string representation consisting of 17 digits "12000000000000000"

The long that will be parsed is one char less "1200000000000000":

  first = 0x1200_0000_0000_0000
  second = 0;
  result = 0x2000_0000_0000_0000 // first << 4, result > first

i.e. overflow of the overflow if you consider 16 additions, rather than a multiply.

My brain is too clogged up with cold at the moment to propose a fix :-(

Paul.

On Dec 19, 2013, at 12:52 AM, Louis Wasserman  wrote:

> Derp.  Here is the test case:
> 
> import java.math.BigInteger;
> 
> public class UnsignedLongBug {
>  public static void main(String[] args) {
>    try {
>      String input = "1234567890abcdef1";
>      System.out.println(Long.parseUnsignedLong(input, 16));
>      BigInteger maxUnsignedLong =
> BigInteger.ONE.shiftLeft(64).subtract(BigInteger.ONE);
>      BigInteger inputValue = new BigInteger(input, 16);
>      System.out.println(maxUnsignedLong.compareTo(inputValue));
>      throw new AssertionError();
>    } catch (NumberFormatException expected) {
>      System.out.println("Correct");
>    }
>  }
> }
> 
> 
> On Wed, Dec 18, 2013 at 3:51 PM, Louis Wasserman wrote:
> 
>> The Javadoc of Long.parseUnsignedLong specifies that it should throw a
>> NumberFormatException if "the value represented by the string is larger
>> than the largest unsigned long, 2^64-1."
>> 
>> This does not appear to be happening:
>> 
>> --
>> Louis Wasserman
>> 
> 
> 
> 
> -- 
> Louis Wasserman


From brian.burkhalter at oracle.com  Thu Dec 19 17:42:10 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Dec 2013 09:42:10 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
Message-ID: 


On Dec 19, 2013, at 9:36 AM, Paul Sandoz wrote:

> I think the logic for overflow when using the compareUnsigned is incorrect in Long:
> 
> [?]
>                long result = first * radix + second;
>                if (compareUnsigned(result, first) < 0) {

I concur and verified that yesterday by replacing the above logic with BigInteger equivalents which passed the test.

> My brain is too clogged up with cold at the moment to propose a fix :-(

Hope you recover soon!

Thanks,

Brian

From daniel.fuchs at oracle.com  Thu Dec 19 17:54:05 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Dec 2013 18:54:05 +0100
Subject: RFR:
	java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
	failing again
In-Reply-To: <52B32148.7030307@oracle.com>
References: <52B03C17.5040204@oracle.com> <52B20709.6040007@oracle.com>
	<52B2D2CA.1010907@oracle.com> <52B32148.7030307@oracle.com>
Message-ID: <52B332BD.3030601@oracle.com>

On 12/19/13 5:39 PM, Mandy Chung wrote:
>
> On 12/19/2013 3:04 AM, Daniel Fuchs wrote:
>> On 12/18/13 9:35 PM, Mandy Chung wrote:
>>>
>>> On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> Please find below a fix for what I believe is a test bug.
>>>> I plan to push this in JDK 9 dev.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8030187
>>>>
>>>> This seems to be a very intermittent failure.
>>>> It looks as if a logger held in a local variable can be
>>>> arbitrarily garbage collected if that variable is no longer
>>>> used.
>>>> To prevent arbitrary garbage collection of such loggers, the fix
>>>> makes sure to use the variable again at the end of the test.
>>>>
>>>
>>> Looks like running the test in -Xcomp and also with jtreg creates
>>> pressure to the young gen and more object allocation failure and so
>>> unreachable objects get collected in the middle of a small method body
>>> (like in this case).
>>>
>>> You added code to reference the local variables referencing the
>>> loggers.  Would it be simpler to have this test  just to hold a strong
>>> reference to the logger?
>>
>> Hmmm. I don't think it would be simpler. I could have added an
>> array list of loggers and cleared that at the end of the test.
>> It would just have been another way of making sure that the
>> loggers weren't gc'ed.
>
> Are you concerned that a static/instance field holding the loggers gets
> GC'ed if not referenced before the test method returns?   They should be
> only collected when the class/instance becomes unreachable and it
> shouldn't be an issue (as do in other tests).

Yes - that was part of my concern. Reusing the variable at the end
of the test makes it obviously visible that it can't be gc'ed before
that.

> I'm fine with what you have.

OK thanks Mandy, I think I will push what I have then.
This is what I have tested - by running it for several hours in a
loop :-)

-- daniel

>
> Mandy



From lowasser at google.com  Thu Dec 19 18:28:28 2013
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 19 Dec 2013 10:28:28 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
Message-ID: 

Here's one approach that works: there is overflow iff

compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 || (first
== divideUnsigned(MAX_UNSIGNED, radix) && second >
remainderUnsigned(MAX_UNSIGNED, radix));

Since radix <= Character.MAX_RADIX, you can precompute the divides and
remainders in a small table.


On Thu, Dec 19, 2013 at 9:42 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

>
> On Dec 19, 2013, at 9:36 AM, Paul Sandoz wrote:
>
> > I think the logic for overflow when using the compareUnsigned is
> incorrect in Long:
> >
> > [?]
> >                long result = first * radix + second;
> >                if (compareUnsigned(result, first) < 0) {
>
> I concur and verified that yesterday by replacing the above logic with
> BigInteger equivalents which passed the test.
>
> > My brain is too clogged up with cold at the moment to propose a fix :-(
>
> Hope you recover soon!
>
> Thanks,
>
> Brian




-- 
Louis Wasserman


From Alan.Bateman at oracle.com  Thu Dec 19 18:33:33 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Dec 2013 18:33:33 +0000
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: <52B33BFD.70401@oracle.com>

On 19/12/2013 14:51, Paul Sandoz wrote:
> :
>
> I ran all the j.u. tests locally and there were no regressions.
That's the main thing with changes like this.

I skimmed over the changes too and they look okay. I'm sometimes wary of 
IDEs re-arranging things but there's nothing here. It would be good to 
get a few other areas done too while things are quiet.

-Alan.


From mike.duigou at oracle.com  Thu Dec 19 19:22:58 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 19 Dec 2013 11:22:58 -0800
Subject: RFR of lang level code migration patches
In-Reply-To: 
References: 
Message-ID: 

These look good to me.

On Dec 19 2013, at 06:51 , Paul Sandoz  wrote:

> Hi,
> 
> Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback.
> 
> This is motivated from Brian's patches to lang tools.
> 
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/

The comment in JarVerifier "// e.g. sun.security.pkcs.ParsingException" is now probably too broad to be useful. Maybe just remove it.




From brian.burkhalter at oracle.com  Thu Dec 19 19:26:49 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Dec 2013 11:26:49 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
Message-ID: <17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>

Upon inspection only that indeed looks correct.

Thanks ?

On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:

> Here's one approach that works: there is overflow iff 
> 
> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 || (first == divideUnsigned(MAX_UNSIGNED, radix) && second > remainderUnsigned(MAX_UNSIGNED, radix));
> 
> Since radix <= Character.MAX_RADIX, you can precompute the divides and remainders in a small table.



From brian.burkhalter at oracle.com  Thu Dec 19 20:21:27 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Dec 2013 12:21:27 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
Message-ID: <8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>

Here's a formalization of the suggested fix:

http://cr.openjdk.java.net/~bpb/8030814/webrev/

It works against the test case.

Brian

On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:

> Upon inspection only that indeed looks correct.
> 
> Thanks ?
> 
> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
> 
>> Here's one approach that works: there is overflow iff 
>> 
>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 || (first == divideUnsigned(MAX_UNSIGNED, radix) && second > remainderUnsigned(MAX_UNSIGNED, radix));
>> 
>> Since radix <= Character.MAX_RADIX, you can precompute the divides and remainders in a small table.
> 



From mandy.chung at oracle.com  Thu Dec 19 21:38:35 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Dec 2013 13:38:35 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B315A2.7010403@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
	<52B227E2.4000809@oracle.com> <52B315A2.7010403@gmail.com>
Message-ID: <52B3675B.1030403@oracle.com>

On 12/19/13 7:49 AM, Peter Levart wrote:
> Hi Mandy, Daniel,
>
> I didn't like the package-protected getters either. So here's another 
> variant that replaces Handler.configure() method with a 
> package-protected constructor which is chained from JDK subclasses:
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/
>

Looks good.  Thanks for making the change and the new test.  It'd be 
good to close the handlers by the test. The test is running in othervm 
mode and the Cleaner thread will close the handler when VM exits and the 
test is fine as it is.

Digress:  Just notice that the closeable handler classes are not 
AutoCloseable (they don't implement Closeable either).  The close() 
method don't throw IOException but instead throws SecurityException an 
unchecked exception.  Otherwise, we could use try-with-resources.

> I filed another bug that is fixed by this patch:
>
>     https://bugs.openjdk.java.net/browse/JDK-8030801
>
> And I created a test (see webrev.07) that almost passes when run 
> against unchanged JDK 8 (the failure is just at the end when calling 
> new SocketHandler(host, port) - access denied 
> ("java.util.logging.LoggingPermission" "control")). If I comment-out 
> the System.setSecurityManager() from the test, it passes with 
> unchanged code. This is to verify the test itself. When run against 
> the patched JDK 8, it passes even when SecurityManager is active - 
> this verifies two things:
> - the behaviour of patched code is analogous to unpatched code as far 
> as defaults and configured handler properties is concerned and it 
> conforms to javadoc
> - the patched code does not require any new permissions - it actually 
> requires less, because it fixes bug 8030801.
>

Yes I agree this is a bug that should get fixed.

> All java/util/logging jtreg tests pass with patched code. I hope that 
> "localhost" is a resolvable name on all environments and that new 
> ServerSocket(0) creates a server socket bound at least to the IP 
> address that "localhost" resolves to. Is this reasonable to assume?

"localhost" should be fine and there are other tests depending on it be 
resolvable.

thanks
Mandy


From david.holmes at oracle.com  Fri Dec 20 01:08:50 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 11:08:50 +1000
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B3568B.5050905@oracle.com>
References: <52B3568B.5050905@oracle.com>
Message-ID: <52B398A2.8030307@oracle.com>

Hi Kalyan,

This is not a hotspot issue so I'm moving this to core-libs, please drop 
hotspot from any replies.

On 20/12/2013 6:26 AM, srikalyan wrote:
> Hi all,  I have been working on the bug JDK-8022321
>  , this is a sporadic
> failure and the webrev is available here
> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/

I'm really not sure what to make of this. We have a test that triggers 
an out-of-memory condition but the OOME can actually turn up in the 
ReferenceHandler thread causing it to terminate and the test to fail. We 
previously accounted for the non-obvious occurrences of OOME due to the 
Object.wait and the possible need to load the InterruptedException class 
- but still the OOME can appear where we don't want it. So finally you 
have just placed the whole for(;;) loop in a try/catch(OOME) that 
ignores the OOME. I'm certain that makes the test happy, but I'm not 
sure it is really what we want for the ReferenceHandler thread. If the 
OOME occurs while cleaning, or enqueuing then we will fail to clean 
and/or enqueue but there would be no indication that has occurred and I 
think that is a bigger problem than this test failing.

There may be no way to make this test 100% reliable. In fact I'd suggest 
that no memory exhaustion test can be 100% reliable.

David

> *
> **"Root Cause:Still not known"*
> 2 places where there is a possibility for OOME
> 1) Cleaner.clean()
> 2) ReferenceQueue.enqueue()
>
> 1)  The cleanup code in turn has 2 places where there is potential for
> throwing OOME,
>      a) thunk Thread which is run from clean() method. This Runnable is
> passed to Cleaner and appears in the following classes
>          java/nio/DirectByteBuffer.java
>          sun/misc/Perf.java
>          sun/nio/fs/NativeBuffer.java
>          sun/nio/ch/IOVecWrapper.java
>          sun/misc/Cleaner/ExitOnThrow.java
> However none of the above overridden implementations ever create an
> object in the clean() code.
>      b) new PrivilegedAction created in try catch Exception block of
> clean() method but for this object to be created and to be held
> responsible for OOME an Exception(other than OOME) has to be thrown.
>
> 2) No new heap objects are created in the enqueue method nor anywhere in
> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
> potential cause.
>
> *Experimental change to java.lang.Reference.java* :
> - Put one more guard (try catch with OOME block) in the Reference
> Handler Thread which may give the Reference Handler a chance to cleanup.
> This is fixing the test failure (several 1000 runs with 0 failures)
> - Without the above change the test fails atleast 3-5 times for every
> 1000 run.
>
> *PS*: The code change is to a very critical part of JDK and i am fully
> not aware of the consequences of the change, hence seeking expert help
> here. Appreciate your time and inputs towards this.
>


From david.holmes at oracle.com  Fri Dec 20 02:19:29 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 12:19:29 +1000
Subject: RFR [6968459] JNDI timeout fails before timeout is reached
In-Reply-To: <529E014B.6040602@gmail.com>
References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com>
	<5298F3CE.6000003@oracle.com> <529DC94C.20300@gmail.com>
	<529DEC34.3010309@oracle.com> <529E014B.6040602@gmail.com>
Message-ID: <52B3A931.1040806@oracle.com>

If you track the elapsed waiting time using System.nanoTime you do not 
need to be concerned whether anyone messes with the TOD clock.

David

On 4/12/2013 2:05 AM, Peter Levart wrote:
> On 12/03/2013 03:35 PM, Ivan Gerasimov wrote:
>> Hi Peter!
>>
>> Thank you for your review!
>>
>> You are right, the patch changed the behavior of the code.
>> I've reverted back all the unnecessary changes. This should minimize
>> the risk.
>>
>> I've also made another correction: After decrementing the remaining
>> timeOut, the startTime should be set to currTime.
>>
>> Would you please help review the updated webrev:
>> http://cr.openjdk.java.net/~igerasim/6968459/2/webrev/
>>
>> Sincerely yours,
>> Ivan
>
> Hi Ivan,
>
> That's better. You could move the initial request for ldr.getReplyBer()
> (line 447) out of while loop, since it is not needed in the loop (all
> further ldr.getReplyBer() calls in loop are performed in synchronized
> block already - line 465). "else { break; }" (line 469) is not needed in
> that case. I would also make timeOut variable long to avoid overflows.
> Simplified logic could look like this:
>
>
>      BerDecoder readReply(LdapRequest ldr)
>              throws IOException, NamingException {
>          long timeOut = (readTimeout > 0) ?
>                  readTimeout : 15 * 1000; // Default read timeout of 15 sec
>
>          long currTime = System.currentTimeMillis();
>
>          BerDecoder rber = ldr.getReplyBer();
>
>          while (rber == null && timeOut > 0L) {
>              long startTime = currTime;
>              // If socket closed, don't even try
>              synchronized (this) {
>                  if (sock == null) {
>                      throw new ServiceUnavailableException(host + ":" +
> port +
> "; socket closed");
>                  }
>              }
>              synchronized (ldr) {
>                  // check if condition has changed since our last check
>                  rber = ldr.getReplyBer();
>                  if (rber == null) {
>                      try {
>                          ldr.wait(timeOut);
>                      } catch (InterruptedException ex) {
>                          throw new InterruptedNamingException(
>                              "Interrupted during LDAP operation");
>                      }
>                  }
>              }
>              currTime = System.currentTimeMillis();
>              if (startTime < currTime) {
>                  timeOut -= (currTime - startTime);
>              }
>              // else system time must have changed backwards (or not at
> all)
>          }
>
>          if (rber == null && readTimeout > 0) {
>              removeRequest(ldr);
>              throw new NamingException("LDAP response read timed out,
> timeout used:"
>                              + readTimeout + "ms." );
>          }
>
>          return rber;
>      }
>
>
> What do you think?
>
> Regards, Peter
>
>>
>>>
>>> From quick look I notice a danger that Connection.readReply() pauses
>>> (for the timeOut time) in spite of the fact that a reply is ready and
>>> enqueued before waiting.
>>>
>>> Imagine a situation where the 1st try of obtaining result returns null:
>>>
>>>  450         // Get the reply if it is already available.
>>>  451         BerDecoder rber = ldr.getReplyBer();
>>>
>>>
>>> ...after that, but before reaching the following lines:
>>>
>>>  471                     synchronized (ldr) {
>>>  472                         ldr.wait(timeOut);
>>>  473                     }
>>>
>>>
>>> The "other" thread enqueues a reply (LdapRequest.addReplyBer())
>>> because the code in readReply() is executing without holding a lock
>>> on "ldr". When "this" thread (executing readReply()) finally enters
>>> synchronized block and waits, it will wait until wait() times out or
>>> another reply is enqueued which will issue another notify(). This can
>>> lead to unnecessary pauses. Old code does not exhibit this problem,
>>> because it re-checks the readiness of a reply immediately after
>>> entering the synchronized block.
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>
>


From stuart.marks at oracle.com  Fri Dec 20 02:47:08 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 19 Dec 2013 18:47:08 -0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <52B1B675.8090908@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>	<529FD0A9.9020400@oracle.com>
	<52A7C98E.7000200@oracle.com> <52A8DA41.1020909@oracle.com>
	<52B1B675.8090908@oracle.com>
Message-ID: <52B3AFAC.1080204@oracle.com>

Hi Tristan,

Changes mostly look good.

There is an ignored InterruptedException in both versions of 
UseCustomSocketFactory.java, but that was there already; it's not clear what 
should be done in this case anyway. This is something to keep in mind for a 
future cleanup. Hm, some duplicate code here as well, again something to think 
about for the future.

There is a serious problem with the change to ReadTimeoutTest.java, however. The 
change removes the (old) line 72, which is

     TestIface stub = impl.export();

probably because there was an IDE warning that the variable "stub" is unused. 
This much is true, but it's essential for impl.export() to be called, because 
that exports the object, which creates a socket using the socket factory, which 
eventually results in the fac.whichPort() call below returning the port that was 
open. In the absence of the export() call, whichPort() returns zero which causes 
the test to abort immediately.

In addition, the refactoring to use try-with-resources changes the order of 
execution of certain code, and it changes the scope of things handled by the 
finally-block.

One purpose of the finally-block is to unexport the remote object so it makes 
sense to begin the try-block immediately following the export. The original code 
did this (well, only after a benign local variable declaration). The change 
moves the try-block few lines down, which means there is a larger window of time 
within which the finally-block won't be executed. This isn't obviously a 
problem, but it's a change nonetheless.

Also, the change alters the order of opening the client socket and the 
"connecting to listening port" message, so the message comes after the port is 
opened, instead of before. Again, an apparently small change, but if there's an 
exception opening the port, the port number being opened won't be printed out.

The main point of the changes to this file, however, is good, which is to 
replace the unsafe use of multi-thread access to a boolean array and polling of 
that value, with a CountDownLatch. So that part of the change should go in. The 
problem is the apparently innocuous code cleanups (use of try-with-resources, 
removal of apparently unused local variable) which cause the test to break or 
otherwise change its behavior.

I could go ahead and push this changeset, omitting the changes to 
ReadTimeoutTest.java. Or, you could update the changeset to revert all of the 
changes to ReadTimeoutTest.java except for those necessary to implement the use 
of CountDownLatch. Either way is fine with me.

Which would you prefer?

s'marks


On 12/18/13 6:51 AM, Tristan Yan wrote:
> Hi Everyone
> Please review the code fix for bug JDK-7168267
>
> http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01/ 
> 
>
> This is a cleanup for RMI tests. trying to use real timeout to replace a fixed 
> number of loop.
> Thank you
>
> Tristan
>
>
> On 12/12/2013 05:33 AM, Stuart Marks wrote:
>> On 12/10/13 6:10 PM, Tristan Yan wrote:
>>> /Hi everyone
>>> I am working on bug JDK-7168267
>>>
>>
>> Correct link is
>>
>> https://bugs.openjdk.java.net/browse/JDK-7168267
>>
>>> Root Cause:
>>> - Per Stuart's comment, this is a clean up bug.
>>>
>>> Suggested Fix:
>>> - Will use timeout to replace loop.
>>
>> We should probably look at specific cases for this. There are places where 
>> the test is waiting for some external service to become ready (e.g., 
>> rmiregistry). There's no notification for things like this so 
>> wait-with-timeout cannot be used. Pretty much the only thing that can be done 
>> is to poll reasonably often until the service is ready, or until the timeout 
>> is exceeded.
>>
>>> - Also I am fixing two test's performance
>>> java/rmi/activation/Activatable/forceLogSnapshot - method waitAllStarted is
>>> using sleep to poll 50 restartedObject to be true, we can use modern
>>> CountDownLatch to implement blocking-time wait.
>>> java/rmi/activation/Activatable/checkAnnotations - We can subclass
>>> ByteArrayOutputStream which support notification when data was written. Also 
>>> use
>>> two thread wait output string and error string to be not null.
>>
>> These sound reasonble. Go ahead and file sub-tasks for these and then choose 
>> one to work on first. (I think it will get too confusing if we try to work on 
>> them all simultaneously.) Either post a detailed description of what you 
>> intend to do, or if it's simple enough, just post a webrev.
>>
>> s'marks
>>
>>>
>>> Please let me know if you have any comments or suggestions.
>>> / /
>>> Thank you
>>> Tristan
>>>
>>> On 12/05/2013 09:02 AM, Stuart Marks wrote:
>>> /
>>>> /On 12/3/13 11:05 PM, Tristan Yan wrote:
>>>> /
>>>>> /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This 
>>>>> bug is
>>>>> asking performance improvement for RMI test. Because this would involve
>>>>> different RMI tests. I?d like to use this cr as an umbrella bug, create 
>>>>> sub-cr
>>>>> for different test. Then I can make progress on sub-cr. Please let me know 
>>>>> your
>>>>> opinion on this.
>>>>> /
>>>> /
>>>> Actually JDK-7168267 is more about various test cleanups, and JDK-8005436 is
>>>> more about performance. Both bugs, though, make general statements about "the
>>>> RMI tests" and don't have much information about specific actions that need to
>>>> be taken. I've added some notes to JDK-7168267 about some cleanups that could
>>>> be done.
>>>> / /
>>>> If there are specific actions for either of these bugs, then yes, creating
>>>> Sub-Tasks of these bugs and fixing them individually is the right thing to do.
>>>> / /
>>>> s'marks
>>>> /
>>> /
>>> /
>



From srikalyan.chandrashekar at oracle.com  Fri Dec 20 02:57:48 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Thu, 19 Dec 2013 18:57:48 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B398A2.8030307@oracle.com>
References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com>
Message-ID: <52B3B22C.20701@oracle.com>

Hi David Thanks for your comments, the unguarded part(clean and enqueue) 
in the Reference Handler thread does not seem to create any new objects, 
so it is the application(the test in this case) which is adding objects 
to heap and causing the Reference Handler to die with OOME. I am still 
unsure about the side effects of the code change and agree with your 
thoughts(on memory exhaustion test's reliability).

PS: hotspot dev alias removed from CC.

--
Thanks
kalyan

On 12/19/13 5:08 PM, David Holmes wrote:
> Hi Kalyan,
>
> This is not a hotspot issue so I'm moving this to core-libs, please 
> drop hotspot from any replies.
>
> On 20/12/2013 6:26 AM, srikalyan wrote:
>> Hi all,  I have been working on the bug JDK-8022321
>>  , this is a sporadic
>> failure and the webrev is available here
>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>
>
> I'm really not sure what to make of this. We have a test that triggers 
> an out-of-memory condition but the OOME can actually turn up in the 
> ReferenceHandler thread causing it to terminate and the test to fail. 
> We previously accounted for the non-obvious occurrences of OOME due to 
> the Object.wait and the possible need to load the InterruptedException 
> class - but still the OOME can appear where we don't want it. So 
> finally you have just placed the whole for(;;) loop in a 
> try/catch(OOME) that ignores the OOME. I'm certain that makes the test 
> happy, but I'm not sure it is really what we want for the 
> ReferenceHandler thread. If the OOME occurs while cleaning, or 
> enqueuing then we will fail to clean and/or enqueue but there would be 
> no indication that has occurred and I think that is a bigger problem 
> than this test failing.
>
> There may be no way to make this test 100% reliable. In fact I'd 
> suggest that no memory exhaustion test can be 100% reliable.
>
> David
>
>> *
>> **"Root Cause:Still not known"*
>> 2 places where there is a possibility for OOME
>> 1) Cleaner.clean()
>> 2) ReferenceQueue.enqueue()
>>
>> 1)  The cleanup code in turn has 2 places where there is potential for
>> throwing OOME,
>>      a) thunk Thread which is run from clean() method. This Runnable is
>> passed to Cleaner and appears in the following classes
>>          java/nio/DirectByteBuffer.java
>>          sun/misc/Perf.java
>>          sun/nio/fs/NativeBuffer.java
>>          sun/nio/ch/IOVecWrapper.java
>>          sun/misc/Cleaner/ExitOnThrow.java
>> However none of the above overridden implementations ever create an
>> object in the clean() code.
>>      b) new PrivilegedAction created in try catch Exception block of
>> clean() method but for this object to be created and to be held
>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>
>> 2) No new heap objects are created in the enqueue method nor anywhere in
>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>> potential cause.
>>
>> *Experimental change to java.lang.Reference.java* :
>> - Put one more guard (try catch with OOME block) in the Reference
>> Handler Thread which may give the Reference Handler a chance to cleanup.
>> This is fixing the test failure (several 1000 runs with 0 failures)
>> - Without the above change the test fails atleast 3-5 times for every
>> 1000 run.
>>
>> *PS*: The code change is to a very critical part of JDK and i am fully
>> not aware of the consequences of the change, hence seeking expert help
>> here. Appreciate your time and inputs towards this.
>>



From stuart.marks at oracle.com  Fri Dec 20 03:06:04 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 19 Dec 2013 19:06:04 -0800
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
In-Reply-To: <52B29168.9070302@oracle.com>
References: <52B29168.9070302@oracle.com>
Message-ID: <52B3B41C.8080003@oracle.com>

On 12/18/13 10:25 PM, Tristan Yan wrote:
> Hi Everyone
>
> Please help to review the fix for JDK-8030284.
>
> http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/
> 
>
> This is a one line fix that add -Xss to prevent StackOverflowError.

Hi, I guess this might make sense, but this still seems like a mystery to me.

Do we have any evidence that this test hit the stack limit but otherwise is 
behaving identically? It does load 50 classes recursively. It seems strange that 
this test apparently ran for years without problems as a shell test, but when 
run in a jtreg environment, adding the additional six or so stack frames for 
jtreg would have pushed it over the limit.

It's also kind of strange that in the two stack traces I've seen (I think I 
managed to capture only one in the bug report though) the StackOverflowError 
occurs on loading exactly the 50th class. Since we're observing intermittent 
behavior (happens sometimes but not others) the stack size is apparently 
variable. Since it's variable I'd expect to see it failing at different times, 
possibly the 49th or 48th recursive classload, not just the 50th. And in such 
circumstances, do we know what the default stack size is?

I don't know if you were able to reproduce this issue. If you were, it would be 
good to understand in more detail exactly what's going on.

s'marks


From tristan.yan at oracle.com  Fri Dec 20 04:08:42 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Fri, 20 Dec 2013 12:08:42 +0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <52B3AFAC.1080204@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>	<529FD0A9.9020400@oracle.com>
	<52A7C98E.7000200@oracle.com> <52A8DA41.1020909@oracle.com>
	<52B1B675.8090908@oracle.com> <52B3AFAC.1080204@oracle.com>
Message-ID: <52B3C2CA.2030200@oracle.com>

Thanks Stuart
I changed ReadTimeoutTest.java only apply CountdownLatch part. Please 
review.

http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.02/

Thank you
Tristan

On 12/20/2013 10:47 AM, Stuart Marks wrote:
> Hi Tristan,
>
> Changes mostly look good.
>
> There is an ignored InterruptedException in both versions of 
> UseCustomSocketFactory.java, but that was there already; it's not 
> clear what should be done in this case anyway. This is something to 
> keep in mind for a future cleanup. Hm, some duplicate code here as 
> well, again something to think about for the future.
>
> There is a serious problem with the change to ReadTimeoutTest.java, 
> however. The change removes the (old) line 72, which is
>      TestIface stub = impl.export();
> probably because there was an IDE warning that the variable "stub" is 
> unused. This much is true, but it's essential for impl.export() to be 
> called, because that exports the object, which creates a socket using 
> the socket factory, which eventually results in the fac.whichPort() 
> call below returning the port that was open. In the absence of the 
> export() call, whichPort() returns zero which causes the test to abort 
> immediately.
>
> In addition, the refactoring to use try-with-resources changes the 
> order of execution of certain code, and it changes the scope of things 
> handled by the finally-block.
>
> One purpose of the finally-block is to unexport the remote object so 
> it makes sense to begin the try-block immediately following the 
> export. The original code did this (well, only after a benign local 
> variable declaration). The change moves the try-block few lines down, 
> which means there is a larger window of time within which the 
> finally-block won't be executed. This isn't obviously a problem, but 
> it's a change nonetheless.
>
> Also, the change alters the order of opening the client socket and the 
> "connecting to listening port" message, so the message comes after the 
> port is opened, instead of before. Again, an apparently small change, 
> but if there's an exception opening the port, the port number being 
> opened won't be printed out.
>
> The main point of the changes to this file, however, is good, which is 
> to replace the unsafe use of multi-thread access to a boolean array 
> and polling of that value, with a CountDownLatch. So that part of the 
> change should go in. The problem is the apparently innocuous code 
> cleanups (use of try-with-resources, removal of apparently unused 
> local variable) which cause the test to break or otherwise change its 
> behavior.
>
> I could go ahead and push this changeset, omitting the changes to 
> ReadTimeoutTest.java. Or, you could update the changeset to revert all 
> of the changes to ReadTimeoutTest.java except for those necessary to 
> implement the use of CountDownLatch. Either way is fine with me.
>
> Which would you prefer?
>
> s'marks
>
>
> On 12/18/13 6:51 AM, Tristan Yan wrote:
>> Hi Everyone
>> Please review the code fix for bug JDK-7168267
>>
>> http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01/ 
>> 
>>
>> This is a cleanup for RMI tests. trying to use real timeout to 
>> replace a fixed number of loop.
>> Thank you
>>
>> Tristan
>>
>>
>> On 12/12/2013 05:33 AM, Stuart Marks wrote:
>>> On 12/10/13 6:10 PM, Tristan Yan wrote:
>>>> /Hi everyone
>>>> I am working on bug JDK-7168267
>>>>
>>>
>>> Correct link is
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-7168267
>>>
>>>> Root Cause:
>>>> - Per Stuart's comment, this is a clean up bug.
>>>>
>>>> Suggested Fix:
>>>> - Will use timeout to replace loop.
>>>
>>> We should probably look at specific cases for this. There are places 
>>> where the test is waiting for some external service to become ready 
>>> (e.g., rmiregistry). There's no notification for things like this so 
>>> wait-with-timeout cannot be used. Pretty much the only thing that 
>>> can be done is to poll reasonably often until the service is ready, 
>>> or until the timeout is exceeded.
>>>
>>>> - Also I am fixing two test's performance
>>>> java/rmi/activation/Activatable/forceLogSnapshot - method 
>>>> waitAllStarted is
>>>> using sleep to poll 50 restartedObject to be true, we can use modern
>>>> CountDownLatch to implement blocking-time wait.
>>>> java/rmi/activation/Activatable/checkAnnotations - We can subclass
>>>> ByteArrayOutputStream which support notification when data was 
>>>> written. Also use
>>>> two thread wait output string and error string to be not null.
>>>
>>> These sound reasonble. Go ahead and file sub-tasks for these and 
>>> then choose one to work on first. (I think it will get too confusing 
>>> if we try to work on them all simultaneously.) Either post a 
>>> detailed description of what you intend to do, or if it's simple 
>>> enough, just post a webrev.
>>>
>>> s'marks
>>>
>>>>
>>>> Please let me know if you have any comments or suggestions.
>>>> / /
>>>> Thank you
>>>> Tristan
>>>>
>>>> On 12/05/2013 09:02 AM, Stuart Marks wrote:
>>>> /
>>>>> /On 12/3/13 11:05 PM, Tristan Yan wrote:
>>>>> /
>>>>>> /I am working on 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is
>>>>>> asking performance improvement for RMI test. Because this would 
>>>>>> involve
>>>>>> different RMI tests. I?d like to use this cr as an umbrella bug, 
>>>>>> create sub-cr
>>>>>> for different test. Then I can make progress on sub-cr. Please 
>>>>>> let me know your
>>>>>> opinion on this.
>>>>>> /
>>>>> /
>>>>> Actually JDK-7168267 is more about various test cleanups, and 
>>>>> JDK-8005436 is
>>>>> more about performance. Both bugs, though, make general statements 
>>>>> about "the
>>>>> RMI tests" and don't have much information about specific actions 
>>>>> that need to
>>>>> be taken. I've added some notes to JDK-7168267 about some cleanups 
>>>>> that could
>>>>> be done.
>>>>> / /
>>>>> If there are specific actions for either of these bugs, then yes, 
>>>>> creating
>>>>> Sub-Tasks of these bugs and fixing them individually is the right 
>>>>> thing to do.
>>>>> / /
>>>>> s'marks
>>>>> /
>>>> /
>>>> /
>>
>



From david.holmes at oracle.com  Fri Dec 20 04:10:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 14:10:59 +1000
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
	test failed with 'Completed != 2'
In-Reply-To: <52A624D7.9090405@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
	<52A624D7.9090405@oracle.com>
Message-ID: <52B3C353.10904@oracle.com>

Sorry Kalyan but I don't see the need for all the incidental changes if 
the primary change is to just increase the iterations. I also don't see 
why you need to do anything for BrokenBarrierException as it is not 
expected to happen and the test should just fail if it does.

David

On 10/12/2013 6:15 AM, srikalyan wrote:
> Hi David/Martin a gentle reminder for review.
>
> --
> Thanks
> kalyan
> Ph: (408)-585-8040
>
>
> On 12/2/13, 11:21 AM, srikalyan wrote:
>> Hi David, Thanks for the review, the new webrev is hosted at
>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/
>> . Please see inline text.
>>
>> On 11/20/13, 6:35 PM, David Holmes wrote:
>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>>> I again tried and failed to reproduce a failure.  Even if I go whole
>>>> hog
>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test
>>>> continues to
>>>> PASS.  Is it just me?!
>>>
>>> I think you are going the wrong way Martin - you want the timeout to
>>> be smaller than the time it takes to execute ITERS.
>>>
>>>> I don't think there's any reason to make result long.  It's not even
>>>> used
>>>> except to inhibit hotspot optimizations.
>>>>
>>>> +        private volatile long result = 17;//Can get int overflow,so
>>>> using long
>>>
>>> Further the subsequent use of += is incorrect as it is not an atomic
>>> operation. Even if we don't care about the value, it looks bad.
>> Made the necessary changes for atomic update.
>>>
>>> I'm not sure result must be updated if we get a
>>> BrokenBarrierException either. Probably harmless, but necessary?
>> I retained it in the fix for completeness in updating the numbers,
>> please let me know if you still think otherwise.
>>>
>>>> need to fix spelling and spacing below.
>>>>
>>>> +                barrier.await();//If a BrokeBarrierException happens
>>>> here(due to
>>>
>>> There are a number of style issues with spacing around comments.
>> Fixed the spelling error and styling issues.
>>>
>>> And I don't think this change is sufficient to claim co-author status
>>> with Doug either ;-)
>> Removed the claim :)
>>>
>>> The additional tracing may be useful but seems stylistically
>>> different from the rest of the code.
>> Retained the tracking to understand if it is again the timing issue
>> which is the cause in an event of a failure, however i can remove it
>> if you think it is not necessary (OR) include an alternate solution as
>> you may want to suggest.
>>>
>>> Overall I'm suspicious that the changed timeout actually fixes
>>> anything - normally we need to add longer timeouts not shorter ones.
>>> Does this fail on a range of machines or only specific ones? Have we
>>> verified that the clocks/timers are behaving properly on those systems?
>> Here the time out is not about waiting for threads to complete
>> something but to "be interrupted" before being considered done, so we
>> decreased the timeout. However we now chose to increase the number of
>> iterations to 5000000 from 1000000(thanks to tristan for the
>> suggestion) instead of decreasing the timeout as done earlier because
>> the increasing iterations ensures the threads are busy for long time
>> curtailing the need to touch the timeout.
>>
>>>
>>> Thanks,
>>> David
>>
>> --
>> Thanks
>> kalyan
>> Ph: (408)-585-8040
>>
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>
>>>>>   Hi Martin , apologies for the delay , was trying to get help for
>>>>> hosting
>>>>> my webrev.  .  Please see inline text.
>>>>>
>>>>>
>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>>
>>>>> Hi Kalyan,
>>>>>
>>>>>   None of us can review your changes yet because you haven't given
>>>>> us a
>>>>> URL of your webrev.
>>>>>
>>>>> It is located here
>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/
>>>>>
>>>>>
>>>>>
>>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test
>>>>> just keeps
>>>>> on passing for me.  Hints appreciated.
>>>>>
>>>>> Bump up the timeout to 500ms and you will see a failure (i can see it
>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8
>>>>> latest any promoted build).
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>
>>>>>>     Suggested Fix:
>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that
>>>>>>> the test
>>>>>>> will pass even on faster machines
>>>>>>>
>>>>>>
>>>>>   This doesn't look like a permanent fix - it just makes the
>>>>> failing case
>>>>> rarer.
>>>>>
>>>>> Thats true , the other way is to make the main thread wait on TIMEOUT
>>>>> after firing the interrupts instead of other way round, but that
>>>>> would be
>>>>> over-optimization which probably is not desirable as well.  The 50
>>>>> ms was
>>>>> arrived at empirically after running several 100 times on multiple
>>>>> configurations and did not cause failures.
>>>>>
>>>>> --
>>>>> Thanks
>>>>> kalyan
>>>>> Ph: (408)-585-8040
>>>>>
>>>>>
>>>>>


From david.holmes at oracle.com  Fri Dec 20 04:18:09 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 14:18:09 +1000
Subject: RFR for JDK-6963118 Intermittent test failure:
	test/java/nio/channels/Selector/Wakeup.java fail intermittently (win)
In-Reply-To: <529D4473.8060909@oracle.com>
References: <529D4473.8060909@oracle.com>
Message-ID: <52B3C501.2020006@oracle.com>

This should probably be reviewed by the nio-dev folk.

Increasing the timeouts seems okay but how confident are you that this 
is sufficient for a wide range of platforms. In other tests we often see 
timeouts of a few seconds get extended even further, so three seconds is 
not so big.

Also the yield loops:

while (sleeper.entries < 5)
     Thread.yield();

would be better as sleep loops (as used elsewhere) to avoid potential 
issues with yield being a no-op on some platforms (Yes I see it is 
already used that way elsewhere in the test but the sleep is better :) ).

Thanks,
David

On 3/12/2013 12:39 PM, srikalyan chandrashekar wrote:
> Hi all, I am working on bug JDK-6963118
>  .
> Root Cause:
> - Sensitive timing dependency between events in Main and Sleeper threads
> are causes for test failure.
>
> Suggested Fix:
>    1) Main thread should wait for more than 1sec(made it 3sec) and check
> more often than 50ms(made it 1ms) intervals , sleeper thread may be
> still waiting for interrupt/wakeup hence main thread waiting for just
> 1sec to flag a failure is premature . The reason is especially on
> windows high priority virus scanners etc run(we faced it when simulating
> failures) and kept the system busy.
>    2) The test is essentially a sequence of 2 events
>    a)Firing up wakeups/interrupts followed by a
>    b)Check
>   Check the sleeper.entries value and yield the main thread as required
> so that the above 2 events step in tandem.
>
> The webrev is hosted at
> http://cr.openjdk.java.net/~cl/host_for_kal/6963118-Wakeup/ .
> Please let me know if you have any comments or suggestions.
>


From david.holmes at oracle.com  Fri Dec 20 04:29:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 14:29:25 +1000
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
In-Reply-To: <52B3B41C.8080003@oracle.com>
References: <52B29168.9070302@oracle.com> <52B3B41C.8080003@oracle.com>
Message-ID: <52B3C7A5.7050705@oracle.com>

Hi Stuart,

On 20/12/2013 1:06 PM, Stuart Marks wrote:
> On 12/18/13 10:25 PM, Tristan Yan wrote:
>> Hi Everyone
>>
>> Please help to review the fix for JDK-8030284.
>>
>> http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/
>> 
>>
>> This is a one line fix that add -Xss to prevent StackOverflowError.
>
> Hi, I guess this might make sense, but this still seems like a mystery
> to me.
>
> Do we have any evidence that this test hit the stack limit but otherwise
> is behaving identically? It does load 50 classes recursively. It seems
> strange that this test apparently ran for years without problems as a
> shell test, but when run in a jtreg environment, adding the additional
> six or so stack frames for jtreg would have pushed it over the limit.

If you were always one frame from the end then it is not so surprising 
that a simple change pushes you past the limit :) Try running the shell 
test with additional recursive loads and see when it fails.

> It's also kind of strange that in the two stack traces I've seen (I
> think I managed to capture only one in the bug report though) the
> StackOverflowError occurs on loading exactly the 50th class. Since we're
> observing intermittent behavior (happens sometimes but not others) the
> stack size is apparently variable. Since it's variable I'd expect to see
> it failing at different times, possibly the 49th or 48th recursive
> classload, not just the 50th. And in such circumstances, do we know what
> the default stack size is?

Classloading consumes a reasonable chunk of stack so if the variance 
elsewhere is quite small it is not that surprising that the test always 
fails on the 50th class. I would not expect run-to-run stack usage 
variance to be high unless there is some random component to the test.

> I don't know if you were able to reproduce this issue. If you were, it
> would be good to understand in more detail exactly what's going on.

FWIW there was a recent change in 7u to bump up the number of stack 
shadow pages in hotspot as "suddenly" StackOverflow tests were crashing 
instead of triggering StackOverflowError. So something started using 
more stack in a way the caused there to not be enough space to process a 
stackoverflow properly. Finding the exact cause can be somewhat tedious.

Cheers,
David

> s'marks


From mandy.chung at oracle.com  Fri Dec 20 04:33:18 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Dec 2013 20:33:18 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B3B22C.20701@oracle.com>
References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com>
	<52B3B22C.20701@oracle.com>
Message-ID: <52B3C88E.2030502@oracle.com>

Hi Srikalyan,

Maybe you can get add an uncaught handler to see if you can get
any information.  I ran it for 1000 times but not able to duplicate
the failure.  Did you run it with jtreg (I didn't)?

Below is the patch to install a thread's uncaught handler that
you can take and try.

diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java b/test/java/lang/ref/OOMEInReferenceHand
ler.java
--- a/test/java/lang/ref/OOMEInReferenceHandler.java
+++ b/test/java/lang/ref/OOMEInReferenceHandler.java
@@ -51,6 +51,14 @@
           return first;
       }

+     static class UEH implements Thread.UncaughtExceptionHandler {
+         public void uncaughtException(Thread t, Throwable e) {
+             System.err.println("ERROR: " + t.getName() + " exception " +
+                 e.getMessage());
+             e.printStackTrace();
+         }
+     }
+
       public static void main(String[] args) throws Exception {
           // preinitialize the InterruptedException class so that the reference handler
           // does not die due to OOME when loading the class if it is the first use
@@ -77,6 +85,8 @@
               throw new IllegalStateException("Couldn't find Reference Handler thread.");
           }

+         referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
+
           ReferenceQueue refQueue = new ReferenceQueue<>();
           Object referent = new Object();
           WeakReference weakRef = new WeakReference<>(referent, refQueue);

On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
> Hi David Thanks for your comments, the unguarded part(clean and 
> enqueue) in the Reference Handler thread does not seem to create any 
> new objects, so it is the application(the test in this case) which is 
> adding objects to heap and causing the Reference Handler to die with 
> OOME. I am still unsure about the side effects of the code change and 
> agree with your thoughts(on memory exhaustion test's reliability).
>
> PS: hotspot dev alias removed from CC.
>
> -- 
> Thanks
> kalyan
>
> On 12/19/13 5:08 PM, David Holmes wrote:
>> Hi Kalyan,
>>
>> This is not a hotspot issue so I'm moving this to core-libs, please 
>> drop hotspot from any replies.
>>
>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>> Hi all,  I have been working on the bug JDK-8022321
>>>  , this is a sporadic
>>> failure and the webrev is available here
>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>>
>>
>> I'm really not sure what to make of this. We have a test that 
>> triggers an out-of-memory condition but the OOME can actually turn up 
>> in the ReferenceHandler thread causing it to terminate and the test 
>> to fail. We previously accounted for the non-obvious occurrences of 
>> OOME due to the Object.wait and the possible need to load the 
>> InterruptedException class - but still the OOME can appear where we 
>> don't want it. So finally you have just placed the whole for(;;) loop 
>> in a try/catch(OOME) that ignores the OOME. I'm certain that makes 
>> the test happy, but I'm not sure it is really what we want for the 
>> ReferenceHandler thread. If the OOME occurs while cleaning, or 
>> enqueuing then we will fail to clean and/or enqueue but there would 
>> be no indication that has occurred and I think that is a bigger 
>> problem than this test failing.
>>
>> There may be no way to make this test 100% reliable. In fact I'd 
>> suggest that no memory exhaustion test can be 100% reliable.
>>
>> David
>>
>>> *
>>> **"Root Cause:Still not known"*
>>> 2 places where there is a possibility for OOME
>>> 1) Cleaner.clean()
>>> 2) ReferenceQueue.enqueue()
>>>
>>> 1)  The cleanup code in turn has 2 places where there is potential for
>>> throwing OOME,
>>>      a) thunk Thread which is run from clean() method. This Runnable is
>>> passed to Cleaner and appears in the following classes
>>>          java/nio/DirectByteBuffer.java
>>>          sun/misc/Perf.java
>>>          sun/nio/fs/NativeBuffer.java
>>>          sun/nio/ch/IOVecWrapper.java
>>>          sun/misc/Cleaner/ExitOnThrow.java
>>> However none of the above overridden implementations ever create an
>>> object in the clean() code.
>>>      b) new PrivilegedAction created in try catch Exception block of
>>> clean() method but for this object to be created and to be held
>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>
>>> 2) No new heap objects are created in the enqueue method nor 
>>> anywhere in
>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>> potential cause.
>>>
>>> *Experimental change to java.lang.Reference.java* :
>>> - Put one more guard (try catch with OOME block) in the Reference
>>> Handler Thread which may give the Reference Handler a chance to 
>>> cleanup.
>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>> - Without the above change the test fails atleast 3-5 times for every
>>> 1000 run.
>>>
>>> *PS*: The code change is to a very critical part of JDK and i am fully
>>> not aware of the consequences of the change, hence seeking expert help
>>> here. Appreciate your time and inputs towards this.
>>>
>



From david.holmes at oracle.com  Fri Dec 20 06:49:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Dec 2013 16:49:15 +1000
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B3B22C.20701@oracle.com>
References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com>
	<52B3B22C.20701@oracle.com>
Message-ID: <52B3E86B.3050707@oracle.com>

On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote:
> Hi David Thanks for your comments, the unguarded part(clean and enqueue)
> in the Reference Handler thread does not seem to create any new objects,
> so it is the application(the test in this case) which is adding objects
> to heap and causing the Reference Handler to die with OOME.

The ReferenceHandler thread can only get OOME if it allocates (directly 
or indirectly) - so there has to be something in the unguarded part that 
causes this. Again it may be an implicit action in the VM - similar to 
the class load issue for InterruptedException.

David

I am still
> unsure about the side effects of the code change and agree with your
> thoughts(on memory exhaustion test's reliability).
>
> PS: hotspot dev alias removed from CC.
>
> --
> Thanks
> kalyan
>
> On 12/19/13 5:08 PM, David Holmes wrote:
>> Hi Kalyan,
>>
>> This is not a hotspot issue so I'm moving this to core-libs, please
>> drop hotspot from any replies.
>>
>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>> Hi all,  I have been working on the bug JDK-8022321
>>>  , this is a sporadic
>>> failure and the webrev is available here
>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/
>>>
>>
>> I'm really not sure what to make of this. We have a test that triggers
>> an out-of-memory condition but the OOME can actually turn up in the
>> ReferenceHandler thread causing it to terminate and the test to fail.
>> We previously accounted for the non-obvious occurrences of OOME due to
>> the Object.wait and the possible need to load the InterruptedException
>> class - but still the OOME can appear where we don't want it. So
>> finally you have just placed the whole for(;;) loop in a
>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test
>> happy, but I'm not sure it is really what we want for the
>> ReferenceHandler thread. If the OOME occurs while cleaning, or
>> enqueuing then we will fail to clean and/or enqueue but there would be
>> no indication that has occurred and I think that is a bigger problem
>> than this test failing.
>>
>> There may be no way to make this test 100% reliable. In fact I'd
>> suggest that no memory exhaustion test can be 100% reliable.
>>
>> David
>>
>>> *
>>> **"Root Cause:Still not known"*
>>> 2 places where there is a possibility for OOME
>>> 1) Cleaner.clean()
>>> 2) ReferenceQueue.enqueue()
>>>
>>> 1)  The cleanup code in turn has 2 places where there is potential for
>>> throwing OOME,
>>>      a) thunk Thread which is run from clean() method. This Runnable is
>>> passed to Cleaner and appears in the following classes
>>>          java/nio/DirectByteBuffer.java
>>>          sun/misc/Perf.java
>>>          sun/nio/fs/NativeBuffer.java
>>>          sun/nio/ch/IOVecWrapper.java
>>>          sun/misc/Cleaner/ExitOnThrow.java
>>> However none of the above overridden implementations ever create an
>>> object in the clean() code.
>>>      b) new PrivilegedAction created in try catch Exception block of
>>> clean() method but for this object to be created and to be held
>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>
>>> 2) No new heap objects are created in the enqueue method nor anywhere in
>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>> potential cause.
>>>
>>> *Experimental change to java.lang.Reference.java* :
>>> - Put one more guard (try catch with OOME block) in the Reference
>>> Handler Thread which may give the Reference Handler a chance to cleanup.
>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>> - Without the above change the test fails atleast 3-5 times for every
>>> 1000 run.
>>>
>>> *PS*: The code change is to a very critical part of JDK and i am fully
>>> not aware of the consequences of the change, hence seeking expert help
>>> here. Appreciate your time and inputs towards this.
>>>
>


From chris.hegarty at oracle.com  Fri Dec 20 09:54:09 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Dec 2013 09:54:09 +0000
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B3C88E.2030502@oracle.com>
References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com>
	<52B3B22C.20701@oracle.com> <52B3C88E.2030502@oracle.com>
Message-ID: <4D6B1813-EEB6-4388-9FC7-2E0BDF004222@oracle.com>


On 20 Dec 2013, at 04:33, Mandy Chung  wrote:

> Hi Srikalyan,
> 
> Maybe you can get add an uncaught handler to see if you can get
> any information.  

+1. With this, at least the next time we see this failure we should have a better idea where the OOM is coming from.

-Chris.

> I ran it for 1000 times but not able to duplicate
> the failure.  Did you run it with jtreg (I didn't)?
> 
> Below is the patch to install a thread's uncaught handler that
> you can take and try.
> 
> diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java b/test/java/lang/ref/OOMEInReferenceHand
> ler.java
> --- a/test/java/lang/ref/OOMEInReferenceHandler.java
> +++ b/test/java/lang/ref/OOMEInReferenceHandler.java
> @@ -51,6 +51,14 @@
>          return first;
>      }
> 
> +     static class UEH implements Thread.UncaughtExceptionHandler {
> +         public void uncaughtException(Thread t, Throwable e) {
> +             System.err.println("ERROR: " + t.getName() + " exception " +
> +                 e.getMessage());
> +             e.printStackTrace();
> +         }
> +     }
> +
>      public static void main(String[] args) throws Exception {
>          // preinitialize the InterruptedException class so that the reference handler
>          // does not die due to OOME when loading the class if it is the first use
> @@ -77,6 +85,8 @@
>              throw new IllegalStateException("Couldn't find Reference Handler thread.");
>          }
> 
> +         referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
> +
>          ReferenceQueue refQueue = new ReferenceQueue<>();
>          Object referent = new Object();
>          WeakReference weakRef = new WeakReference<>(referent, refQueue);
> 
> On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
>> Hi David Thanks for your comments, the unguarded part(clean and enqueue) in the Reference Handler thread does not seem to create any new objects, so it is the application(the test in this case) which is adding objects to heap and causing the Reference Handler to die with OOME. I am still unsure about the side effects of the code change and agree with your thoughts(on memory exhaustion test's reliability).
>> 
>> PS: hotspot dev alias removed from CC.
>> 
>> -- 
>> Thanks
>> kalyan
>> 
>> On 12/19/13 5:08 PM, David Holmes wrote:
>>> Hi Kalyan,
>>> 
>>> This is not a hotspot issue so I'm moving this to core-libs, please drop hotspot from any replies.
>>> 
>>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>>> Hi all,  I have been working on the bug JDK-8022321
>>>>  , this is a sporadic
>>>> failure and the webrev is available here
>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>> 
>>> I'm really not sure what to make of this. We have a test that triggers an out-of-memory condition but the OOME can actually turn up in the ReferenceHandler thread causing it to terminate and the test to fail. We previously accounted for the non-obvious occurrences of OOME due to the Object.wait and the possible need to load the InterruptedException class - but still the OOME can appear where we don't want it. So finally you have just placed the whole for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm certain that makes the test happy, but I'm not sure it is really what we want for the ReferenceHandler thread. If the OOME occurs while cleaning, or enqueuing then we will fail to clean and/or enqueue but there would be no indication that has occurred and I think that is a bigger problem than this test failing.
>>> 
>>> There may be no way to make this test 100% reliable. In fact I'd suggest that no memory exhaustion test can be 100% reliable.
>>> 
>>> David
>>> 
>>>> *
>>>> **"Root Cause:Still not known"*
>>>> 2 places where there is a possibility for OOME
>>>> 1) Cleaner.clean()
>>>> 2) ReferenceQueue.enqueue()
>>>> 
>>>> 1)  The cleanup code in turn has 2 places where there is potential for
>>>> throwing OOME,
>>>>     a) thunk Thread which is run from clean() method. This Runnable is
>>>> passed to Cleaner and appears in the following classes
>>>>         java/nio/DirectByteBuffer.java
>>>>         sun/misc/Perf.java
>>>>         sun/nio/fs/NativeBuffer.java
>>>>         sun/nio/ch/IOVecWrapper.java
>>>>         sun/misc/Cleaner/ExitOnThrow.java
>>>> However none of the above overridden implementations ever create an
>>>> object in the clean() code.
>>>>     b) new PrivilegedAction created in try catch Exception block of
>>>> clean() method but for this object to be created and to be held
>>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>> 
>>>> 2) No new heap objects are created in the enqueue method nor anywhere in
>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>>> potential cause.
>>>> 
>>>> *Experimental change to java.lang.Reference.java* :
>>>> - Put one more guard (try catch with OOME block) in the Reference
>>>> Handler Thread which may give the Reference Handler a chance to cleanup.
>>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>>> - Without the above change the test fails atleast 3-5 times for every
>>>> 1000 run.
>>>> 
>>>> *PS*: The code change is to a very critical part of JDK and i am fully
>>>> not aware of the consequences of the change, hence seeking expert help
>>>> here. Appreciate your time and inputs towards this.
>>>> 
>> 
> 



From paul.sandoz at oracle.com  Fri Dec 20 10:30:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Dec 2013 11:30:03 +0100
Subject: RFR of lang level code migration patches
In-Reply-To: <52B3228B.6040303@oracle.com>
References: 
	<52B3228B.6040303@oracle.com>
Message-ID: <99C02A6A-2C6A-4876-B19A-FB5BF154A8C6@oracle.com>

On Dec 19, 2013, at 5:44 PM, Brian Goetz  wrote:
> +1 on all changes, except perhaps for this one in Collections.copy:
> 
> ListIterator di=dest.listIterator();
>              ListIterator si=src.listIterator();
>              for (int i=0; i                  di.next();
>                  di.set(si.next());
>              }
> 
> The code is bizarre enough (calling next based on a range loop rather than hasNext()) to leave alone.
> 

Well spotted. I guess the reason is performance, since the size constraints are checked before looping there is no need to call hasNext (probably for the second time since next will probably call it :-) ).


On Dec 19, 2013, at 8:22 PM, Mike Duigou  wrote:
>> Compress catches
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
> 
> The comment in JarVerifier "// e.g. sun.security.pkcs.ParsingException" is now probably too broad to be useful. Maybe just remove it.

Done.


On Dec 19, 2013, at 7:33 PM, Alan Bateman  wrote:
> I skimmed over the changes too and they look okay. I'm sometimes wary of IDEs re-arranging things but there's nothing here.

Yes, it is important to verify what the IDE is doing rather, more so for non-diamond-like transformations, as it sometimes gets it wrong and may monkey around with formatting [*].


> It would be good to get a few other areas done too while things are quiet.
> 

Yes. Both NetBeans and IntelliJ have the appropriate refactoring capabilities.

I can take on java.lang.

Paul.

[*] are we ever likely to agree on a single, tool-compatible, code format in the JDK before the heat death of the universe?

From aleksej.efimov at oracle.com  Fri Dec 20 11:39:14 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 20 Dec 2013 15:39:14 +0400
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B2A8A6.4020903@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
Message-ID: <52B42C62.9090603@oracle.com>

Masayoshi,
Thank you for the detailed review and your comments. I tried to address 
all of them. The responses are below. The new webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 


Michael,
As Masayoshi mentioned, we have a list of inconsistent translations in 
translation files. I suggest two approaches to resolve it: 1. Log 
different bug with all problems in translation files. 2. Wait for the 
next resource file translation update to address these problems.

-Aleksej

On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>> fix includes:
>
> Common to all modified files:
> - All year ranges in the copyright header should be modified accordingly.

Fixed.

>
>>  - The translation of time zone generic names were added to all locales.
>
> I haven't fully reviewed translations, especially all \uxxxx strings. 
> But I noticed the following.
>
> Common to all TimeZoneNames_*.java:
> - The same generic abbreviation is used for the long name in MET. I 
> thought this was fixed in the root properties...

No, the "MET" is used in root properties both for generic long and short 
names. I will update these names when new translation update will be 
available.

> - Some generic names don't match the style of their standard and/or 
> daylight time names.

The same as previous. This is a first large update for generic names and 
latest translations. All inconsistency in translations will be fixed 
during next translation update.

>
> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
> - Some generic names use "Normalzeit". Is that OK?

It's not good. But the resolution is same as previous two.

>
> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
> - "Chuuk Time" isn't translated.

I think it will be translated in next translations update.

>
>>  - Time Zone names were updated according to the latest translations.
>>  - Added tz names regression test 
>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
>> across all locales. This test compares short/long 
>> standard/daylight/generic names with translations stored in 
>> .properties files.
>
> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>
> - lines 33, 34: unused imports?

Removed

> - line 75: Should it be detected as an error?

Agree, now the test will fail if there is some incorrect entries in the 
test .properties files.

> - line 108: IOException should be used as a cause. (OK to assume "not 
> found"?)

The IOException cause is added. Currently, the test will stop with 
RuntimeException, because the test file is not found.

> - lines 118 -121: Locale.getDefault() has to be replaced with 
> Locale.ROOT. Regression tests are run in different locales.

Thank you for catching this one. Fixed.

>
>>  - Tests updates to address current changes ( 
>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>
> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
> removed.

Removed

>
>>
>> The following fix was tested with JPRT build and the 'jdk_util' test 
>> set succeeded (new test is included in this test set).
>
> Have you executed all date-time related regression tests (including 
> java.time and java.text)?

Yes, I have executed the following set of tests via JTREG:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/closed/java/util/TimeZone test/java/util/TimeZone
  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
All tests gave "PASS" results.
Please, let me know if you think that some other tests should be executed.


>
> Thanks,
> Masayoshi
>
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>
>



From sergey.lugovoy at oracle.com  Fri Dec 20 14:16:34 2013
From: sergey.lugovoy at oracle.com (Serge)
Date: Fri, 20 Dec 2013 18:16:34 +0400
Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
In-Reply-To: <43E97AF9-B53D-44EE-9F28-AD561C51F2D2@oracle.com>
References: <52A0B6EE.5040207@oracle.com> <52A09C4A.9000902@oracle.com>
	<43E97AF9-B53D-44EE-9F28-AD561C51F2D2@oracle.com>
Message-ID: <52B45142.4030103@oracle.com>

Hi all.

Please review a second fix
http://cr.openjdk.java.net/~yan/8028712/webrev.03/

for
https://bugs.openjdk.java.net/browse/JDK-8028712

I deleted part of java/sql/package.html,
and replaced "br/" to "br" for compliance with html 3.2


On 12/05/2013 10:39 PM, Lance Andersen - Oracle wrote:
> Hi Serge
>
>
>
> This looks OK.
>
>
>
> For
>
> --- old/src/share/classes/java/sql/package.html	2013-12-05 15:08:50.587885460 +0000
> +++ new/src/share/classes/java/sql/package.html	2013-12-05 15:08:50.435885464 +0000
>
> Please remove the following
>
> --------------------
> Package Specification
>
> 	. Specification of the JDBC 4.0 API
> Related Documentation
>
> 	. Getting Started--overviews of the major interfaces
> 	. Chapters on the JDBC API--from the online version of The Java Tutorial Continued
> 	. JDBCTMAPI Tutorial and Reference, Third Edition-- a complete reference and tutorial for the JDBC 3.0 API
>
> ----------------
>
> The above links keep breaking now that we are off of java.sun.com
>
> And I agree with roger, please use 
        
>
>
> Alan, yes I can look to clean up some of the formatting crud for Java SE 9 once we have access to the workspace
>
> Thank you for doing this Serge.
>
> Best
> Lance
> On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote:
>
>> On 05/12/2013 17:25, Serge wrote:
>>> Hi all,
>>> please review the fix
>>> http://cr.openjdk.java.net/~yan/8028712/webrev.02/ 
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8028712
>>>
>>> This patch cleanup tidy warnings for generated html documentation, and do
>>> not affect the appearance of the documentation.
>> The removal of the 
         tags seems okay. The only thing that I'm not sure about the addition of 
         to the package docs (is that needed?).
>>
>> Lance - while scanning this patch then it appears that some of the formatting in the javadoc comments is all over the place (java.sql.Connection is one example). It might be good to clean that up once the jdk9 project is open for business.
>>
>> -Alan
>>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From Alan.Bateman at oracle.com  Fri Dec 20 15:03:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Dec 2013 15:03:56 +0000
Subject: RFR for JDK-6963118 Intermittent test failure:
	test/java/nio/channels/Selector/Wakeup.java fail intermittently (win)
In-Reply-To: <52B3C501.2020006@oracle.com>
References: <529D4473.8060909@oracle.com> <52B3C501.2020006@oracle.com>
Message-ID: <52B45C5C.3030501@oracle.com>

On 20/12/2013 04:18, David Holmes wrote:
> :
>
> Increasing the timeouts seems okay but how confident are you that this 
> is sufficient for a wide range of platforms. In other tests we often 
> see timeouts of a few seconds get extended even further, so three 
> seconds is not so big.
>
> Also the yield loops:
>
> while (sleeper.entries < 5)
>     Thread.yield();
>
> would be better as sleep loops (as used elsewhere) to avoid potential 
> issues with yield being a no-op on some platforms (Yes I see it is 
> already used that way elsewhere in the test but the sleep is better :) ).
Kalyan started another thread on this one and in the latest revision 
then the timeout has been increased to 10 seconds.

I agree, it would be better to use a small sleep rather than yield.

-Alan.


From paul.sandoz at oracle.com  Fri Dec 20 15:53:46 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Dec 2013 16:53:46 +0100
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
Message-ID: <057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>

Hi Brian,

It would be nice to avoid the caches, on a hunch i am wondering if the following will work:

  long result = first * radix + second;
  if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow of first * radix
    Long.compareUnsigned(result, first) < 0) {  // overflow of  first * radix + second

It should be possible to write some tests creating strings in the appropriate base to select the appropriate value for first will kick off an overflow.

Paul.
 
On Dec 19, 2013, at 9:21 PM, Brian Burkhalter  wrote:

> Here's a formalization of the suggested fix:
> 
> http://cr.openjdk.java.net/~bpb/8030814/webrev/
> 
> It works against the test case.
> 
> Brian
> 
> On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
> 
>> Upon inspection only that indeed looks correct.
>> 
>> Thanks ?
>> 
>> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
>> 
>>> Here's one approach that works: there is overflow iff 
>>> 
>>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 || (first == divideUnsigned(MAX_UNSIGNED, radix) && second > remainderUnsigned(MAX_UNSIGNED, radix));
>>> 
>>> Since radix <= Character.MAX_RADIX, you can precompute the divides and remainders in a small table.
>> 
> 


From dmitry.nadezhin at gmail.com  Fri Dec 20 16:54:52 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 20 Dec 2013 20:54:52 +0400
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
Message-ID: 

What is performance of Long.compareUnsigned(x, y) ?
Does HotSpot implement it as a call of Long.compare(x + MIN_VALUE, y +
MIN_VALUE) or as a single machine instruction ?



On Fri, Dec 20, 2013 at 7:53 PM, Paul Sandoz  wrote:

> Hi Brian,
>
> It would be nice to avoid the caches, on a hunch i am wondering if the
> following will work:
>
>   long result = first * radix + second;
>   if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow of
> first * radix
>     Long.compareUnsigned(result, first) < 0) {  // overflow of  first *
> radix + second
>
> It should be possible to write some tests creating strings in the
> appropriate base to select the appropriate value for first will kick off an
> overflow.
>
> Paul.
>
> On Dec 19, 2013, at 9:21 PM, Brian Burkhalter 
> wrote:
>
> > Here's a formalization of the suggested fix:
> >
> > http://cr.openjdk.java.net/~bpb/8030814/webrev/
> >
> > It works against the test case.
> >
> > Brian
> >
> > On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
> >
> >> Upon inspection only that indeed looks correct.
> >>
> >> Thanks ?
> >>
> >> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
> >>
> >>> Here's one approach that works: there is overflow iff
> >>>
> >>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 ||
> (first == divideUnsigned(MAX_UNSIGNED, radix) && second >
> remainderUnsigned(MAX_UNSIGNED, radix));
> >>>
> >>> Since radix <= Character.MAX_RADIX, you can precompute the divides and
> remainders in a small table.
> >>
> >
>
>


From paul.sandoz at oracle.com  Fri Dec 20 17:25:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Dec 2013 18:25:00 +0100
Subject: Demo for Parallel Core Collection API
In-Reply-To: <52B2E3A5.3070807@oracle.com>
References: 
	<2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com>
	
	<36B4EDF7-15DE-482C-AFB7-511A03BCDC92@oracle.com>
	<52B2E3A5.3070807@oracle.com>
Message-ID: <301A54AB-CD30-4763-8370-540C3B6D1914@oracle.com>

Hi Tristan,

Thanks, I need to look at this in more detail, but here are some quick comments.

- recommend you try and avoid using limit with parallel ops, for example the Pi example cam be reformulated as:

       long M = LongStream.range(0, N).parallel().filter(sr -> {
           double x = ThreadLocalRandom.current().nextDouble(-1, 1);
           double y = ThreadLocalRandom.current().nextDouble(-1, 1);

           return x * x + y * y < R * R;  // Don't use need to use sqrt
       }).count();
      double pi = (M / N) * 4.0;

the Primes example could be reformulated as:

   LongStream.range(0, limit).parallel().map(/odd values/).filter(RandomPrimeNumber::isPrime).findAny();

you don't need to declare unordered() since findAny implicitly makes the stream unordered by definition.

The key message here is range has better decomposition characteristics than generate or iterate.

More later, probably after the break,
Paul.

On Dec 19, 2013, at 1:16 PM, Tristan Yan  wrote:

> Hi Paul And Everyone
> Sorry for getting back late.
> I took Paul's suggestion and have written other two demos which presents usage of parallel computation. One is using Monte-Carlo to calculate value of PI. Other is find a big prime by given length. Please review it.
> http://cr.openjdk.java.net/~tyan/sample/webrev.00/
> There is another demo which present mandelbrot set was designed Alexander Kouznetsov has been already in reviewing. It's not my code review request.
> Thank you very much
> Tristan


From huizhe.wang at oracle.com  Fri Dec 20 17:52:42 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Fri, 20 Dec 2013 17:52:42 +0000
Subject: hg: jdk8/tl/jaxp: 8029955: AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
Message-ID: <20131220175245.EC28362E51@hg.openjdk.java.net>

Changeset: 1bedbbce236a
Author:    joehw
Date:      2013-12-20 09:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1bedbbce236a

8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars
Reviewed-by: dfuchs, lancea, ulfzibis

! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java



From huizhe.wang at oracle.com  Fri Dec 20 17:56:50 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Fri, 20 Dec 2013 17:56:50 +0000
Subject: hg: jdk8/tl/jdk: 8029955: AIOB in XMLEntityScanner.scanLiteral upon
	parsing literals with > 100 LF chars
Message-ID: <20131220175726.27E5B62E52@hg.openjdk.java.net>

Changeset: 73473e9dfc46
Author:    joehw
Date:      2013-12-20 09:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73473e9dfc46

8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars
Reviewed-by: dfuchs, lancea, ulfzibis

+ test/javax/xml/jaxp/parsers/8029955/EntityScannerTest.java



From srikalyan.chandrashekar at oracle.com  Fri Dec 20 18:19:39 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan)
Date: Fri, 20 Dec 2013 10:19:39 -0800
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
	test failed with 'Completed != 2'
In-Reply-To: <52B3C353.10904@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
	<52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com>
Message-ID: <52B48A3B.8040002@oracle.com>

Hi David, i retained only the changes to ITERS, ProbleMList.txt and 
upstream changes by Doug Lea(as pointed by Martin), could you please 
review the new change available here 
http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/ 
.

--
Thanks
kalyan
Ph: (408)-585-8040


On 12/19/13, 8:10 PM, David Holmes wrote:
> Sorry Kalyan but I don't see the need for all the incidental changes 
> if the primary change is to just increase the iterations. I also don't 
> see why you need to do anything for BrokenBarrierException as it is 
> not expected to happen and the test should just fail if it does.
>
> David
>
> On 10/12/2013 6:15 AM, srikalyan wrote:
>> Hi David/Martin a gentle reminder for review.
>>
>> -- 
>> Thanks
>> kalyan
>> Ph: (408)-585-8040
>>
>>
>> On 12/2/13, 11:21 AM, srikalyan wrote:
>>> Hi David, Thanks for the review, the new webrev is hosted at
>>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/
>>> . Please see inline text.
>>>
>>> On 11/20/13, 6:35 PM, David Holmes wrote:
>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>>>> I again tried and failed to reproduce a failure.  Even if I go whole
>>>>> hog
>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test
>>>>> continues to
>>>>> PASS.  Is it just me?!
>>>>
>>>> I think you are going the wrong way Martin - you want the timeout to
>>>> be smaller than the time it takes to execute ITERS.
>>>>
>>>>> I don't think there's any reason to make result long.  It's not even
>>>>> used
>>>>> except to inhibit hotspot optimizations.
>>>>>
>>>>> +        private volatile long result = 17;//Can get int overflow,so
>>>>> using long
>>>>
>>>> Further the subsequent use of += is incorrect as it is not an atomic
>>>> operation. Even if we don't care about the value, it looks bad.
>>> Made the necessary changes for atomic update.
>>>>
>>>> I'm not sure result must be updated if we get a
>>>> BrokenBarrierException either. Probably harmless, but necessary?
>>> I retained it in the fix for completeness in updating the numbers,
>>> please let me know if you still think otherwise.
>>>>
>>>>> need to fix spelling and spacing below.
>>>>>
>>>>> +                barrier.await();//If a BrokeBarrierException happens
>>>>> here(due to
>>>>
>>>> There are a number of style issues with spacing around comments.
>>> Fixed the spelling error and styling issues.
>>>>
>>>> And I don't think this change is sufficient to claim co-author status
>>>> with Doug either ;-)
>>> Removed the claim :)
>>>>
>>>> The additional tracing may be useful but seems stylistically
>>>> different from the rest of the code.
>>> Retained the tracking to understand if it is again the timing issue
>>> which is the cause in an event of a failure, however i can remove it
>>> if you think it is not necessary (OR) include an alternate solution as
>>> you may want to suggest.
>>>>
>>>> Overall I'm suspicious that the changed timeout actually fixes
>>>> anything - normally we need to add longer timeouts not shorter ones.
>>>> Does this fail on a range of machines or only specific ones? Have we
>>>> verified that the clocks/timers are behaving properly on those 
>>>> systems?
>>> Here the time out is not about waiting for threads to complete
>>> something but to "be interrupted" before being considered done, so we
>>> decreased the timeout. However we now chose to increase the number of
>>> iterations to 5000000 from 1000000(thanks to tristan for the
>>> suggestion) instead of decreasing the timeout as done earlier because
>>> the increasing iterations ensures the threads are busy for long time
>>> curtailing the need to touch the timeout.
>>>
>>>>
>>>> Thanks,
>>>> David
>>>
>>> -- 
>>> Thanks
>>> kalyan
>>> Ph: (408)-585-8040
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>
>>>>>>   Hi Martin , apologies for the delay , was trying to get help for
>>>>>> hosting
>>>>>> my webrev.  .  Please see inline text.
>>>>>>
>>>>>>
>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>>>
>>>>>> Hi Kalyan,
>>>>>>
>>>>>>   None of us can review your changes yet because you haven't given
>>>>>> us a
>>>>>> URL of your webrev.
>>>>>>
>>>>>> It is located here
>>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test
>>>>>> just keeps
>>>>>> on passing for me.  Hints appreciated.
>>>>>>
>>>>>> Bump up the timeout to 500ms and you will see a failure (i can 
>>>>>> see it
>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with 
>>>>>> JDK 1.8
>>>>>> latest any promoted build).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>
>>>>>>>     Suggested Fix:
>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that
>>>>>>>> the test
>>>>>>>> will pass even on faster machines
>>>>>>>>
>>>>>>>
>>>>>>   This doesn't look like a permanent fix - it just makes the
>>>>>> failing case
>>>>>> rarer.
>>>>>>
>>>>>> Thats true , the other way is to make the main thread wait on 
>>>>>> TIMEOUT
>>>>>> after firing the interrupts instead of other way round, but that
>>>>>> would be
>>>>>> over-optimization which probably is not desirable as well.  The 50
>>>>>> ms was
>>>>>> arrived at empirically after running several 100 times on multiple
>>>>>> configurations and did not cause failures.
>>>>>>
>>>>>> -- 
>>>>>> Thanks
>>>>>> kalyan
>>>>>> Ph: (408)-585-8040
>>>>>>
>>>>>>
>>>>>>


From roger.riggs at oracle.com  Fri Dec 20 18:20:17 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 20 Dec 2013 18:20:17 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131220182101.841EB62E55@hg.openjdk.java.net>

Changeset: 7186275e6ef1
Author:    rriggs
Date:      2013-12-20 13:06 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7186275e6ef1

8030002: Enhance deserialization using readObject
Reviewed-by: sherman, chegar, scolebourne

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/AbstractChronology.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoPeriodImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! test/java/time/tck/java/time/AbstractTCKTest.java
! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java
! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java
! test/java/time/tck/java/time/serial/TCKDurationSerialization.java
! test/java/time/tck/java/time/serial/TCKInstantSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java
! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java
! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java
! test/java/time/tck/java/time/serial/TCKYearSerialization.java
! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java
! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java
! test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java
! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java
! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java

Changeset: 39a02b18b386
Author:    rriggs
Date:      2013-12-20 13:06 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39a02b18b386

8029909: Clarify equals/hashcode behavior for java.time types
Summary: Document the behavior of equals and hashcode in java.time.chrono date types
Reviewed-by: sherman, scolebourne

! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java



From joe.darcy at oracle.com  Fri Dec 20 18:29:54 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Dec 2013 10:29:54 -0800
Subject: JDK 9 RFR of JDK-8030785: Missing "since 1.8" javadoc for
	java.lang.reflect.Method:getParameterCount
Message-ID: <52B48CA2.4010109@oracle.com>

Hello,

Please review the patch below to fix

     JDK-8030785: Missing "since 1.8" javadoc for 
java.lang.reflect.Method:getParameterCount

The Executable type was added in 8 so none of the method in Executable 
should have an @since 1.8 tag.

In the Constructor and Executable subtypes, @since 1.8 is added to the 
getParameterCount method. I didn't seen any other similar situations 
that needed to be corrected.

Thanks,

-Joe

diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
--- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 
08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 
10:26:15 2013 -0800
@@ -204,6 +204,7 @@

      /**
       * {@inheritDoc}
+     * @since 1.8
       */
      public int getParameterCount() { return parameterTypes.length; }

diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
--- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 
08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 
10:26:15 2013 -0800
@@ -240,7 +240,6 @@
       * declared or implicitly declared or neither) for the executable
       * represented by this object.
       *
-     * @since 1.8
       * @return The number of formal parameters for the executable this
       * object represents
darcy at ubuntu:~/Sun/OpenJDK/9/dev/jdk$ hg diff | more
diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
--- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 
08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 
10:26:17 2013 -0800
@@ -204,6 +204,7 @@

      /**
       * {@inheritDoc}
+     * @since 1.8
       */
      public int getParameterCount() { return parameterTypes.length; }

diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
--- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 
08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 
10:26:17 2013 -0800
@@ -240,7 +240,6 @@
       * declared or implicitly declared or neither) for the executable
       * represented by this object.
       *
-     * @since 1.8
       * @return The number of formal parameters for the executable this
       * object represents
       */
@@ -291,7 +290,6 @@
       * have unique names, or names that are legal identifiers in the
       * Java programming language (JLS 3.8).
       *
-     * @since 1.8
       * @throws MalformedParametersException if the class file contains
       * a MethodParameters attribute that is improperly formatted.
       * @return an array of {@code Parameter} objects representing all
@@ -523,7 +521,6 @@
      /**
       * {@inheritDoc}
       * @throws NullPointerException {@inheritDoc}
-     * @since 1.8
       */
      @Override
      public  T[] getAnnotationsByType(Class 
annotationClass) {
@@ -566,8 +563,6 @@
       *
       * @return an object representing the return type of the method
       * or constructor represented by this {@code Executable}
-     *
-     * @since 1.8
       */
      public abstract AnnotatedType getAnnotatedReturnType();

@@ -576,8 +571,6 @@
       * Returns an AnnotatedType object that represents the use of a 
type to
       * specify the return type of the method/constructor represented 
by this
       * Executable.
-     *
-     * @since 1.8
       */
      AnnotatedType getAnnotatedReturnType0(Type returnType) {
          return 
TypeAnnotationParser.buildAnnotatedType(getTypeAnnotationBytes0(),
@@ -607,8 +600,6 @@
       *
       * @return an object representing the receiver type of the method or
       * constructor represented by this {@code Executable}
-     *
-     * @since 1.8
       */
      public AnnotatedType getAnnotatedReceiverType() {
          if (Modifier.isStatic(this.getModifiers()))
@@ -635,8 +626,6 @@
       * @return an array of objects representing the types of the
       * formal parameters of the method or constructor represented by this
       * {@code Executable}
-     *
-     * @since 1.8
       */
      public AnnotatedType[] getAnnotatedParameterTypes() {
          return 
TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
@@ -661,8 +650,6 @@
       * @return an array of objects representing the declared
       * exceptions of the method or constructor represented by this {@code
       * Executable}
-     *
-     * @since 1.8
       */
      public AnnotatedType[] getAnnotatedExceptionTypes() {
          return 
TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Method.java
--- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
10:26:17 2013 -0800
@@ -251,7 +251,8 @@
      }

      /**
-     * {@inheritDoc}
+     * {@inheritDoc}1
+     * @since 1.8
       */
      public int getParameterCount() { return parameterTypes.length; }




From daniel.fuchs at oracle.com  Fri Dec 20 18:45:54 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Dec 2013 19:45:54 +0100
Subject: RFR: 8030850: Setting .level=FINEST for the root logger in logging
	configuration file doesn't work
Message-ID: <52B49062.7010908@oracle.com>

Hi,

Please find below a fix for

8030850: Setting .level=FINEST for the root logger in
          logging configuration file doesn't work

https://bugs.openjdk.java.net/browse/JDK-8030850

http://cr.openjdk.java.net/~dfuchs/webrev_8030850/webrev.00/

This is a regression I introduced with my fix for JDK-8026499.

The root logger sets its own level to "INFO" in its constructor.
Then later when the logger is added, it believes that its level
has already been initialized/set by the user and so skips its
initialization from the config file.
Setting the level of the root logger to INFO in the constructor
is too early.

The fix is very limited - instead of initializing the
root level to 'INFO' in the constructor, we can do it just
after having added it to the LogManager. At this time the
configuration is already read (happened a few lines above),
and thus we can set the level to its default value after
checking whether it's already been initialized.

There should be no synchronization issue since it all happens
in the same synchronization lock as before the fix - and the
logic ensures that the LogManager will not be published to other
threads until the initialization is done.

best regards,

-- daniel


From lowasser at google.com  Fri Dec 20 18:48:25 2013
From: lowasser at google.com (Louis Wasserman)
Date: Fri, 20 Dec 2013 10:48:25 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
	
Message-ID: 

@Paul Sandoz: Is there a particular reason you prefer an extra division to
the cache?


On Fri, Dec 20, 2013 at 8:54 AM, Dmitry Nadezhin
wrote:

> What is performance of Long.compareUnsigned(x, y) ?
> Does HotSpot implement it as a call of Long.compare(x + MIN_VALUE, y +
> MIN_VALUE) or as a single machine instruction ?
>
>
>
> On Fri, Dec 20, 2013 at 7:53 PM, Paul Sandoz 
> wrote:
>
> > Hi Brian,
> >
> > It would be nice to avoid the caches, on a hunch i am wondering if the
> > following will work:
> >
> >   long result = first * radix + second;
> >   if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow
> of
> > first * radix
> >     Long.compareUnsigned(result, first) < 0) {  // overflow of  first *
> > radix + second
> >
> > It should be possible to write some tests creating strings in the
> > appropriate base to select the appropriate value for first will kick off
> an
> > overflow.
> >
> > Paul.
> >
> > On Dec 19, 2013, at 9:21 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com>
> > wrote:
> >
> > > Here's a formalization of the suggested fix:
> > >
> > > http://cr.openjdk.java.net/~bpb/8030814/webrev/
> > >
> > > It works against the test case.
> > >
> > > Brian
> > >
> > > On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
> > >
> > >> Upon inspection only that indeed looks correct.
> > >>
> > >> Thanks ?
> > >>
> > >> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
> > >>
> > >>> Here's one approach that works: there is overflow iff
> > >>>
> > >>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 ||
> > (first == divideUnsigned(MAX_UNSIGNED, radix) && second >
> > remainderUnsigned(MAX_UNSIGNED, radix));
> > >>>
> > >>> Since radix <= Character.MAX_RADIX, you can precompute the divides
> and
> > remainders in a small table.
> > >>
> > >
> >
> >
>



-- 
Louis Wasserman


From mandy.chung at oracle.com  Fri Dec 20 19:33:46 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Dec 2013 11:33:46 -0800
Subject: RFR: 8030850: Setting .level=FINEST for the root logger in logging
	configuration file doesn't work
In-Reply-To: <52B49062.7010908@oracle.com>
References: <52B49062.7010908@oracle.com>
Message-ID: <52B49B9A.8090404@oracle.com>

On 12/20/2013 10:45 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for
>
> 8030850: Setting .level=FINEST for the root logger in
>          logging configuration file doesn't work
>
> https://bugs.openjdk.java.net/browse/JDK-8030850
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8030850/webrev.00/
>

Looks good.   It's unfortunate that there is no test catching this basic 
functionality (such kind of tests should exist when j.u.logging was 
added).  You have added many tests to improve the coverage for 
j.u.logging.  Do you think there is a SQE logging test catching this?   
We will find out.

Mandy


From mike.duigou at oracle.com  Fri Dec 20 20:58:18 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 20 Dec 2013 12:58:18 -0800
Subject: JDK 9 RFR of JDK-8030785: Missing "since 1.8" javadoc for
	java.lang.reflect.Method:getParameterCount
In-Reply-To: <52B48CA2.4010109@oracle.com>
References: <52B48CA2.4010109@oracle.com>
Message-ID: <4104538D-4D88-4CF6-95E0-BCAE07561ECC@oracle.com>

+1

Mike

On Dec 20 2013, at 10:29 , Joe Darcy  wrote:

> Hello,
> 
> Please review the patch below to fix
> 
>    JDK-8030785: Missing "since 1.8" javadoc for java.lang.reflect.Method:getParameterCount
> 
> The Executable type was added in 8 so none of the method in Executable should have an @since 1.8 tag.
> 
> In the Constructor and Executable subtypes, @since 1.8 is added to the getParameterCount method. I didn't seen any other similar situations that needed to be corrected.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 10:26:15 2013 -0800
> @@ -204,6 +204,7 @@
> 
>     /**
>      * {@inheritDoc}
> +     * @since 1.8
>      */
>     public int getParameterCount() { return parameterTypes.length; }
> 
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 10:26:15 2013 -0800
> @@ -240,7 +240,6 @@
>      * declared or implicitly declared or neither) for the executable
>      * represented by this object.
>      *
> -     * @since 1.8
>      * @return The number of formal parameters for the executable this
>      * object represents
> darcy at ubuntu:~/Sun/OpenJDK/9/dev/jdk$ hg diff | more
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 20 10:26:17 2013 -0800
> @@ -204,6 +204,7 @@
> 
>     /**
>      * {@inheritDoc}
> +     * @since 1.8
>      */
>     public int getParameterCount() { return parameterTypes.length; }
> 
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 20 10:26:17 2013 -0800
> @@ -240,7 +240,6 @@
>      * declared or implicitly declared or neither) for the executable
>      * represented by this object.
>      *
> -     * @since 1.8
>      * @return The number of formal parameters for the executable this
>      * object represents
>      */
> @@ -291,7 +290,6 @@
>      * have unique names, or names that are legal identifiers in the
>      * Java programming language (JLS 3.8).
>      *
> -     * @since 1.8
>      * @throws MalformedParametersException if the class file contains
>      * a MethodParameters attribute that is improperly formatted.
>      * @return an array of {@code Parameter} objects representing all
> @@ -523,7 +521,6 @@
>     /**
>      * {@inheritDoc}
>      * @throws NullPointerException {@inheritDoc}
> -     * @since 1.8
>      */
>     @Override
>     public  T[] getAnnotationsByType(Class annotationClass) {
> @@ -566,8 +563,6 @@
>      *
>      * @return an object representing the return type of the method
>      * or constructor represented by this {@code Executable}
> -     *
> -     * @since 1.8
>      */
>     public abstract AnnotatedType getAnnotatedReturnType();
> 
> @@ -576,8 +571,6 @@
>      * Returns an AnnotatedType object that represents the use of a type to
>      * specify the return type of the method/constructor represented by this
>      * Executable.
> -     *
> -     * @since 1.8
>      */
>     AnnotatedType getAnnotatedReturnType0(Type returnType) {
>         return TypeAnnotationParser.buildAnnotatedType(getTypeAnnotationBytes0(),
> @@ -607,8 +600,6 @@
>      *
>      * @return an object representing the receiver type of the method or
>      * constructor represented by this {@code Executable}
> -     *
> -     * @since 1.8
>      */
>     public AnnotatedType getAnnotatedReceiverType() {
>         if (Modifier.isStatic(this.getModifiers()))
> @@ -635,8 +626,6 @@
>      * @return an array of objects representing the types of the
>      * formal parameters of the method or constructor represented by this
>      * {@code Executable}
> -     *
> -     * @since 1.8
>      */
>     public AnnotatedType[] getAnnotatedParameterTypes() {
>         return TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
> @@ -661,8 +650,6 @@
>      * @return an array of objects representing the declared
>      * exceptions of the method or constructor represented by this {@code
>      * Executable}
> -     *
> -     * @since 1.8
>      */
>     public AnnotatedType[] getAnnotatedExceptionTypes() {
>         return TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Method.java
> --- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 10:26:17 2013 -0800
> @@ -251,7 +251,8 @@
>     }
> 
>     /**
> -     * {@inheritDoc}
> +     * {@inheritDoc}1
> +     * @since 1.8
>      */
>     public int getParameterCount() { return parameterTypes.length; }
> 
> 



From srikalyan.chandrashekar at oracle.com  Fri Dec 20 21:00:54 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan)
Date: Fri, 20 Dec 2013 13:00:54 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B3C88E.2030502@oracle.com>
References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com>
	<52B3B22C.20701@oracle.com> <52B3C88E.2030502@oracle.com>
Message-ID: <52B4B006.4030308@oracle.com>

Hi Mandy, yes I ran with JTreg to simulate the failure, i will try the 
UEH patch to see if it sheds some light and get back to you. Thanks for 
the direction :)

--
Thanks
kalyan
Ph: (408)-585-8040


On 12/19/13, 8:33 PM, Mandy Chung wrote:
> Hi Srikalyan,
>
> Maybe you can get add an uncaught handler to see if you can get
> any information.  I ran it for 1000 times but not able to duplicate
> the failure.  Did you run it with jtreg (I didn't)?
>
> Below is the patch to install a thread's uncaught handler that
> you can take and try.
>
> diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java 
> b/test/java/lang/ref/OOMEInReferenceHand
> ler.java
> --- a/test/java/lang/ref/OOMEInReferenceHandler.java
> +++ b/test/java/lang/ref/OOMEInReferenceHandler.java
> @@ -51,6 +51,14 @@
>           return first;
>       }
>
> +     static class UEH implements Thread.UncaughtExceptionHandler {
> +         public void uncaughtException(Thread t, Throwable e) {
> +             System.err.println("ERROR: " + t.getName() + " exception 
> " +
> +                 e.getMessage());
> +             e.printStackTrace();
> +         }
> +     }
> +
>       public static void main(String[] args) throws Exception {
>           // preinitialize the InterruptedException class so that the 
> reference handler
>           // does not die due to OOME when loading the class if it is 
> the first use
> @@ -77,6 +85,8 @@
>               throw new IllegalStateException("Couldn't find Reference 
> Handler thread.");
>           }
>
> +         referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
> +
>           ReferenceQueue refQueue = new ReferenceQueue<>();
>           Object referent = new Object();
>           WeakReference weakRef = new 
> WeakReference<>(referent, refQueue);
>
> On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
>> Hi David Thanks for your comments, the unguarded part(clean and 
>> enqueue) in the Reference Handler thread does not seem to create any 
>> new objects, so it is the application(the test in this case) which is 
>> adding objects to heap and causing the Reference Handler to die with 
>> OOME. I am still unsure about the side effects of the code change and 
>> agree with your thoughts(on memory exhaustion test's reliability).
>>
>> PS: hotspot dev alias removed from CC.
>>
>> -- 
>> Thanks
>> kalyan
>>
>> On 12/19/13 5:08 PM, David Holmes wrote:
>>> Hi Kalyan,
>>>
>>> This is not a hotspot issue so I'm moving this to core-libs, please 
>>> drop hotspot from any replies.
>>>
>>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>>> Hi all,  I have been working on the bug JDK-8022321
>>>>  , this is a 
>>>> sporadic
>>>> failure and the webrev is available here
>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>>>
>>>
>>> I'm really not sure what to make of this. We have a test that 
>>> triggers an out-of-memory condition but the OOME can actually turn 
>>> up in the ReferenceHandler thread causing it to terminate and the 
>>> test to fail. We previously accounted for the non-obvious 
>>> occurrences of OOME due to the Object.wait and the possible need to 
>>> load the InterruptedException class - but still the OOME can appear 
>>> where we don't want it. So finally you have just placed the whole 
>>> for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm certain 
>>> that makes the test happy, but I'm not sure it is really what we 
>>> want for the ReferenceHandler thread. If the OOME occurs while 
>>> cleaning, or enqueuing then we will fail to clean and/or enqueue but 
>>> there would be no indication that has occurred and I think that is a 
>>> bigger problem than this test failing.
>>>
>>> There may be no way to make this test 100% reliable. In fact I'd 
>>> suggest that no memory exhaustion test can be 100% reliable.
>>>
>>> David
>>>
>>>> *
>>>> **"Root Cause:Still not known"*
>>>> 2 places where there is a possibility for OOME
>>>> 1) Cleaner.clean()
>>>> 2) ReferenceQueue.enqueue()
>>>>
>>>> 1)  The cleanup code in turn has 2 places where there is potential for
>>>> throwing OOME,
>>>>      a) thunk Thread which is run from clean() method. This 
>>>> Runnable is
>>>> passed to Cleaner and appears in the following classes
>>>>          java/nio/DirectByteBuffer.java
>>>>          sun/misc/Perf.java
>>>>          sun/nio/fs/NativeBuffer.java
>>>>          sun/nio/ch/IOVecWrapper.java
>>>>          sun/misc/Cleaner/ExitOnThrow.java
>>>> However none of the above overridden implementations ever create an
>>>> object in the clean() code.
>>>>      b) new PrivilegedAction created in try catch Exception block of
>>>> clean() method but for this object to be created and to be held
>>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>>
>>>> 2) No new heap objects are created in the enqueue method nor 
>>>> anywhere in
>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>>> potential cause.
>>>>
>>>> *Experimental change to java.lang.Reference.java* :
>>>> - Put one more guard (try catch with OOME block) in the Reference
>>>> Handler Thread which may give the Reference Handler a chance to 
>>>> cleanup.
>>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>>> - Without the above change the test fails atleast 3-5 times for every
>>>> 1000 run.
>>>>
>>>> *PS*: The code change is to a very critical part of JDK and i am fully
>>>> not aware of the consequences of the change, hence seeking expert help
>>>> here. Appreciate your time and inputs towards this.
>>>>
>>
>


From mandy.chung at oracle.com  Fri Dec 20 21:21:40 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Dec 2013 13:21:40 -0800
Subject: JDK 9 RFR of JDK-8030785: Missing "since 1.8" javadoc for
	java.lang.reflect.Method:getParameterCount
In-Reply-To: <52B48CA2.4010109@oracle.com>
References: <52B48CA2.4010109@oracle.com>
Message-ID: <52B4B4E4.7020102@oracle.com>

--- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 08:59:52 2013 -0800
+++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 10:26:17 2013 -0800
@@ -251,7 +251,8 @@
      }

      /**
-     * {@inheritDoc}
+     * {@inheritDoc}1

Is this accident?  Other than this, look fine.

Mandy

On 12/20/2013 10:29 AM, Joe Darcy wrote:
> Hello,
>
> Please review the patch below to fix
>
>     JDK-8030785: Missing "since 1.8" javadoc for 
> java.lang.reflect.Method:getParameterCount
>
> The Executable type was added in 8 so none of the method in Executable 
> should have an @since 1.8 tag.
>
> In the Constructor and Executable subtypes, @since 1.8 is added to the 
> getParameterCount method. I didn't seen any other similar situations 
> that needed to be corrected.
>
> Thanks,
>
> -Joe
>
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 
> 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 
> 20 10:26:15 2013 -0800
> @@ -204,6 +204,7 @@
>
>      /**
>       * {@inheritDoc}
> +     * @since 1.8
>       */
>      public int getParameterCount() { return parameterTypes.length; }
>
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 
> 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 
> 20 10:26:15 2013 -0800
> @@ -240,7 +240,6 @@
>       * declared or implicitly declared or neither) for the executable
>       * represented by this object.
>       *
> -     * @since 1.8
>       * @return The number of formal parameters for the executable this
>       * object represents
> darcy at ubuntu:~/Sun/OpenJDK/9/dev/jdk$ hg diff | more
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Constructor.java
> --- a/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 
> 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Constructor.java    Fri Dec 
> 20 10:26:17 2013 -0800
> @@ -204,6 +204,7 @@
>
>      /**
>       * {@inheritDoc}
> +     * @since 1.8
>       */
>      public int getParameterCount() { return parameterTypes.length; }
>
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 
> 20 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Executable.java    Fri Dec 
> 20 10:26:17 2013 -0800
> @@ -240,7 +240,6 @@
>       * declared or implicitly declared or neither) for the executable
>       * represented by this object.
>       *
> -     * @since 1.8
>       * @return The number of formal parameters for the executable this
>       * object represents
>       */
> @@ -291,7 +290,6 @@
>       * have unique names, or names that are legal identifiers in the
>       * Java programming language (JLS 3.8).
>       *
> -     * @since 1.8
>       * @throws MalformedParametersException if the class file contains
>       * a MethodParameters attribute that is improperly formatted.
>       * @return an array of {@code Parameter} objects representing all
> @@ -523,7 +521,6 @@
>      /**
>       * {@inheritDoc}
>       * @throws NullPointerException {@inheritDoc}
> -     * @since 1.8
>       */
>      @Override
>      public  T[] getAnnotationsByType(Class 
> annotationClass) {
> @@ -566,8 +563,6 @@
>       *
>       * @return an object representing the return type of the method
>       * or constructor represented by this {@code Executable}
> -     *
> -     * @since 1.8
>       */
>      public abstract AnnotatedType getAnnotatedReturnType();
>
> @@ -576,8 +571,6 @@
>       * Returns an AnnotatedType object that represents the use of a 
> type to
>       * specify the return type of the method/constructor represented 
> by this
>       * Executable.
> -     *
> -     * @since 1.8
>       */
>      AnnotatedType getAnnotatedReturnType0(Type returnType) {
>          return 
> TypeAnnotationParser.buildAnnotatedType(getTypeAnnotationBytes0(),
> @@ -607,8 +600,6 @@
>       *
>       * @return an object representing the receiver type of the method or
>       * constructor represented by this {@code Executable}
> -     *
> -     * @since 1.8
>       */
>      public AnnotatedType getAnnotatedReceiverType() {
>          if (Modifier.isStatic(this.getModifiers()))
> @@ -635,8 +626,6 @@
>       * @return an array of objects representing the types of the
>       * formal parameters of the method or constructor represented by 
> this
>       * {@code Executable}
> -     *
> -     * @since 1.8
>       */
>      public AnnotatedType[] getAnnotatedParameterTypes() {
>          return 
> TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
> @@ -661,8 +650,6 @@
>       * @return an array of objects representing the declared
>       * exceptions of the method or constructor represented by this 
> {@code
>       * Executable}
> -     *
> -     * @since 1.8
>       */
>      public AnnotatedType[] getAnnotatedExceptionTypes() {
>          return 
> TypeAnnotationParser.buildAnnotatedTypes(getTypeAnnotationBytes0(),
> diff -r 33c3c4c0ebcf src/share/classes/java/lang/reflect/Method.java
> --- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
> 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
> 10:26:17 2013 -0800
> @@ -251,7 +251,8 @@
>      }
>
>      /**
> -     * {@inheritDoc}
> +     * {@inheritDoc}1
> +     * @since 1.8
>       */
>      public int getParameterCount() { return parameterTypes.length; }
>
>



From joe.darcy at oracle.com  Fri Dec 20 22:03:11 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Dec 2013 14:03:11 -0800
Subject: JDK 9 RFR of JDK-8030785: Missing "since 1.8" javadoc for
	java.lang.reflect.Method:getParameterCount
In-Reply-To: <52B4B4E4.7020102@oracle.com>
References: <52B48CA2.4010109@oracle.com> <52B4B4E4.7020102@oracle.com>
Message-ID: <52B4BE9F.5020407@oracle.com>

On 12/20/2013 01:21 PM, Mandy Chung wrote:
> --- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
> 08:59:52 2013 -0800
> +++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 
> 10:26:17 2013 -0800
> @@ -251,7 +251,8 @@
>      }
>
>      /**
> -     * {@inheritDoc}
> +     * {@inheritDoc}1
>
> Is this accident?  Other than this, look fine.

Oops; yes, that is a typo. I'll correct it before I push.

Thanks for the close reading Mandy,

-Joe



From kumar.x.srinivasan at oracle.com  Fri Dec 20 23:03:42 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 20 Dec 2013 15:03:42 -0800
Subject: RFR: jdk9: 8029997: [infra] remove Solaris ISA directories and the
	links
Message-ID: <52B4CCCE.4000009@oracle.com>

Hello,

Please review the removal of  ISA (Instruction Specific Architecture) 
directories namely sparcv9, amd64
and the symlinks in these directories,   this was provided to aid 
transition to jdk8, where solaris 32-bit was
removed, and the 32-bit binaries were replaced with 64-bit versions.

http://cr.openjdk.java.net/~ksrini/8029997/webrev.0/

Thanks
Kumar



From tim.bell at oracle.com  Fri Dec 20 23:18:02 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 20 Dec 2013 15:18:02 -0800
Subject: RFR: jdk9: 8029997: [infra] remove Solaris ISA directories and
	the links
In-Reply-To: <52B4CCCE.4000009@oracle.com>
References: <52B4CCCE.4000009@oracle.com>
Message-ID: <52B4D02A.8020205@oracle.com>

Hi Kumar:

> Please review the removal of  ISA (Instruction Specific Architecture) 
> directories namely sparcv9, amd64
> and the symlinks in these directories,   this was provided to aid 
> transition to jdk8, where solaris 32-bit was
> removed, and the 32-bit binaries were replaced with 64-bit versions.
>
> http://cr.openjdk.java.net/~ksrini/8029997/webrev.0/

Three cheers for code deletion!  Looks good to me.

Tim



From stuart.marks at oracle.com  Fri Dec 20 23:38:03 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 20 Dec 2013 15:38:03 -0800
Subject: JDK 9 RFR of JDK-8030785: Missing "since 1.8" javadoc for
	java.lang.reflect.Method:getParameterCount
In-Reply-To: <52B4BE9F.5020407@oracle.com>
References: <52B48CA2.4010109@oracle.com> <52B4B4E4.7020102@oracle.com>
	<52B4BE9F.5020407@oracle.com>
Message-ID: <52B4D4DB.7060606@oracle.com>

On 12/20/13 2:03 PM, Joe Darcy wrote:
> On 12/20/2013 01:21 PM, Mandy Chung wrote:
>> --- a/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 08:59:52
>> 2013 -0800
>> +++ b/src/share/classes/java/lang/reflect/Method.java    Fri Dec 20 10:26:17
>> 2013 -0800
>> @@ -251,7 +251,8 @@
>>      }
>>
>>      /**
>> -     * {@inheritDoc}
>> +     * {@inheritDoc}1
>>
>> Is this accident?  Other than this, look fine.
>
> Oops; yes, that is a typo. I'll correct it before I push.
>
> Thanks for the close reading Mandy,

Although Mike had said "+1" I think he really meant "-1".



From stuart.marks at oracle.com  Fri Dec 20 23:47:48 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 20 Dec 2013 15:47:48 -0800
Subject: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests
	(activation and others)
In-Reply-To: <52B3C2CA.2030200@oracle.com>
References: <147942d4-f052-4403-b374-3d3ed59e7175@default>	<529FD0A9.9020400@oracle.com>
	<52A7C98E.7000200@oracle.com> <52A8DA41.1020909@oracle.com>
	<52B1B675.8090908@oracle.com> <52B3AFAC.1080204@oracle.com>
	<52B3C2CA.2030200@oracle.com>
Message-ID: <52B4D724.1010706@oracle.com>

Hi Tristan,

Thanks for cleaning this up. I've gone ahead and pushed the revised changeset.

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eaa533e9778a

I did take the liberty of making a couple changes... first, I had to fix some 
whitespace issues (trailing whitespace on a line) that were caught by jcheck.

Second, I changed this line from ReadTimeoutTest.java:

     throw new Error("Unexpected error happen in reader:" + ie);

to be this instead:

     throw new Error("Unexpected interrupt", ie);

I had missed this in my earlier review.

The point here is to use the exception chaining mechanism, so that when the 
stack trace for the Error is printed, it includes a "caused by" segment with the 
stack trace from the original exception that had been caught. This provides 
better diagnostic information. The general rule is that any catch-and-rethrow 
should chain up the exception cause this way. The only exception (heh) to this 
rule is if including the cause would leak sensitive information to the caller. 
This situation basically never occurs in test code, though.

s'marks


On 12/19/13 8:08 PM, Tristan Yan wrote:
> Thanks Stuart
> I changed ReadTimeoutTest.java only apply CountdownLatch part. Please review.
>
> http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.02/
>
> Thank you
> Tristan
>
> On 12/20/2013 10:47 AM, Stuart Marks wrote:
>> Hi Tristan,
>>
>> Changes mostly look good.
>>
>> There is an ignored InterruptedException in both versions of 
>> UseCustomSocketFactory.java, but that was there already; it's not clear what 
>> should be done in this case anyway. This is something to keep in mind for a 
>> future cleanup. Hm, some duplicate code here as well, again something to 
>> think about for the future.
>>
>> There is a serious problem with the change to ReadTimeoutTest.java, however. 
>> The change removes the (old) line 72, which is
>>      TestIface stub = impl.export();
>> probably because there was an IDE warning that the variable "stub" is unused. 
>> This much is true, but it's essential for impl.export() to be called, because 
>> that exports the object, which creates a socket using the socket factory, 
>> which eventually results in the fac.whichPort() call below returning the port 
>> that was open. In the absence of the export() call, whichPort() returns zero 
>> which causes the test to abort immediately.
>>
>> In addition, the refactoring to use try-with-resources changes the order of 
>> execution of certain code, and it changes the scope of things handled by the 
>> finally-block.
>>
>> One purpose of the finally-block is to unexport the remote object so it makes 
>> sense to begin the try-block immediately following the export. The original 
>> code did this (well, only after a benign local variable declaration). The 
>> change moves the try-block few lines down, which means there is a larger 
>> window of time within which the finally-block won't be executed. This isn't 
>> obviously a problem, but it's a change nonetheless.
>>
>> Also, the change alters the order of opening the client socket and the 
>> "connecting to listening port" message, so the message comes after the port 
>> is opened, instead of before. Again, an apparently small change, but if 
>> there's an exception opening the port, the port number being opened won't be 
>> printed out.
>>
>> The main point of the changes to this file, however, is good, which is to 
>> replace the unsafe use of multi-thread access to a boolean array and polling 
>> of that value, with a CountDownLatch. So that part of the change should go 
>> in. The problem is the apparently innocuous code cleanups (use of 
>> try-with-resources, removal of apparently unused local variable) which cause 
>> the test to break or otherwise change its behavior.
>>
>> I could go ahead and push this changeset, omitting the changes to 
>> ReadTimeoutTest.java. Or, you could update the changeset to revert all of the 
>> changes to ReadTimeoutTest.java except for those necessary to implement the 
>> use of CountDownLatch. Either way is fine with me.
>>
>> Which would you prefer?
>>
>> s'marks
>>
>>
>> On 12/18/13 6:51 AM, Tristan Yan wrote:
>>> Hi Everyone
>>> Please review the code fix for bug JDK-7168267
>>>
>>> http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01/ 
>>> 
>>>
>>> This is a cleanup for RMI tests. trying to use real timeout to replace a 
>>> fixed number of loop.
>>> Thank you
>>>
>>> Tristan
>>>
>>>
>>> On 12/12/2013 05:33 AM, Stuart Marks wrote:
>>>> On 12/10/13 6:10 PM, Tristan Yan wrote:
>>>>> /Hi everyone
>>>>> I am working on bug JDK-7168267
>>>>>
>>>>
>>>> Correct link is
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7168267
>>>>
>>>>> Root Cause:
>>>>> - Per Stuart's comment, this is a clean up bug.
>>>>>
>>>>> Suggested Fix:
>>>>> - Will use timeout to replace loop.
>>>>
>>>> We should probably look at specific cases for this. There are places where 
>>>> the test is waiting for some external service to become ready (e.g., 
>>>> rmiregistry). There's no notification for things like this so 
>>>> wait-with-timeout cannot be used. Pretty much the only thing that can be 
>>>> done is to poll reasonably often until the service is ready, or until the 
>>>> timeout is exceeded.
>>>>
>>>>> - Also I am fixing two test's performance
>>>>> java/rmi/activation/Activatable/forceLogSnapshot - method waitAllStarted is
>>>>> using sleep to poll 50 restartedObject to be true, we can use modern
>>>>> CountDownLatch to implement blocking-time wait.
>>>>> java/rmi/activation/Activatable/checkAnnotations - We can subclass
>>>>> ByteArrayOutputStream which support notification when data was written. 
>>>>> Also use
>>>>> two thread wait output string and error string to be not null.
>>>>
>>>> These sound reasonble. Go ahead and file sub-tasks for these and then 
>>>> choose one to work on first. (I think it will get too confusing if we try 
>>>> to work on them all simultaneously.) Either post a detailed description of 
>>>> what you intend to do, or if it's simple enough, just post a webrev.
>>>>
>>>> s'marks
>>>>
>>>>>
>>>>> Please let me know if you have any comments or suggestions.
>>>>> / /
>>>>> Thank you
>>>>> Tristan
>>>>>
>>>>> On 12/05/2013 09:02 AM, Stuart Marks wrote:
>>>>> /
>>>>>> /On 12/3/13 11:05 PM, Tristan Yan wrote:
>>>>>> /
>>>>>>> /I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This 
>>>>>>> bug is
>>>>>>> asking performance improvement for RMI test. Because this would involve
>>>>>>> different RMI tests. I?d like to use this cr as an umbrella bug, create 
>>>>>>> sub-cr
>>>>>>> for different test. Then I can make progress on sub-cr. Please let me 
>>>>>>> know your
>>>>>>> opinion on this.
>>>>>>> /
>>>>>> /
>>>>>> Actually JDK-7168267 is more about various test cleanups, and JDK-8005436 is
>>>>>> more about performance. Both bugs, though, make general statements about 
>>>>>> "the
>>>>>> RMI tests" and don't have much information about specific actions that 
>>>>>> need to
>>>>>> be taken. I've added some notes to JDK-7168267 about some cleanups that 
>>>>>> could
>>>>>> be done.
>>>>>> / /
>>>>>> If there are specific actions for either of these bugs, then yes, creating
>>>>>> Sub-Tasks of these bugs and fixing them individually is the right thing 
>>>>>> to do.
>>>>>> / /
>>>>>> s'marks
>>>>>> /
>>>>> /
>>>>> /
>>>
>>
>



From stuart.marks at oracle.com  Sat Dec 21 00:01:55 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 20 Dec 2013 16:01:55 -0800
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
In-Reply-To: <52B3C7A5.7050705@oracle.com>
References: <52B29168.9070302@oracle.com> <52B3B41C.8080003@oracle.com>
	<52B3C7A5.7050705@oracle.com>
Message-ID: <52B4DA73.3070602@oracle.com>

On 12/19/13 8:29 PM, David Holmes wrote:
> If you were always one frame from the end then it is not so surprising that a
> simple change pushes you past the limit :) Try running the shell test with
> additional recursive loads and see when it fails.

David doesn't seem surprised, but I guess I still am. :-)

Tristan, do you think you could do some investigation here, regarding the shell 
script based test's stack consumption? Run the shell-based test with some 
different values for -Xss and see how low you have to set it before it generates 
a stack overflow.

>> It's also kind of strange that in the two stack traces I've seen (I
>> think I managed to capture only one in the bug report though) the
>> StackOverflowError occurs on loading exactly the 50th class. Since we're
>> observing intermittent behavior (happens sometimes but not others) the
>> stack size is apparently variable. Since it's variable I'd expect to see
>> it failing at different times, possibly the 49th or 48th recursive
>> classload, not just the 50th. And in such circumstances, do we know what
>> the default stack size is?
>
> Classloading consumes a reasonable chunk of stack so if the variance elsewhere
> is quite small it is not that surprising that the test always fails on the 50th
> class. I would not expect run-to-run stack usage variance to be high unless
> there is some random component to the test.

Hm. There should be no variance in stack usage coming from the test itself. I 
believe the test does the same thing every time.

The thing I'm concerned about is whether the Java-based test is doing something 
different from the shell-based test, because of the execution environment (jtreg 
or other). We may end up simply raising the stack limit anyway, but I still find 
it hard to believe that the shell-based test was consistently just a few frames 
shy of a stack overflow.

The failure is intermittent; we've seen it twice in JPRT (our internal 
build&test system). Possible sources of the intermittency are from the different 
machines on which the test executes. So environmental factors could be at play. 
How does the JVM determine the default stack size? Could different test runs on 
different machines be running with different stack sizes?

Another source of variance is the JIT. I believe JIT-compiled code consumes 
stack differently from interpreted code. At least, I've seen differences in 
stack usage between -Xint and -Xcomp runs, and in the absence of these options 
(which means -Xmixed, I guess) the results sometimes vary unpredictably. I guess 
this might have to do with when the JIT compiler decides to kick in.

This test does perform a bunch of iterations, so JIT compilation could be a factor.

>> I don't know if you were able to reproduce this issue. If you were, it
>> would be good to understand in more detail exactly what's going on.
>
> FWIW there was a recent change in 7u to bump up the number of stack shadow pages
> in hotspot as "suddenly" StackOverflow tests were crashing instead of triggering
> StackOverflowError. So something started using more stack in a way the caused
> there to not be enough space to process a stackoverflow properly. Finding the
> exact cause can be somewhat tedious.

This seems like a different problem. We're seeing actual StackOverflowErrors, 
not crashes. Good to look out for this, though.

s'marks


>
> Cheers,
> David
>
>> s'marks


From stuart.marks at oracle.com  Sat Dec 21 01:58:52 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 20 Dec 2013 17:58:52 -0800
Subject: RFR for JDK-8030057: speed up forceLogSnapshot and
	checkAnnotations
In-Reply-To: <52B1C11E.4040601@oracle.com>
References: <52B1C11E.4040601@oracle.com>
Message-ID: <52B4F5DC.8080908@oracle.com>

Hi Tristan,

First of all, these are two completely separate changes. They're sort-of related 
in that they involve replacing sleep() loops and polling with different 
constructs, but other than that, they're completely independent. As you'll see 
from my review comments, there are different issues going on with each as well. 
It might be worthwhile to consider splitting these into separate subtasks, one 
for each of these changes, so that if one of the changes converges more quickly 
(seems like) it can go in independently of the others.

CheckAnnotations

This is a pretty complicated test to begin with, and the changes make it even 
more complicated. It adds two threads, a single Lock, two conditions, and stream 
subclasses that notify these conditions. It's not clear to me why the low-level 
constructs from j.u.concurrent.locks are necessary. At first glance the idea of 
having a notifying specialization of a ByteArrayOutputStream is reasonable. I'd 
expect the lock and condition to be inside the stream object, though, not 
external to it. In addition, the condition being notified is simply "something 
has been written". We don't actually know that all the output from the 
subprocess has been read. The old version waited around for a while and assumed 
that it had collected it all. This of course is racy; but having the notifying 
stream is still racy, if it happens that the output is written in multiple chunks.

Note that if we want to get subprocess output as it arrives, there are two 
threads hidden inside of RMI's TestLibrary.JavaVM class that collect stdout and 
stderr from the subprocess. By default they simply write to whatever stream they 
are given. An alternative approach would be to plumb an interface to these 
threads and have the output sent directly to the test as it comes in. (I think 
one of the other RMI tests does this, though it does it in a particularly clumsy 
way that I wouldn't recommend emulating.)

But stepping back a bit, the original test is over-complicated to begin with, 
and I'm reluctant to add all these additional mechanisms in this proposed 
change, because they add more complexity, and also because I can't quite 
convince myself that they're correct or that they even solve the problem that 
exists in the original test.

The original test probably needs to be reconceived entirely. The idea is to 
activate several objects in several different activation groups (which are child 
JVMs of the RMID process), and to make sure that the output from each is 
"annotated" with a prefix that indicates which activation group it came from. It 
seems to me that a much simpler way to approach the problem is to activate 
several objects and have them each emit a unique bit of output. Then, shut 
everything down, collect ALL the output, and check to make sure that each 
object's unique output is on a line that was annotated properly. This completely 
avoids threads, locks, conditions, timing loops, and race conditions.

If you think this alternative approach would be an effective way to proceed, I'd 
be happy to help you out with it.

ForceLogSnapshot

This is another fairly complicated test that is partially helped by the addition 
of CountDownLatches. Basically, it registers 50 activatable+restartable objects 
and 50 activatable (but not restartable) objects with the activation system. 
Then it restarts the activation system. The test wants to ensure that the 
restartable objects are all restarted, but that *none* of the non-restartable 
objects are restarted.

In the first case, having a CountDownLatch that starts at 50 and awaits for them 
all to be restarted makes perfect sense. The await() call has a timeout to make 
sure we don't wait excessively long for all 50 to be restarted, but the 
CountDownLatch allows the test to continue immediately as soon as all 50 have 
been restarted. For this case, it's also not necessary to have a retry loop in 
waitAllStarted(). We just wait once until the latch is decremented to zero, or 
until we time out. It might make sense to raise the timeout here, since there's 
a lot of activity; 30 or even 60 seconds might be reasonable. In the normal case 
the restarts will all occur quickly, so we'll only wait the full timeout if 
there's a failure.

In the second case, we expect zero objects to be restarted, so having a 
CountDownLatch starting at 50 doesn't make sense. There is no notion of having 
the test proceed immediately as soon as "all" of some events have happened. One 
choice here is to wait around for a while and count how many of the 
non-restartable objects actually get restarted. An AtomicInteger would be 
sufficient for that. An alternative might be to have a CountDownLatch 
initialized to 1. If any one of the non-restartable objects is restarted, we 
know immediately that the test has failed and we can report that. We might not 
care if additional non-restartable objects are restarted after we've observed 
the first one having been restarted erroneously. (Then again, we might.) But if 
others do, decrementing the CountDownLatch further after it's reached zero does 
nothing, so that's OK.

Unfortunately, the successful case needs the test to wait around for a while, 
because it's trying to verify a negative, i.e., that no non-restartable objects 
were actually restarted. I'm not sure whether that's better done with a 
CountDownLatch(1) plus timeout, or a sleep call followed by a check of an 
AtomicInteger. I think the latter is a bit easier understand, since the 
"latching" behavior in this case is the error, not the normal condition.

Finally, these changes are intended to improve performance. It would be good to 
see some measurements to ensure that the performance has actually improved. The 
CountDownLatch stuff is an improvement over the original array of booleans, and 
it potentially makes the code cleaner, but I think its potential for performance 
improvement is limited.

On my system the test run takes about 80 seconds. (It actually does all of the 
above twice: once after shutting down rmid, and once after causing the 
activation group JVMs to exit ("crash").) The howManyRestarted() loop for 
restartable objects sleeps for ten seconds before polling the number of objects 
restarted. On average it might wait five seconds too long; given the two test 
scenarios, that's a savings of ten seconds. The howManyRestarted() loop for the 
objects that *aren't* supposed to be restarted waits for 20 seconds 
unconditionally. With two scenarios run, that's 40 seconds right there, fully 
half of the time of the test run. (Where does the other half of the time go?) 
That time is unavoidable waiting around to make sure the wrong thing (restarting 
a non-restartable object) doesn't happen.

I think some of the CountDownLatch stuff will improve the test code, but let's 
not make any assumptions about performance.

s'marks


On 12/18/13 7:37 AM, Tristan Yan wrote:
> Hi Everyone
>
> Please help to review the code change for bug JDK-8030057.
>
>
> http://cr.openjdk.java.net/~tyan/JDK-8030057/webrev.00/
> 
> Description:
>
> Performance improvement for two RMI tests
>
> java/rmi/activation/Activatable/forceLogSnapshot
>
> method waitAllStarted is using recursive sleep to poll 50 restartedObject to be
> true, we can use modern CountDownLatch to implement blocking-time wait.
>
> Also suggest shorten waiting time to 5 seconds.
>
> java/rmi/activation/Activatable/checkAnnotations
>
> We can subclass ByteArrayOutputStream which support notification when data was
> written. Also use two thread wait output string and error string to be not null
>
> Thank you
> Tristan


From martinrb at google.com  Sat Dec 21 03:07:28 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Dec 2013 19:07:28 -0800
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test
	failed with 'Completed != 2'
In-Reply-To: <52B48A3B.8040002@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
	<52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com>
	<52B48A3B.8040002@oracle.com>
Message-ID: 

Sorry for all the troubles with this test.  The latest change seems OK to
me, although I continue to be disturbed that I've never been able to
reproduce any failure even with aggressive fiddling with the test
parameters.  Also, I'm still hoping that Doug will comment.


On Fri, Dec 20, 2013 at 10:19 AM, srikalyan <
srikalyan.chandrashekar at oracle.com> wrote:

> Hi David, i retained only the changes to ITERS, ProbleMList.txt and
> upstream changes by Doug Lea(as pointed by Martin), could you please review
> the new change available here http://cr.openjdk.java.net/~
> srikchan/Regression/6772009-CancelledLockLoop-webrev/ .
>
>
> --
> Thanks
> kalyan
> Ph: (408)-585-8040
>
>
> On 12/19/13, 8:10 PM, David Holmes wrote:
>
>> Sorry Kalyan but I don't see the need for all the incidental changes if
>> the primary change is to just increase the iterations. I also don't see why
>> you need to do anything for BrokenBarrierException as it is not expected to
>> happen and the test should just fail if it does.
>>
>> David
>>
>> On 10/12/2013 6:15 AM, srikalyan wrote:
>>
>>> Hi David/Martin a gentle reminder for review.
>>>
>>> --
>>> Thanks
>>> kalyan
>>> Ph: (408)-585-8040
>>>
>>>
>>> On 12/2/13, 11:21 AM, srikalyan wrote:
>>>
>>>> Hi David, Thanks for the review, the new webrev is hosted at
>>>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/
>>>> . Please see inline text.
>>>>
>>>> On 11/20/13, 6:35 PM, David Holmes wrote:
>>>>
>>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>>>>
>>>>>> I again tried and failed to reproduce a failure.  Even if I go whole
>>>>>> hog
>>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test
>>>>>> continues to
>>>>>> PASS.  Is it just me?!
>>>>>>
>>>>>
>>>>> I think you are going the wrong way Martin - you want the timeout to
>>>>> be smaller than the time it takes to execute ITERS.
>>>>>
>>>>>  I don't think there's any reason to make result long.  It's not even
>>>>>> used
>>>>>> except to inhibit hotspot optimizations.
>>>>>>
>>>>>> +        private volatile long result = 17;//Can get int overflow,so
>>>>>> using long
>>>>>>
>>>>>
>>>>> Further the subsequent use of += is incorrect as it is not an atomic
>>>>> operation. Even if we don't care about the value, it looks bad.
>>>>>
>>>> Made the necessary changes for atomic update.
>>>>
>>>>>
>>>>> I'm not sure result must be updated if we get a
>>>>> BrokenBarrierException either. Probably harmless, but necessary?
>>>>>
>>>> I retained it in the fix for completeness in updating the numbers,
>>>> please let me know if you still think otherwise.
>>>>
>>>>>
>>>>>  need to fix spelling and spacing below.
>>>>>>
>>>>>> +                barrier.await();//If a BrokeBarrierException happens
>>>>>> here(due to
>>>>>>
>>>>>
>>>>> There are a number of style issues with spacing around comments.
>>>>>
>>>> Fixed the spelling error and styling issues.
>>>>
>>>>>
>>>>> And I don't think this change is sufficient to claim co-author status
>>>>> with Doug either ;-)
>>>>>
>>>> Removed the claim :)
>>>>
>>>>>
>>>>> The additional tracing may be useful but seems stylistically
>>>>> different from the rest of the code.
>>>>>
>>>> Retained the tracking to understand if it is again the timing issue
>>>> which is the cause in an event of a failure, however i can remove it
>>>> if you think it is not necessary (OR) include an alternate solution as
>>>> you may want to suggest.
>>>>
>>>>>
>>>>> Overall I'm suspicious that the changed timeout actually fixes
>>>>> anything - normally we need to add longer timeouts not shorter ones.
>>>>> Does this fail on a range of machines or only specific ones? Have we
>>>>> verified that the clocks/timers are behaving properly on those systems?
>>>>>
>>>> Here the time out is not about waiting for threads to complete
>>>> something but to "be interrupted" before being considered done, so we
>>>> decreased the timeout. However we now chose to increase the number of
>>>> iterations to 5000000 from 1000000(thanks to tristan for the
>>>> suggestion) instead of decreasing the timeout as done earlier because
>>>> the increasing iterations ensures the threads are busy for long time
>>>> curtailing the need to touch the timeout.
>>>>
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>
>>>> --
>>>> Thanks
>>>> kalyan
>>>> Ph: (408)-585-8040
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>
>>>>>>    Hi Martin , apologies for the delay , was trying to get help for
>>>>>>> hosting
>>>>>>> my webrev.  .  Please see inline text.
>>>>>>>
>>>>>>>
>>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>>>>
>>>>>>> Hi Kalyan,
>>>>>>>
>>>>>>>   None of us can review your changes yet because you haven't given
>>>>>>> us a
>>>>>>> URL of your webrev.
>>>>>>>
>>>>>>> It is located here
>>>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_
>>>>>>> CancelledLockLoops/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test
>>>>>>> just keeps
>>>>>>> on passing for me.  Hints appreciated.
>>>>>>>
>>>>>>> Bump up the timeout to 500ms and you will see a failure (i can see it
>>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK
>>>>>>> 1.8
>>>>>>> latest any promoted build).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>>
>>>>>>>      Suggested Fix:
>>>>>>>>
>>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that
>>>>>>>>> the test
>>>>>>>>> will pass even on faster machines
>>>>>>>>>
>>>>>>>>>
>>>>>>>>    This doesn't look like a permanent fix - it just makes the
>>>>>>> failing case
>>>>>>> rarer.
>>>>>>>
>>>>>>> Thats true , the other way is to make the main thread wait on TIMEOUT
>>>>>>> after firing the interrupts instead of other way round, but that
>>>>>>> would be
>>>>>>> over-optimization which probably is not desirable as well.  The 50
>>>>>>> ms was
>>>>>>> arrived at empirically after running several 100 times on multiple
>>>>>>> configurations and did not cause failures.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks
>>>>>>> kalyan
>>>>>>> Ph: (408)-585-8040
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>


From david.holmes at oracle.com  Sat Dec 21 06:28:56 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 21 Dec 2013 16:28:56 +1000
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
	test failed with 'Completed != 2'
In-Reply-To: <52B48A3B.8040002@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
	<52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com>
	<52B48A3B.8040002@oracle.com>
Message-ID: <52B53528.9050704@oracle.com>

On 21/12/2013 4:19 AM, srikalyan wrote:
> Hi David, i retained only the changes to ITERS, ProbleMList.txt and
> upstream changes by Doug Lea(as pointed by Martin), could you please
> review the new change available here
> http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/
> .

Ok.

Thanks,
David

> --
> Thanks
> kalyan
> Ph: (408)-585-8040
>
>
> On 12/19/13, 8:10 PM, David Holmes wrote:
>> Sorry Kalyan but I don't see the need for all the incidental changes
>> if the primary change is to just increase the iterations. I also don't
>> see why you need to do anything for BrokenBarrierException as it is
>> not expected to happen and the test should just fail if it does.
>>
>> David
>>
>> On 10/12/2013 6:15 AM, srikalyan wrote:
>>> Hi David/Martin a gentle reminder for review.
>>>
>>> --
>>> Thanks
>>> kalyan
>>> Ph: (408)-585-8040
>>>
>>>
>>> On 12/2/13, 11:21 AM, srikalyan wrote:
>>>> Hi David, Thanks for the review, the new webrev is hosted at
>>>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/
>>>> . Please see inline text.
>>>>
>>>> On 11/20/13, 6:35 PM, David Holmes wrote:
>>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>>>>> I again tried and failed to reproduce a failure.  Even if I go whole
>>>>>> hog
>>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test
>>>>>> continues to
>>>>>> PASS.  Is it just me?!
>>>>>
>>>>> I think you are going the wrong way Martin - you want the timeout to
>>>>> be smaller than the time it takes to execute ITERS.
>>>>>
>>>>>> I don't think there's any reason to make result long.  It's not even
>>>>>> used
>>>>>> except to inhibit hotspot optimizations.
>>>>>>
>>>>>> +        private volatile long result = 17;//Can get int overflow,so
>>>>>> using long
>>>>>
>>>>> Further the subsequent use of += is incorrect as it is not an atomic
>>>>> operation. Even if we don't care about the value, it looks bad.
>>>> Made the necessary changes for atomic update.
>>>>>
>>>>> I'm not sure result must be updated if we get a
>>>>> BrokenBarrierException either. Probably harmless, but necessary?
>>>> I retained it in the fix for completeness in updating the numbers,
>>>> please let me know if you still think otherwise.
>>>>>
>>>>>> need to fix spelling and spacing below.
>>>>>>
>>>>>> +                barrier.await();//If a BrokeBarrierException happens
>>>>>> here(due to
>>>>>
>>>>> There are a number of style issues with spacing around comments.
>>>> Fixed the spelling error and styling issues.
>>>>>
>>>>> And I don't think this change is sufficient to claim co-author status
>>>>> with Doug either ;-)
>>>> Removed the claim :)
>>>>>
>>>>> The additional tracing may be useful but seems stylistically
>>>>> different from the rest of the code.
>>>> Retained the tracking to understand if it is again the timing issue
>>>> which is the cause in an event of a failure, however i can remove it
>>>> if you think it is not necessary (OR) include an alternate solution as
>>>> you may want to suggest.
>>>>>
>>>>> Overall I'm suspicious that the changed timeout actually fixes
>>>>> anything - normally we need to add longer timeouts not shorter ones.
>>>>> Does this fail on a range of machines or only specific ones? Have we
>>>>> verified that the clocks/timers are behaving properly on those
>>>>> systems?
>>>> Here the time out is not about waiting for threads to complete
>>>> something but to "be interrupted" before being considered done, so we
>>>> decreased the timeout. However we now chose to increase the number of
>>>> iterations to 5000000 from 1000000(thanks to tristan for the
>>>> suggestion) instead of decreasing the timeout as done earlier because
>>>> the increasing iterations ensures the threads are busy for long time
>>>> curtailing the need to touch the timeout.
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>>> --
>>>> Thanks
>>>> kalyan
>>>> Ph: (408)-585-8040
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>
>>>>>>>   Hi Martin , apologies for the delay , was trying to get help for
>>>>>>> hosting
>>>>>>> my webrev.  .  Please see inline text.
>>>>>>>
>>>>>>>
>>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>>>>
>>>>>>> Hi Kalyan,
>>>>>>>
>>>>>>>   None of us can review your changes yet because you haven't given
>>>>>>> us a
>>>>>>> URL of your webrev.
>>>>>>>
>>>>>>> It is located here
>>>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test
>>>>>>> just keeps
>>>>>>> on passing for me.  Hints appreciated.
>>>>>>>
>>>>>>> Bump up the timeout to 500ms and you will see a failure (i can
>>>>>>> see it
>>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with
>>>>>>> JDK 1.8
>>>>>>> latest any promoted build).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>>
>>>>>>>>     Suggested Fix:
>>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that
>>>>>>>>> the test
>>>>>>>>> will pass even on faster machines
>>>>>>>>>
>>>>>>>>
>>>>>>>   This doesn't look like a permanent fix - it just makes the
>>>>>>> failing case
>>>>>>> rarer.
>>>>>>>
>>>>>>> Thats true , the other way is to make the main thread wait on
>>>>>>> TIMEOUT
>>>>>>> after firing the interrupts instead of other way round, but that
>>>>>>> would be
>>>>>>> over-optimization which probably is not desirable as well.  The 50
>>>>>>> ms was
>>>>>>> arrived at empirically after running several 100 times on multiple
>>>>>>> configurations and did not cause failures.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks
>>>>>>> kalyan
>>>>>>> Ph: (408)-585-8040
>>>>>>>
>>>>>>>
>>>>>>>


From Alan.Bateman at oracle.com  Sat Dec 21 08:08:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Dec 2013 08:08:15 +0000
Subject: RFR: jdk9: 8029997: [infra] remove Solaris ISA directories and
	the links
In-Reply-To: <52B4CCCE.4000009@oracle.com>
References: <52B4CCCE.4000009@oracle.com>
Message-ID: <52B54C6F.7090301@oracle.com>

On 20/12/2013 23:03, Kumar Srinivasan wrote:
> Hello,
>
> Please review the removal of  ISA (Instruction Specific Architecture) 
> directories namely sparcv9, amd64
> and the symlinks in these directories,   this was provided to aid 
> transition to jdk8, where solaris 32-bit was
> removed, and the 32-bit binaries were replaced with 64-bit versions.
>
> http://cr.openjdk.java.net/~ksrini/8029997/webrev.0/
This looks good to me too (I assumed there would be several tests that 
needed adjustment, it seems not).

-Alan.


From dmitry.nadezhin at gmail.com  Sat Dec 21 10:04:58 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 21 Dec 2013 14:04:58 +0400
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
	
	
Message-ID: 

I can weaken the question:
Is there a reason to prefer extra int multiplication to the cache ?

long result = first * radix + second;
final int GUARD_BIT = 7;
int guard = radix * (int) (first >>> (Long.SIZE - GUARD_BIT));
if (guard >= (1 << GUARD_BIT) - Character.MAX_RADIX
     && (guard >= (1 << GUARD_BIT) || result >= 0)) {
  . . .


On Fri, Dec 20, 2013 at 10:48 PM, Louis Wasserman wrote:

> @Paul Sandoz: Is there a particular reason you prefer an extra division to
> the cache?
>
>
> On Fri, Dec 20, 2013 at 8:54 AM, Dmitry Nadezhin <
> dmitry.nadezhin at gmail.com> wrote:
>
>> What is performance of Long.compareUnsigned(x, y) ?
>> Does HotSpot implement it as a call of Long.compare(x + MIN_VALUE, y +
>> MIN_VALUE) or as a single machine instruction ?
>>
>>
>>
>> On Fri, Dec 20, 2013 at 7:53 PM, Paul Sandoz 
>> wrote:
>>
>> > Hi Brian,
>> >
>> > It would be nice to avoid the caches, on a hunch i am wondering if the
>> > following will work:
>> >
>> >   long result = first * radix + second;
>> >   if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow
>> of
>> > first * radix
>> >     Long.compareUnsigned(result, first) < 0) {  // overflow of  first *
>> > radix + second
>> >
>> > It should be possible to write some tests creating strings in the
>> > appropriate base to select the appropriate value for first will kick
>> off an
>> > overflow.
>> >
>> > Paul.
>> >
>> > On Dec 19, 2013, at 9:21 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com>
>> > wrote:
>> >
>> > > Here's a formalization of the suggested fix:
>> > >
>> > > http://cr.openjdk.java.net/~bpb/8030814/webrev/
>> > >
>> > > It works against the test case.
>> > >
>> > > Brian
>> > >
>> > > On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
>> > >
>> > >> Upon inspection only that indeed looks correct.
>> > >>
>> > >> Thanks ?
>> > >>
>> > >> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
>> > >>
>> > >>> Here's one approach that works: there is overflow iff
>> > >>>
>> > >>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 ||
>> > (first == divideUnsigned(MAX_UNSIGNED, radix) && second >
>> > remainderUnsigned(MAX_UNSIGNED, radix));
>> > >>>
>> > >>> Since radix <= Character.MAX_RADIX, you can precompute the divides
>> and
>> > remainders in a small table.
>> > >>
>> > >
>> >
>> >
>>
>
>
>
> --
> Louis Wasserman
>


From peter.levart at gmail.com  Sat Dec 21 16:50:11 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 21 Dec 2013 17:50:11 +0100
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <4D6B1813-EEB6-4388-9FC7-2E0BDF004222@oracle.com>
References: <52B3568B.5050905@oracle.com>
	<52B398A2.8030307@oracle.com>	<52B3B22C.20701@oracle.com>
	<52B3C88E.2030502@oracle.com>
	<4D6B1813-EEB6-4388-9FC7-2E0BDF004222@oracle.com>
Message-ID: <52B5C6C3.7000208@gmail.com>

Hi David,

Is it possible to get the test output when it fails? It can fail in two 
different ways. I can't look at the bug (not authorized)...


On 12/20/2013 10:54 AM, Chris Hegarty wrote:
> On 20 Dec 2013, at 04:33, Mandy Chung  wrote:
>
>> Hi Srikalyan,
>>
>> Maybe you can get add an uncaught handler to see if you can get
>> any information.
> +1. With this, at least the next time we see this failure we should have a better idea where the OOM is coming from.
>
> -Chris.

We can try, but I think the VM already prints the stack-trace of the 
exception by default and as far as I remember, OOME thrown by VM is 
preallocated and does not contain a stack trace. So I suspect we'll see 
nothing more with the suggested UEH.

Is it possible to include in test, a modified version of Reference class 
that would be prepended to boot-classpath? For example, containing the 
following ReferenceHandler:


     private static class ReferenceHandler extends Thread {

         ReferenceHandler(ThreadGroup g, String name) {
             super(g, name);
         }

         private volatile int state;

         @Override
         public String toString() {
             return super.toString() + "[state=" + state + "]";
         }

         public void run() {
             for (;;) {
                 state = 1;
                 Reference r;
                 state = 2;
                 synchronized (lock) {
                     state = 3;
                     if (pending != null) {
                         state = 4;
                         r = pending;
                         state = 5;
                         pending = r.discovered;
                         state = 6;
                         r.discovered = null;
                         state = 7;
                     } else {
                         state = 8;
                         // The waiting on the lock may cause an OOME 
because it may try to allocate
                         // exception objects, so also catch OOME here 
to avoid silent exit of the
                         // reference handler thread.
                         //
                         // Explicitly define the order of the two 
exceptions we catch here
                         // when waiting for the lock.
                         //
                         // We do not want to try to potentially load 
the InterruptedException class
                         // (which would be done if this was its first 
use, and InterruptedException
                         // were checked first) in this situation.
                         //
                         // This may lead to the VM not ever trying to 
load the InterruptedException
                         // class again.
                         try {
                             state = 9;
                             try {
                                 state = 10;
                                 lock.wait();
                                 state = 11;
                             } catch (InterruptedException x) { state = 
12; }
                             state = 13;
                         } catch (OutOfMemoryError x) { state = 14; }
                         state = 15;
                         continue;
                     }
                     state = 16;
                 }
                 state = 17;

                 // Fast path for cleaners
                 if (r instanceof Cleaner) {
                     state = 18;
                     ((Cleaner)r).clean();
                     state = 19;
                     continue;
                 }
                 state = 20;

                 ReferenceQueue q = (ReferenceQueue) r.queue;
                 state = 21;
                 if (q != ReferenceQueue.NULL) q.enqueue(r);
                 state = 22;
             }
         }
     }




...then just include the toString of referenceHandlerThread instance as 
part of the exception message at the end of the test:

...
...
          // wait at most 10 seconds for success or failure
          for (int i = 0; i < 20; i++) {
              if (refQueue.poll() != null) {
                  // Reference Handler thread still working -> success
                  return;
              }
              System.gc();
              Thread.sleep(500L); // wait a little to allow GC to do 
it's work before allocating objects
              if (!referenceHandlerThread.isAlive()) {
                  // Reference Handler thread died -> failure
                  throw new Exception("Reference Handler thread died. 
referenceHandlerThread: " + referenceHandlerThread);
              }
          }

          // no sure answer after 10 seconds
          throw new IllegalStateException("Reference Handler thread 
stuck. weakRef.get(): " + weakRef.get() +
                                           ", referenceHandlerThread: " 
+ referenceHandlerThread);
      }


This might be safer than using UEH since at the time the 
UEH.uncaughtException() is called, the heap might still be full which 
would prevent printing the message. The test makes sure the allocated 
waste gets GCed before reporting the outcome...

I suspect that with the above, the failure message would print 8 <= 
state <= 14 ...

When I was trying out the OOMEInReferenceHandler test, I experimented 
with various arrangements of exception handlers in ReferenceHandler and 
encountered one that in one ocassion allowed OOME to sneak-through or 
re-induced it, but I haven't been able to explain why and also could not 
reproduce it afterwards.  So it might still be that something 
interesting is happening between state 8 and 14.

Regards, Peter

>> I ran it for 1000 times but not able to duplicate
>> the failure.  Did you run it with jtreg (I didn't)?
>>
>> Below is the patch to install a thread's uncaught handler that
>> you can take and try.
>>
>> diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java b/test/java/lang/ref/OOMEInReferenceHand
>> ler.java
>> --- a/test/java/lang/ref/OOMEInReferenceHandler.java
>> +++ b/test/java/lang/ref/OOMEInReferenceHandler.java
>> @@ -51,6 +51,14 @@
>>           return first;
>>       }
>>
>> +     static class UEH implements Thread.UncaughtExceptionHandler {
>> +         public void uncaughtException(Thread t, Throwable e) {
>> +             System.err.println("ERROR: " + t.getName() + " exception " +
>> +                 e.getMessage());
>> +             e.printStackTrace();
>> +         }
>> +     }
>> +
>>       public static void main(String[] args) throws Exception {
>>           // preinitialize the InterruptedException class so that the reference handler
>>           // does not die due to OOME when loading the class if it is the first use
>> @@ -77,6 +85,8 @@
>>               throw new IllegalStateException("Couldn't find Reference Handler thread.");
>>           }
>>
>> +         referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
>> +
>>           ReferenceQueue refQueue = new ReferenceQueue<>();
>>           Object referent = new Object();
>>           WeakReference weakRef = new WeakReference<>(referent, refQueue);
>>
>> On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
>>> Hi David Thanks for your comments, the unguarded part(clean and enqueue) in the Reference Handler thread does not seem to create any new objects, so it is the application(the test in this case) which is adding objects to heap and causing the Reference Handler to die with OOME. I am still unsure about the side effects of the code change and agree with your thoughts(on memory exhaustion test's reliability).
>>>
>>> PS: hotspot dev alias removed from CC.
>>>
>>> -- 
>>> Thanks
>>> kalyan
>>>
>>> On 12/19/13 5:08 PM, David Holmes wrote:
>>>> Hi Kalyan,
>>>>
>>>> This is not a hotspot issue so I'm moving this to core-libs, please drop hotspot from any replies.
>>>>
>>>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>>>> Hi all,  I have been working on the bug JDK-8022321
>>>>>  , this is a sporadic
>>>>> failure and the webrev is available here
>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/
>>>> I'm really not sure what to make of this. We have a test that triggers an out-of-memory condition but the OOME can actually turn up in the ReferenceHandler thread causing it to terminate and the test to fail. We previously accounted for the non-obvious occurrences of OOME due to the Object.wait and the possible need to load the InterruptedException class - but still the OOME can appear where we don't want it. So finally you have just placed the whole for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm certain that makes the test happy, but I'm not sure it is really what we want for the ReferenceHandler thread. If the OOME occurs while cleaning, or enqueuing then we will fail to clean and/or enqueue but there would be no indication that has occurred and I think that is a bigger problem than this test failing.
>>>>
>>>> There may be no way to make this test 100% reliable. In fact I'd suggest that no memory exhaustion test can be 100% reliable.
>>>>
>>>> David
>>>>
>>>>> *
>>>>> **"Root Cause:Still not known"*
>>>>> 2 places where there is a possibility for OOME
>>>>> 1) Cleaner.clean()
>>>>> 2) ReferenceQueue.enqueue()
>>>>>
>>>>> 1)  The cleanup code in turn has 2 places where there is potential for
>>>>> throwing OOME,
>>>>>      a) thunk Thread which is run from clean() method. This Runnable is
>>>>> passed to Cleaner and appears in the following classes
>>>>>          java/nio/DirectByteBuffer.java
>>>>>          sun/misc/Perf.java
>>>>>          sun/nio/fs/NativeBuffer.java
>>>>>          sun/nio/ch/IOVecWrapper.java
>>>>>          sun/misc/Cleaner/ExitOnThrow.java
>>>>> However none of the above overridden implementations ever create an
>>>>> object in the clean() code.
>>>>>      b) new PrivilegedAction created in try catch Exception block of
>>>>> clean() method but for this object to be created and to be held
>>>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>>>
>>>>> 2) No new heap objects are created in the enqueue method nor anywhere in
>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>>>> potential cause.
>>>>>
>>>>> *Experimental change to java.lang.Reference.java* :
>>>>> - Put one more guard (try catch with OOME block) in the Reference
>>>>> Handler Thread which may give the Reference Handler a chance to cleanup.
>>>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>>>> - Without the above change the test fails atleast 3-5 times for every
>>>>> 1000 run.
>>>>>
>>>>> *PS*: The code change is to a very critical part of JDK and i am fully
>>>>> not aware of the consequences of the change, hence seeking expert help
>>>>> here. Appreciate your time and inputs towards this.
>>>>>



From peter.levart at gmail.com  Sun Dec 22 13:23:20 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 22 Dec 2013 14:23:20 +0100
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B3675B.1030403@oracle.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
	<52B227E2.4000809@oracle.com> <52B315A2.7010403@gmail.com>
	<52B3675B.1030403@oracle.com>
Message-ID: <52B6E7C8.1040109@gmail.com>

Hi Mandy,

On 12/19/2013 10:38 PM, Mandy Chung wrote:
> On 12/19/13 7:49 AM, Peter Levart wrote:
>> Hi Mandy, Daniel,
>>
>> I didn't like the package-protected getters either. So here's another 
>> variant that replaces Handler.configure() method with a 
>> package-protected constructor which is chained from JDK subclasses:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/ 
>>
>>
>
> Looks good.  Thanks for making the change and the new test.  It'd be 
> good to close the handlers by the test. The test is running in othervm 
> mode and the Cleaner thread will close the handler when VM exits and 
> the test is fine as it is.

Well, not really. The Cleaner only closes Handlers that are attached to 
Loggers but the test just instantiates Handlers and doesn't add them to 
any Loggers. It's harmless as it is, othervm will exit nevertheless and 
resources will be freed...

I tried closing Handlers at the end of test, but that requires "control" 
LoggingPermission and we don't want to run the test with "control" 
permission since we want to check that instantiating Handlers 
(SocketHandler too) doesn't require "control" permission.

>
> Digress:  Just notice that the closeable handler classes are not 
> AutoCloseable (they don't implement Closeable either).  The close() 
> method don't throw IOException but instead throws SecurityException an 
> unchecked exception.  Otherwise, we could use try-with-resources.
>
>> I filed another bug that is fixed by this patch:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8030801
>>
>> And I created a test (see webrev.07) that almost passes when run 
>> against unchanged JDK 8 (the failure is just at the end when calling 
>> new SocketHandler(host, port) - access denied 
>> ("java.util.logging.LoggingPermission" "control")). If I comment-out 
>> the System.setSecurityManager() from the test, it passes with 
>> unchanged code. This is to verify the test itself. When run against 
>> the patched JDK 8, it passes even when SecurityManager is active - 
>> this verifies two things:
>> - the behaviour of patched code is analogous to unpatched code as far 
>> as defaults and configured handler properties is concerned and it 
>> conforms to javadoc
>> - the patched code does not require any new permissions - it actually 
>> requires less, because it fixes bug 8030801.
>>
>
> Yes I agree this is a bug that should get fixed.
>
>> All java/util/logging jtreg tests pass with patched code. I hope that 
>> "localhost" is a resolvable name on all environments and that new 
>> ServerSocket(0) creates a server socket bound at least to the IP 
>> address that "localhost" resolves to. Is this reasonable to assume?
>
> "localhost" should be fine and there are other tests depending on it 
> be resolvable.

So should anything else be done before pushing this to jdk9/dev ?


Regards, Peter

>
> thanks
> Mandy



From joe.darcy at oracle.com  Sun Dec 22 14:54:22 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 22 Dec 2013 06:54:22 -0800
Subject: JDK 8 and 9 RFR of 8030212: Several api.java.util.stream tests got
	"NaN" value instead of "Infinity" or "-Infinity"
Message-ID: <52B6FD1E.7080509@oracle.com>

Hello,

Testing (eventually) revealed that changing the streams floating point 
sum and average algorithms to use compensated summation (JDK-8006572 
DoubleStream.sum() & DoubleSummaryStats implementations that reduce 
numerical errors), changed the behavior of the code on streams with 
infinite values: NaN was returned instead of infinity:

     8030212: Several api.java.util.stream tests got "NaN" value instead 
of "Infinity" or "-Infinity"

The specification doesn't explicitly state how non-finite values in 
streams should be handled (and it should be updated to do so in 9, 
JDK-8030942 Explicitly state floating-point summation requirements on 
non-finite inputs), but it isn't unreasonable to assume that a properly 
signed infinity should result.

Towards that end, I've prepared a webrev that uses an additional simple 
sum to distinguish a spurious NaN sum in the result:

     http://cr.openjdk.java.net/~darcy/8030212.1/

This may not be the optimal way to track this situation, additional 
logic in the compensated summation code is possible, but if needed the 
implementation can be refined in JDK 9 and the 8 updates.

Thanks,

-Joe


From aleksej.efimov at oracle.com  Sun Dec 22 18:14:52 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Sun, 22 Dec 2013 22:14:52 +0400
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B42C62.9090603@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com>
Message-ID: <52B72C1C.8000703@oracle.com>

Hi,
The new version of patch for TimeZone display names update is available. 
Previous webrev contains incorrect naming for Acre timezone generic name 
(ACT[] array) across all non-root locales. The name was corrected and 
test TimeZoneNames_*.properties files were modified accordingly.
The new webrev: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 


-Aleksej

On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
> Masayoshi,
> Thank you for the detailed review and your comments. I tried to 
> address all of them. The responses are below. The new webrev can be 
> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
> 
>
> Michael,
> As Masayoshi mentioned, we have a list of inconsistent translations in 
> translation files. I suggest two approaches to resolve it: 1. Log 
> different bug with all problems in translation files. 2. Wait for the 
> next resource file translation update to address these problems.
>
> -Aleksej
>
> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>> Hi,
>>>
>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>> fix includes:
>>
>> Common to all modified files:
>> - All year ranges in the copyright header should be modified 
>> accordingly.
>
> Fixed.
>
>>
>>>  - The translation of time zone generic names were added to all 
>>> locales.
>>
>> I haven't fully reviewed translations, especially all \uxxxx strings. 
>> But I noticed the following.
>>
>> Common to all TimeZoneNames_*.java:
>> - The same generic abbreviation is used for the long name in MET. I 
>> thought this was fixed in the root properties...
>
> No, the "MET" is used in root properties both for generic long and 
> short names. I will update these names when new translation update 
> will be available.
>
>> - Some generic names don't match the style of their standard and/or 
>> daylight time names.
>
> The same as previous. This is a first large update for generic names 
> and latest translations. All inconsistency in translations will be 
> fixed during next translation update.
>
>>
>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>> - Some generic names use "Normalzeit". Is that OK?
>
> It's not good. But the resolution is same as previous two.
>
>>
>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>> - "Chuuk Time" isn't translated.
>
> I think it will be translated in next translations update.
>
>>
>>>  - Time Zone names were updated according to the latest translations.
>>>  - Added tz names regression test 
>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>> names across all locales. This test compares short/long 
>>> standard/daylight/generic names with translations stored in 
>>> .properties files.
>>
>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>
>> - lines 33, 34: unused imports?
>
> Removed
>
>> - line 75: Should it be detected as an error?
>
> Agree, now the test will fail if there is some incorrect entries in 
> the test .properties files.
>
>> - line 108: IOException should be used as a cause. (OK to assume "not 
>> found"?)
>
> The IOException cause is added. Currently, the test will stop with 
> RuntimeException, because the test file is not found.
>
>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>> Locale.ROOT. Regression tests are run in different locales.
>
> Thank you for catching this one. Fixed.
>
>>
>>>  - Tests updates to address current changes ( 
>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>
>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>> removed.
>
> Removed
>
>>
>>>
>>> The following fix was tested with JPRT build and the 'jdk_util' test 
>>> set succeeded (new test is included in this test set).
>>
>> Have you executed all date-time related regression tests (including 
>> java.time and java.text)?
>
> Yes, I have executed the following set of tests via JTREG:
> test/sun/util/calendar test/java/util/Calendar 
> test/sun/util/resources/TimeZone test/sun/util/calendar 
> test/closed/java/util/TimeZone test/java/util/TimeZone
>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
> All tests gave "PASS" results.
> Please, let me know if you think that some other tests should be 
> executed.
>
>
>>
>> Thanks,
>> Masayoshi
>>
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>
>>
>



From brian.goetz at oracle.com  Sun Dec 22 19:40:05 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 22 Dec 2013 14:40:05 -0500
Subject: RFR of lang level code migration patches
In-Reply-To: <99C02A6A-2C6A-4876-B19A-FB5BF154A8C6@oracle.com>
References: 	<52B3228B.6040303@oracle.com>
	<99C02A6A-2C6A-4876-B19A-FB5BF154A8C6@oracle.com>
Message-ID: <52B74015.6010009@oracle.com>

> I can take on java.lang.

When your IDE tells you about "unnecessary boxing" in Integer.valueOf(), 
or "inner class can be converted to lambda" in LambdaMetafacory, don't 
believe it :)




From forax at univ-mlv.fr  Sun Dec 22 20:00:34 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 Dec 2013 21:00:34 +0100
Subject: RFR of lang level code migration patches
In-Reply-To: <52B74015.6010009@oracle.com>
References: 	<52B3228B.6040303@oracle.com>	<99C02A6A-2C6A-4876-B19A-FB5BF154A8C6@oracle.com>
	<52B74015.6010009@oracle.com>
Message-ID: <52B744E2.6060500@univ-mlv.fr>

On 12/22/2013 08:40 PM, Brian Goetz wrote:
>> I can take on java.lang.
>
> When your IDE tells you about "unnecessary boxing" in 
> Integer.valueOf(), or "inner class can be converted to lambda" in 
> LambdaMetafacory, don't believe it :)
>
>

I've found that bug recently, test with your favorite IDE:
   Runnable runnable = new Runnable() {
     public strictfp void run() {  // works with synchronized too
        ...
     }
   };

It will trigger a refactoring to:
   Runnable runnable = () -> { ... };  // where is my strictfp ?

Lambda Refactoring is a bit too young to be trusted :)

R?mi




From mandy.chung at oracle.com  Mon Dec 23 04:50:49 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 22 Dec 2013 20:50:49 -0800
Subject: Theoretical data race on java.util.logging.Handler.sealed
In-Reply-To: <52B6E7C8.1040109@gmail.com>
References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>,
	<529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>,
	<52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>,
	<52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com>
	
	<52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com>
	<52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com>
	<52B227E2.4000809@oracle.com> <52B315A2.7010403@gmail.com>
	<52B3675B.1030403@oracle.com> <52B6E7C8.1040109@gmail.com>
Message-ID: <52B7C129.2040606@oracle.com>


On 12/22/2013 5:23 AM, Peter Levart wrote:
> Hi Mandy,
>
> On 12/19/2013 10:38 PM, Mandy Chung wrote:
>> On 12/19/13 7:49 AM, Peter Levart wrote:
>>> Hi Mandy, Daniel,
>>>
>>> I didn't like the package-protected getters either. So here's 
>>> another variant that replaces Handler.configure() method with a 
>>> package-protected constructor which is chained from JDK subclasses:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/ 
>>>
>>>
>>
>> Looks good.  Thanks for making the change and the new test. It'd be 
>> good to close the handlers by the test. The test is running in 
>> othervm mode and the Cleaner thread will close the handler when VM 
>> exits and the test is fine as it is.
>
> Well, not really. The Cleaner only closes Handlers that are attached 
> to Loggers but the test just instantiates Handlers and doesn't add 
> them to any Loggers. It's harmless as it is, othervm will exit 
> nevertheless and resources will be freed...
>
> I tried closing Handlers at the end of test, but that requires 
> "control" LoggingPermission and we don't want to run the test with 
> "control" permission since we want to check that instantiating 
> Handlers (SocketHandler too) doesn't require "control" permission.

Thanks and the test is fine as it is.

>
> So should anything else be done before pushing this to jdk9/dev ?

Fix looks good and have a regression test.  It's good to go and push to 
jdk9/dev.    No other approval needed.

thanks
Mandy


From kumar.x.srinivasan at oracle.com  Mon Dec 23 15:16:07 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Dec 2013 07:16:07 -0800
Subject: RFR: jdk9: 8029997: [infra] remove Solaris ISA directories and
	the links
In-Reply-To: <52B54C6F.7090301@oracle.com>
References: <52B4CCCE.4000009@oracle.com> <52B54C6F.7090301@oracle.com>
Message-ID: <52B853B7.2050104@oracle.com>


On 12/21/2013 12:08 AM, Alan Bateman wrote:
> On 20/12/2013 23:03, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the removal of  ISA (Instruction Specific Architecture) 
>> directories namely sparcv9, amd64
>> and the symlinks in these directories,   this was provided to aid 
>> transition to jdk8, where solaris 32-bit was
>> removed, and the 32-bit binaries were replaced with 64-bit versions.
>>
>> http://cr.openjdk.java.net/~ksrini/8029997/webrev.0/
> This looks good to me too (I assumed there would be several tests that 
> needed adjustment, it seems not).


There were :),  I  nailed those when I removed 32-bit  in jdk8.

Thanks Tim and Alan.

Kumar

>
> -Alan.



From volker.simonis at gmail.com  Mon Dec 23 15:48:29 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 23 Dec 2013 16:48:29 +0100
Subject: Why do we need LinkOption.NOFOLLOW_LINKS on the target file in
	CopyMoveHelper.copyToForeignTarget?
Message-ID: 

Hi,

while running the jdk/jtreg tests for our ppc-aix-port I found a
problem for the demo/zipfs/basic.sh test on AIX:

Exception in thread "main" java.io.IOException: NOFOLLOW_LINKS is not
supported on this platform
    at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:773)
    at sun.nio.fs.UnixFileAttributeViews$Basic.setTimes(UnixFileAttributeViews.java:74)
    at java.nio.file.CopyMoveHelper.copyToForeignTarget(CopyMoveHelper.java:135)
    at java.nio.file.CopyMoveHelper.moveToForeignTarget(CopyMoveHelper.java:157)
    at java.nio.file.Files.move(Files.java:1395)
    at ZipFSTester.test1(ZipFSTester.java:141)
    at ZipFSTester.main(ZipFSTester.java:50)

The test calls java.nio.file.Files.move() without any CopyOptions.
Files.move() in turn calls
java.nio.file.CopyMoveHelper.moveToForeignTarget() which adds the two
CopyOptions LinkOption.NOFOLLOW_LINKS and
StandardCopyOption.COPY_ATTRIBUTES before calling
CopyMoveHelper.copyToForeignTarget().

CopyMoveHelper.copyToForeignTarget() finally checks that the source
file is no symbolic link and performs the copy operation. In a last
step it also copies the file attributes of the source file to the
target file. For this operation it first calls
Files.getFileAttributeView(target, BasicFileAttributeView.class,
linkOptions) before the new attributes are set with
sun.nio.fs.UnixFileAttributeViews$Basic.setTimes(). But operation will
always fail on system like AIX which do not support NOFOLLOW_LINKS (or
more exactly the O_NOFOLLOW flag to the open system call). See the
stack trace above.

However, I don't think that we need to set the
LinkOption.NOFOLLOW_LINKS option when calling
Files.getFileAttributeView() on the target file, because the target
file can not be a symbolic link anyway for two reasons: first of all,
copyToForeignTarget() already checks that the source file is no
symbolic link and it deletes 'target' it that should exist before.

So from my point of view it would be safe to change
CopyMoveHelper.copyToForeignTarget() as follows to make it work an
systems which don't support NOFOLLOW_LINKS:

--- a/src/share/classes/java/nio/file/CopyMoveHelper.java       Fri
Dec 20 17:52:39 2013 +0100
+++ b/src/share/classes/java/nio/file/CopyMoveHelper.java       Mon
Dec 23 16:33:43 2013 +0100
@@ -130,7 +130,7 @@
         // copy basic attributes to target
         if (opts.copyAttributes) {
             BasicFileAttributeView view =
-                Files.getFileAttributeView(target,
BasicFileAttributeView.class, linkOptions);
+                Files.getFileAttributeView(target,
BasicFileAttributeView.class);
             try {
                 view.setTimes(attrs.lastModifiedTime(),
                               attrs.lastAccessTime(),


What do you think, did I miss something? If nobody objects, I'll put
this small change in the next AIX bug fix collection.

Thank you and best regards,
Volker


From sean.coffey at oracle.com  Mon Dec 23 17:04:55 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Mon, 23 Dec 2013 17:04:55 +0000
Subject: RFR: 8029231: Update copyright years for files in corba repository
	for 2013
Message-ID: <52B86D37.2080508@oracle.com>

Some simple copyright year updates which should have been done during 
the year when these corba files were touched. I hope to push to JDK 8 
and then import the patch into JDK 9.

https://bugs.openjdk.java.net/browse/JDK-8029231
http://cr.openjdk.java.net/~coffeys/webrev.8029231/webrev/

regards,
Sean.


From huizhe.wang at oracle.com  Mon Dec 23 17:56:49 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 23 Dec 2013 09:56:49 -0800
Subject: RFR: 8029236: Update copyright year to match last edit in jdk8 jaxp
	repository for 2013
Message-ID: <52B87961.9090903@oracle.com>

Update copyright date on JAXP files in jdk8 repository edited in 2013. 
This patch will be applied to JDK8 and 9 repositories.

https://bugs.openjdk.java.net/browse/JDK-8029236
http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/

Thanks,
Joe


From lance.andersen at oracle.com  Mon Dec 23 18:10:50 2013
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Mon, 23 Dec 2013 13:10:50 -0500
Subject: RFR: 8029236: Update copyright year to match last edit in jdk8
	jaxp repository for 2013
In-Reply-To: <52B87961.9090903@oracle.com>
References: <52B87961.9090903@oracle.com>
Message-ID: 

Looks ok assuming they were all modified 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

On Dec 23, 2013, at 12:56 PM, huizhe wang  wrote:

> Update copyright date on JAXP files in jdk8 repository edited in 2013. This patch will be applied to JDK8 and 9 repositories.
> 
> https://bugs.openjdk.java.net/browse/JDK-8029236
> http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/
> 
> Thanks,
> Joe


From huizhe.wang at oracle.com  Mon Dec 23 18:18:45 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 23 Dec 2013 10:18:45 -0800
Subject: RFR: 8029236: Update copyright year to match last edit in jdk8
	jaxp repository for 2013
In-Reply-To: 
References: <52B87961.9090903@oracle.com>
	
Message-ID: <52B87E85.9010202@oracle.com>

Thanks Lance!  The patch were SQE-generated based on files changed in 2013.

Joe

On 12/23/2013 10:10 AM, Lance @ Oracle wrote:
> Looks ok assuming they were all modified
>
>
> Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037 
> 
> Oracle Java Engineering
> 1 Network Drive 
> Burlington, MA 01803 
> Lance.Andersen at oracle.com 
> Sent from my iPad
>
> On Dec 23, 2013, at 12:56 PM, huizhe wang  > wrote:
>
>> Update copyright date on JAXP files in jdk8 repository edited in 
>> 2013. This patch will be applied to JDK8 and 9 repositories.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8029236
>> http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/ 
>> 
>>
>> Thanks,
>> Joe



From mandy.chung at oracle.com  Mon Dec 23 18:30:43 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Dec 2013 10:30:43 -0800
Subject: RFR: 8029231: Update copyright years for files in corba repository
	for 2013
In-Reply-To: <52B86D37.2080508@oracle.com>
References: <52B86D37.2080508@oracle.com>
Message-ID: <52B88153.6030009@oracle.com>

The patch looks good.

Mandy

On 12/23/13 9:04 AM, Se?n Coffey wrote:
> Some simple copyright year updates which should have been done during 
> the year when these corba files were touched. I hope to push to JDK 8 
> and then import the patch into JDK 9.
>
> https://bugs.openjdk.java.net/browse/JDK-8029231
> http://cr.openjdk.java.net/~coffeys/webrev.8029231/webrev/
>
> regards,
> Sean.



From mandy.chung at oracle.com  Mon Dec 23 18:31:44 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Dec 2013 10:31:44 -0800
Subject: RFR: 8029236: Update copyright year to match last edit in jdk8
	jaxp repository for 2013
In-Reply-To: <52B87961.9090903@oracle.com>
References: <52B87961.9090903@oracle.com>
Message-ID: <52B88190.3000803@oracle.com>

The copyright date update looks fine.

Mandy

On 12/23/13 9:56 AM, huizhe wang wrote:
> Update copyright date on JAXP files in jdk8 repository edited in 2013. 
> This patch will be applied to JDK8 and 9 repositories.
>
> https://bugs.openjdk.java.net/browse/JDK-8029236
> http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/
>
> Thanks,
> Joe



From sean.coffey at oracle.com  Mon Dec 23 18:45:20 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Mon, 23 Dec 2013 18:45:20 +0000
Subject: hg: jdk8/tl/corba: 8029231: Update copyright years for files in corba
	repository for 2013
Message-ID: <20131223184522.03CE262EB5@hg.openjdk.java.net>

Changeset: 5ca1b4c282b8
Author:    ssides
Date:      2013-12-23 18:42 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/5ca1b4c282b8

8029231: Update copyright years for files in corba repository for 2013
Reviewed-by: mchung, coffeys

! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java
! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java
! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java
! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp
! src/share/classes/javax/rmi/CORBA/Stub.java
! src/share/classes/javax/rmi/CORBA/Util.java
! src/share/classes/javax/rmi/PortableRemoteObject.java
! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java



From srikalyan.chandrashekar at oracle.com  Mon Dec 23 19:17:43 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Mon, 23 Dec 2013 11:17:43 -0800
Subject: RFR for JDK-6772009 Intermittent test failure:
	java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
	test failed with 'Completed != 2'
In-Reply-To: <52B53528.9050704@oracle.com>
References: <528B016A.3080408@oracle.com>
	
	<528C20FA.9090303@oracle.com>
	
	<528D12F4.2070300@oracle.com>
	
	<528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com>
	<52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com>
	<52B48A3B.8040002@oracle.com> <52B53528.9050704@oracle.com>
Message-ID: <52B88C57.9070105@oracle.com>

Hi David/Martin, could any one of you sponsor this change for me?

---
Thanks
kalyan

On 12/20/2013 10:28 PM, David Holmes wrote:
> On 21/12/2013 4:19 AM, srikalyan wrote:
>> Hi David, i retained only the changes to ITERS, ProbleMList.txt and
>> upstream changes by Doug Lea(as pointed by Martin), could you please
>> review the new change available here
>> http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/ 
>>
>> .
>
> Ok.
>
> Thanks,
> David
>
>> -- 
>> Thanks
>> kalyan
>> Ph: (408)-585-8040
>>
>>
>> On 12/19/13, 8:10 PM, David Holmes wrote:
>>> Sorry Kalyan but I don't see the need for all the incidental changes
>>> if the primary change is to just increase the iterations. I also don't
>>> see why you need to do anything for BrokenBarrierException as it is
>>> not expected to happen and the test should just fail if it does.
>>>
>>> David
>>>
>>> On 10/12/2013 6:15 AM, srikalyan wrote:
>>>> Hi David/Martin a gentle reminder for review.
>>>>
>>>> -- 
>>>> Thanks
>>>> kalyan
>>>> Ph: (408)-585-8040
>>>>
>>>>
>>>> On 12/2/13, 11:21 AM, srikalyan wrote:
>>>>> Hi David, Thanks for the review, the new webrev is hosted at
>>>>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ 
>>>>>
>>>>> . Please see inline text.
>>>>>
>>>>> On 11/20/13, 6:35 PM, David Holmes wrote:
>>>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote:
>>>>>>> I again tried and failed to reproduce a failure.  Even if I go 
>>>>>>> whole
>>>>>>> hog
>>>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test
>>>>>>> continues to
>>>>>>> PASS.  Is it just me?!
>>>>>>
>>>>>> I think you are going the wrong way Martin - you want the timeout to
>>>>>> be smaller than the time it takes to execute ITERS.
>>>>>>
>>>>>>> I don't think there's any reason to make result long.  It's not 
>>>>>>> even
>>>>>>> used
>>>>>>> except to inhibit hotspot optimizations.
>>>>>>>
>>>>>>> +        private volatile long result = 17;//Can get int 
>>>>>>> overflow,so
>>>>>>> using long
>>>>>>
>>>>>> Further the subsequent use of += is incorrect as it is not an atomic
>>>>>> operation. Even if we don't care about the value, it looks bad.
>>>>> Made the necessary changes for atomic update.
>>>>>>
>>>>>> I'm not sure result must be updated if we get a
>>>>>> BrokenBarrierException either. Probably harmless, but necessary?
>>>>> I retained it in the fix for completeness in updating the numbers,
>>>>> please let me know if you still think otherwise.
>>>>>>
>>>>>>> need to fix spelling and spacing below.
>>>>>>>
>>>>>>> +                barrier.await();//If a BrokeBarrierException 
>>>>>>> happens
>>>>>>> here(due to
>>>>>>
>>>>>> There are a number of style issues with spacing around comments.
>>>>> Fixed the spelling error and styling issues.
>>>>>>
>>>>>> And I don't think this change is sufficient to claim co-author 
>>>>>> status
>>>>>> with Doug either ;-)
>>>>> Removed the claim :)
>>>>>>
>>>>>> The additional tracing may be useful but seems stylistically
>>>>>> different from the rest of the code.
>>>>> Retained the tracking to understand if it is again the timing issue
>>>>> which is the cause in an event of a failure, however i can remove it
>>>>> if you think it is not necessary (OR) include an alternate 
>>>>> solution as
>>>>> you may want to suggest.
>>>>>>
>>>>>> Overall I'm suspicious that the changed timeout actually fixes
>>>>>> anything - normally we need to add longer timeouts not shorter ones.
>>>>>> Does this fail on a range of machines or only specific ones? Have we
>>>>>> verified that the clocks/timers are behaving properly on those
>>>>>> systems?
>>>>> Here the time out is not about waiting for threads to complete
>>>>> something but to "be interrupted" before being considered done, so we
>>>>> decreased the timeout. However we now chose to increase the number of
>>>>> iterations to 5000000 from 1000000(thanks to tristan for the
>>>>> suggestion) instead of decreasing the timeout as done earlier because
>>>>> the increasing iterations ensures the threads are busy for long time
>>>>> curtailing the need to touch the timeout.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>
>>>>> -- 
>>>>> Thanks
>>>>> kalyan
>>>>> Ph: (408)-585-8040
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan <
>>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>>
>>>>>>>>   Hi Martin , apologies for the delay , was trying to get help for
>>>>>>>> hosting
>>>>>>>> my webrev.  .  Please see inline text.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote:
>>>>>>>>
>>>>>>>> Hi Kalyan,
>>>>>>>>
>>>>>>>>   None of us can review your changes yet because you haven't given
>>>>>>>> us a
>>>>>>>> URL of your webrev.
>>>>>>>>
>>>>>>>> It is located here
>>>>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   I've tried to make the jsr166 copy of CancelledLockLoops fail by
>>>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test
>>>>>>>> just keeps
>>>>>>>> on passing for me.  Hints appreciated.
>>>>>>>>
>>>>>>>> Bump up the timeout to 500ms and you will see a failure (i can
>>>>>>>> see it
>>>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with
>>>>>>>> JDK 1.8
>>>>>>>> latest any promoted build).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar <
>>>>>>>> srikalyan.chandrashekar at oracle.com> wrote:
>>>>>>>>
>>>>>>>>>     Suggested Fix:
>>>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that
>>>>>>>>>> the test
>>>>>>>>>> will pass even on faster machines
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>   This doesn't look like a permanent fix - it just makes the
>>>>>>>> failing case
>>>>>>>> rarer.
>>>>>>>>
>>>>>>>> Thats true , the other way is to make the main thread wait on
>>>>>>>> TIMEOUT
>>>>>>>> after firing the interrupts instead of other way round, but that
>>>>>>>> would be
>>>>>>>> over-optimization which probably is not desirable as well.  The 50
>>>>>>>> ms was
>>>>>>>> arrived at empirically after running several 100 times on multiple
>>>>>>>> configurations and did not cause failures.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Thanks
>>>>>>>> kalyan
>>>>>>>> Ph: (408)-585-8040
>>>>>>>>
>>>>>>>>
>>>>>>>>



From huizhe.wang at oracle.com  Mon Dec 23 19:27:39 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Mon, 23 Dec 2013 19:27:39 +0000
Subject: hg: jdk8/tl/jaxp: 8029236: Update copyright year to match last edit
	in jdk8 jaxp repository for 2013
Message-ID: <20131223192747.200D362EB7@hg.openjdk.java.net>

Changeset: 9a3986b21be4
Author:    joehw
Date:      2013-12-23 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9a3986b21be4

8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Reviewed-by: lancea, mchung

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java
! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java
! src/com/sun/org/apache/xerces/internal/impl/Constants.java
! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java
! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java
! src/com/sun/xml/internal/stream/Entity.java
! src/com/sun/xml/internal/stream/StaxXMLInputSource.java
! src/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/com/sun/xml/internal/stream/writers/WriterUtility.java
! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java
! src/javax/xml/XMLConstants.java
! src/javax/xml/parsers/SAXParser.java
! src/javax/xml/validation/Validator.java
! src/javax/xml/xpath/XPathException.java
! src/javax/xml/xpath/XPathFactory.java
! src/org/xml/sax/helpers/NewInstance.java
! src/org/xml/sax/helpers/ParserAdapter.java
! src/org/xml/sax/helpers/ParserFactory.java
! src/org/xml/sax/helpers/SecuritySupport.java
! src/org/xml/sax/helpers/XMLReaderFactory.java



From tbuktu at hotmail.com  Mon Dec 23 19:37:53 2013
From: tbuktu at hotmail.com (Tim Buktu)
Date: Mon, 23 Dec 2013 20:37:53 +0100
Subject: Update on 8014320
Message-ID: 

Hello,

I've been quiet because real life needed my attention.
Obviously, the Schoenhage-Strassen and Barrett algorithms are not going
to make it into JDK8. I hope that is not a problem for anyone. We
shouldn't use the word "problem" anyway but rather think of it as an
opportunity :-) for more refinement and testing.

Improvements I have planned are:
 * Compact storage of DFT vectors. At the moment, they are stored as
numbers modulo 2^2^(n+1) when (2^2^n)+1 would suffice. This will save
memory and may speed up the DFT and IDFT steps.
 * Use Bailey's algorithm recursively if it improves cache locality and
doesn't add too much complexity to the code.
 * Maybe add a multiplyParallel() method, now that dft() and idft() use
Bailey's algorithm which should make them easy to parallelize.
 * See if dft() and idft() can be made faster on 64-bit CPUs by using
long[][] arrays instead of int[][].

As always, comments are welcome.
Merry Chris... I mean, Holidays and a happy new year to everyone!

Tim


From brian.burkhalter at oracle.com  Mon Dec 23 19:53:56 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 23 Dec 2013 11:53:56 -0800
Subject: Update on 8014320
In-Reply-To: 
References: 
Message-ID: <970CC281-CFD3-4A1D-AA1E-F78E97EA38F5@oracle.com>

Hello Tim,

On Dec 23, 2013, at 11:37 AM, Tim Buktu wrote:

> I've been quiet because real life needed my attention.

Strange how that works. ;-0

> Obviously, the Schoenhage-Strassen and Barrett algorithms are not going
> to make it into JDK8. I hope that is not a problem for anyone.

Correct. Sorry about that. There simply was not enough time.

> We
> shouldn't use the word "problem" anyway but rather think of it as an
> opportunity :-) for more refinement and testing.
> 
> Improvements I have planned are:
> * Compact storage of DFT vectors. At the moment, they are stored as
> numbers modulo 2^2^(n+1) when (2^2^n)+1 would suffice. This will save
> memory and may speed up the DFT and IDFT steps.
> * Use Bailey's algorithm recursively if it improves cache locality and
> doesn't add too much complexity to the code.
> * Maybe add a multiplyParallel() method, now that dft() and idft() use
> Bailey's algorithm which should make them easy to parallelize.
> * See if dft() and idft() can be made faster on 64-bit CPUs by using
> long[][] arrays instead of int[][].

As I've not yet studied the implementation as it stands I cannot really comment with authority, but that all sounds reasonable.

> As always, comments are welcome.
> Merry Chris... I mean, Holidays and a happy new year to everyone!

Thanks and likewise!

Brian

From sean.mullan at oracle.com  Mon Dec 23 20:24:38 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 23 Dec 2013 20:24:38 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20131223202512.3AF6162EBB@hg.openjdk.java.net>

Changeset: aef6c726810e
Author:    mullan
Date:      2013-12-23 14:03 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aef6c726810e

8030813: Signed applet fails to load when CRLs are stored in an LDAP directory
Summary: Skip JNDI application resource lookup to avoid recursive JAR validation
Reviewed-by: vinnie, herrick

! src/share/classes/com/sun/naming/internal/ResourceManager.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java

Changeset: f3c714eeef6c
Author:    mullan
Date:      2013-12-23 14:05 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c714eeef6c

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java



From srikalyan.chandrashekar at oracle.com  Mon Dec 23 22:02:02 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Mon, 23 Dec 2013 14:02:02 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B4B006.4030308@oracle.com>
References: <52B3568B.5050905@oracle.com>
	<52B398A2.8030307@oracle.com>	<52B3B22C.20701@oracle.com>
	<52B3C88E.2030502@oracle.com> <52B4B006.4030308@oracle.com>
Message-ID: <52B8B2DA.7090105@oracle.com>

Hi Mandy, after some trials i could simulate the failure again (now with 
UEH in place), however the UEH now cannot print enough details as it 
also tries to allocate memory, when it does Thread.getName()(it 
internally creates a String object), printStackTrace() also creates new 
WrappedPrintStream object. See the following trace

Exception: java.lang.OutOfMemoryError thrown from the 
UncaughtExceptionHandler in thread "Reference Handler"
ERROR: java.lang.Exception: Reference Handler thread died.
         at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
         at java.lang.reflect.Method.invoke(Method.java:483)
         at 
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
         at java.lang.Thread.run(Thread.java:744)


Meanwhile i am trying looking around to actually print something useful 
without allocating any new memory.

---
Thanks
kalyan

On 12/20/2013 01:00 PM, srikalyan wrote:
> Hi Mandy, yes I ran with JTreg to simulate the failure, i will try the 
> UEH patch to see if it sheds some light and get back to you. Thanks 
> for the direction :)
>
> -- 
> Thanks
> kalyan
> Ph: (408)-585-8040
>
>
> On 12/19/13, 8:33 PM, Mandy Chung wrote:
>> Hi Srikalyan,
>>
>> Maybe you can get add an uncaught handler to see if you can get
>> any information.  I ran it for 1000 times but not able to duplicate
>> the failure.  Did you run it with jtreg (I didn't)?
>>
>> Below is the patch to install a thread's uncaught handler that
>> you can take and try.
>>
>> diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java 
>> b/test/java/lang/ref/OOMEInReferenceHand
>> ler.java
>> --- a/test/java/lang/ref/OOMEInReferenceHandler.java
>> +++ b/test/java/lang/ref/OOMEInReferenceHandler.java
>> @@ -51,6 +51,14 @@
>>           return first;
>>       }
>>
>> +     static class UEH implements Thread.UncaughtExceptionHandler {
>> +         public void uncaughtException(Thread t, Throwable e) {
>> +             System.err.println("ERROR: " + t.getName() + " 
>> exception " +
>> +                 e.getMessage());
>> +             e.printStackTrace();
>> +         }
>> +     }
>> +
>>       public static void main(String[] args) throws Exception {
>>           // preinitialize the InterruptedException class so that the 
>> reference handler
>>           // does not die due to OOME when loading the class if it is 
>> the first use
>> @@ -77,6 +85,8 @@
>>               throw new IllegalStateException("Couldn't find 
>> Reference Handler thread.");
>>           }
>>
>> +         referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
>> +
>>           ReferenceQueue refQueue = new ReferenceQueue<>();
>>           Object referent = new Object();
>>           WeakReference weakRef = new 
>> WeakReference<>(referent, refQueue);
>>
>> On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
>>> Hi David Thanks for your comments, the unguarded part(clean and 
>>> enqueue) in the Reference Handler thread does not seem to create any 
>>> new objects, so it is the application(the test in this case) which 
>>> is adding objects to heap and causing the Reference Handler to die 
>>> with OOME. I am still unsure about the side effects of the code 
>>> change and agree with your thoughts(on memory exhaustion test's 
>>> reliability).
>>>
>>> PS: hotspot dev alias removed from CC.
>>>
>>> -- 
>>> Thanks
>>> kalyan
>>>
>>> On 12/19/13 5:08 PM, David Holmes wrote:
>>>> Hi Kalyan,
>>>>
>>>> This is not a hotspot issue so I'm moving this to core-libs, please 
>>>> drop hotspot from any replies.
>>>>
>>>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>>>> Hi all,  I have been working on the bug JDK-8022321
>>>>>  , this is a 
>>>>> sporadic
>>>>> failure and the webrev is available here
>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>>>>
>>>>
>>>> I'm really not sure what to make of this. We have a test that 
>>>> triggers an out-of-memory condition but the OOME can actually turn 
>>>> up in the ReferenceHandler thread causing it to terminate and the 
>>>> test to fail. We previously accounted for the non-obvious 
>>>> occurrences of OOME due to the Object.wait and the possible need to 
>>>> load the InterruptedException class - but still the OOME can appear 
>>>> where we don't want it. So finally you have just placed the whole 
>>>> for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm 
>>>> certain that makes the test happy, but I'm not sure it is really 
>>>> what we want for the ReferenceHandler thread. If the OOME occurs 
>>>> while cleaning, or enqueuing then we will fail to clean and/or 
>>>> enqueue but there would be no indication that has occurred and I 
>>>> think that is a bigger problem than this test failing.
>>>>
>>>> There may be no way to make this test 100% reliable. In fact I'd 
>>>> suggest that no memory exhaustion test can be 100% reliable.
>>>>
>>>> David
>>>>
>>>>> *
>>>>> **"Root Cause:Still not known"*
>>>>> 2 places where there is a possibility for OOME
>>>>> 1) Cleaner.clean()
>>>>> 2) ReferenceQueue.enqueue()
>>>>>
>>>>> 1)  The cleanup code in turn has 2 places where there is potential 
>>>>> for
>>>>> throwing OOME,
>>>>>      a) thunk Thread which is run from clean() method. This 
>>>>> Runnable is
>>>>> passed to Cleaner and appears in the following classes
>>>>>          java/nio/DirectByteBuffer.java
>>>>>          sun/misc/Perf.java
>>>>>          sun/nio/fs/NativeBuffer.java
>>>>>          sun/nio/ch/IOVecWrapper.java
>>>>>          sun/misc/Cleaner/ExitOnThrow.java
>>>>> However none of the above overridden implementations ever create an
>>>>> object in the clean() code.
>>>>>      b) new PrivilegedAction created in try catch Exception block of
>>>>> clean() method but for this object to be created and to be held
>>>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>>>
>>>>> 2) No new heap objects are created in the enqueue method nor 
>>>>> anywhere in
>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>>>> potential cause.
>>>>>
>>>>> *Experimental change to java.lang.Reference.java* :
>>>>> - Put one more guard (try catch with OOME block) in the Reference
>>>>> Handler Thread which may give the Reference Handler a chance to 
>>>>> cleanup.
>>>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>>>> - Without the above change the test fails atleast 3-5 times for every
>>>>> 1000 run.
>>>>>
>>>>> *PS*: The code change is to a very critical part of JDK and i am 
>>>>> fully
>>>>> not aware of the consequences of the change, hence seeking expert 
>>>>> help
>>>>> here. Appreciate your time and inputs towards this.
>>>>>
>>>
>>



From mandy.chung at oracle.com  Mon Dec 23 23:00:17 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Dec 2013 15:00:17 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B8B2DA.7090105@oracle.com>
References: <52B3568B.5050905@oracle.com>
	<52B398A2.8030307@oracle.com>	<52B3B22C.20701@oracle.com>
	<52B3C88E.2030502@oracle.com> <52B4B006.4030308@oracle.com>
	<52B8B2DA.7090105@oracle.com>
Message-ID: <52B8C081.3060103@oracle.com>

On 12/23/2013 2:02 PM, srikalyan chandrashekar wrote:
> Hi Mandy, after some trials i could simulate the failure again (now 
> with UEH in place), however the UEH now cannot print enough details as 
> it also tries to allocate memory, when it does Thread.getName()(it 
> internally creates a String object), printStackTrace() also creates 
> new WrappedPrintStream object. See the following trace
>

That's what I later also thought that may run into after suggesting UEH 
and no object can be allocated at this point.

It worths trying Peter's suggestion to override the modified version of 
Reference class with instrumentation and see what you will get.

Mandy

> Exception: java.lang.OutOfMemoryError thrown from the 
> UncaughtExceptionHandler in thread "Reference Handler"
> ERROR: java.lang.Exception: Reference Handler thread died.
>         at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:483)
>         at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>         at java.lang.Thread.run(Thread.java:744)
>
>
> Meanwhile i am trying looking around to actually print something 
> useful without allocating any new memory.
>
> ---
> Thanks
> kalyan
>
> On 12/20/2013 01:00 PM, srikalyan wrote:
>> Hi Mandy, yes I ran with JTreg to simulate the failure, i will try 
>> the UEH patch to see if it sheds some light and get back to you. 
>> Thanks for the direction :)
>>
>> -- 
>> Thanks
>> kalyan
>> Ph: (408)-585-8040
>>
>>
>> On 12/19/13, 8:33 PM, Mandy Chung wrote:
>>> Hi Srikalyan,
>>>
>>> Maybe you can get add an uncaught handler to see if you can get
>>> any information.  I ran it for 1000 times but not able to duplicate
>>> the failure.  Did you run it with jtreg (I didn't)?
>>>
>>> Below is the patch to install a thread's uncaught handler that
>>> you can take and try.
>>>
>>> diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java 
>>> b/test/java/lang/ref/OOMEInReferenceHand
>>> ler.java
>>> --- a/test/java/lang/ref/OOMEInReferenceHandler.java
>>> +++ b/test/java/lang/ref/OOMEInReferenceHandler.java
>>> @@ -51,6 +51,14 @@
>>>           return first;
>>>       }
>>>
>>> +     static class UEH implements Thread.UncaughtExceptionHandler {
>>> +         public void uncaughtException(Thread t, Throwable e) {
>>> +             System.err.println("ERROR: " + t.getName() + " 
>>> exception " +
>>> +                 e.getMessage());
>>> +             e.printStackTrace();
>>> +         }
>>> +     }
>>> +
>>>       public static void main(String[] args) throws Exception {
>>>           // preinitialize the InterruptedException class so that 
>>> the reference handler
>>>           // does not die due to OOME when loading the class if it 
>>> is the first use
>>> @@ -77,6 +85,8 @@
>>>               throw new IllegalStateException("Couldn't find 
>>> Reference Handler thread.");
>>>           }
>>>
>>> + referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
>>> +
>>>           ReferenceQueue refQueue = new ReferenceQueue<>();
>>>           Object referent = new Object();
>>>           WeakReference weakRef = new 
>>> WeakReference<>(referent, refQueue);
>>>
>>> On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
>>>> Hi David Thanks for your comments, the unguarded part(clean and 
>>>> enqueue) in the Reference Handler thread does not seem to create 
>>>> any new objects, so it is the application(the test in this case) 
>>>> which is adding objects to heap and causing the Reference Handler 
>>>> to die with OOME. I am still unsure about the side effects of the 
>>>> code change and agree with your thoughts(on memory exhaustion 
>>>> test's reliability).
>>>>
>>>> PS: hotspot dev alias removed from CC.
>>>>
>>>> -- 
>>>> Thanks
>>>> kalyan
>>>>
>>>> On 12/19/13 5:08 PM, David Holmes wrote:
>>>>> Hi Kalyan,
>>>>>
>>>>> This is not a hotspot issue so I'm moving this to core-libs, 
>>>>> please drop hotspot from any replies.
>>>>>
>>>>> On 20/12/2013 6:26 AM, srikalyan wrote:
>>>>>> Hi all,  I have been working on the bug JDK-8022321
>>>>>>  , this is a 
>>>>>> sporadic
>>>>>> failure and the webrev is available here
>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ 
>>>>>>
>>>>>
>>>>> I'm really not sure what to make of this. We have a test that 
>>>>> triggers an out-of-memory condition but the OOME can actually turn 
>>>>> up in the ReferenceHandler thread causing it to terminate and the 
>>>>> test to fail. We previously accounted for the non-obvious 
>>>>> occurrences of OOME due to the Object.wait and the possible need 
>>>>> to load the InterruptedException class - but still the OOME can 
>>>>> appear where we don't want it. So finally you have just placed the 
>>>>> whole for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm 
>>>>> certain that makes the test happy, but I'm not sure it is really 
>>>>> what we want for the ReferenceHandler thread. If the OOME occurs 
>>>>> while cleaning, or enqueuing then we will fail to clean and/or 
>>>>> enqueue but there would be no indication that has occurred and I 
>>>>> think that is a bigger problem than this test failing.
>>>>>
>>>>> There may be no way to make this test 100% reliable. In fact I'd 
>>>>> suggest that no memory exhaustion test can be 100% reliable.
>>>>>
>>>>> David
>>>>>
>>>>>> *
>>>>>> **"Root Cause:Still not known"*
>>>>>> 2 places where there is a possibility for OOME
>>>>>> 1) Cleaner.clean()
>>>>>> 2) ReferenceQueue.enqueue()
>>>>>>
>>>>>> 1)  The cleanup code in turn has 2 places where there is 
>>>>>> potential for
>>>>>> throwing OOME,
>>>>>>      a) thunk Thread which is run from clean() method. This 
>>>>>> Runnable is
>>>>>> passed to Cleaner and appears in the following classes
>>>>>>          java/nio/DirectByteBuffer.java
>>>>>>          sun/misc/Perf.java
>>>>>>          sun/nio/fs/NativeBuffer.java
>>>>>>          sun/nio/ch/IOVecWrapper.java
>>>>>>          sun/misc/Cleaner/ExitOnThrow.java
>>>>>> However none of the above overridden implementations ever create an
>>>>>> object in the clean() code.
>>>>>>      b) new PrivilegedAction created in try catch Exception block of
>>>>>> clean() method but for this object to be created and to be held
>>>>>> responsible for OOME an Exception(other than OOME) has to be thrown.
>>>>>>
>>>>>> 2) No new heap objects are created in the enqueue method nor 
>>>>>> anywhere in
>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a
>>>>>> potential cause.
>>>>>>
>>>>>> *Experimental change to java.lang.Reference.java* :
>>>>>> - Put one more guard (try catch with OOME block) in the Reference
>>>>>> Handler Thread which may give the Reference Handler a chance to 
>>>>>> cleanup.
>>>>>> This is fixing the test failure (several 1000 runs with 0 failures)
>>>>>> - Without the above change the test fails atleast 3-5 times for 
>>>>>> every
>>>>>> 1000 run.
>>>>>>
>>>>>> *PS*: The code change is to a very critical part of JDK and i am 
>>>>>> fully
>>>>>> not aware of the consequences of the change, hence seeking expert 
>>>>>> help
>>>>>> here. Appreciate your time and inputs towards this.
>>>>>>
>>>>
>>>
>



From brian.burkhalter at oracle.com  Tue Dec 24 00:58:15 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 23 Dec 2013 16:58:15 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
	
	
	
Message-ID: <593BAB04-2820-497F-A6AF-C5AF5F4ABC5C@oracle.com>

It looks like this could be rearranged to

long result = first * radix + second;
int guard = radix * (int) (first >>> 57);
if (guard >= 128 || (result >= 0 && guard >= 128 - Character.MAX_RADIX)) {
?

provided reasonable comments were added. I understand the first part of this conditional, guard >= 128, but the second part eludes me. Would you please explain this part.

BTW this works for the test case in question, of course.

On Dec 21, 2013, at 2:04 AM, Dmitry Nadezhin wrote:

> I can weaken the question:
> Is there a reason to prefer extra int multiplication to the cache ?
> 
> long result = first * radix + second;
> final int GUARD_BIT = 7;
> int guard = radix * (int) (first >>> (Long.SIZE - GUARD_BIT));
> if (guard >= (1 << GUARD_BIT) - Character.MAX_RADIX
>     && (guard >= (1 << GUARD_BIT) || result >= 0)) {
>  . . .



From mandy.chung at oracle.com  Tue Dec 24 02:00:40 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Dec 2013 18:00:40 -0800
Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java
	fails intermittently
In-Reply-To: <52B5C6C3.7000208@gmail.com>
References: <52B3568B.5050905@oracle.com>
	<52B398A2.8030307@oracle.com>	<52B3B22C.20701@oracle.com>
	<52B3C88E.2030502@oracle.com>
	<4D6B1813-EEB6-4388-9FC7-2E0BDF004222@oracle.com>
	<52B5C6C3.7000208@gmail.com>
Message-ID: <52B8EAC8.1080409@oracle.com>


On 12/21/2013 8:50 AM, Peter Levart wrote:
> Is it possible to get the test output when it fails? It can fail in 
> two different ways. I can't look at the bug (not authorized)...

You should be able to look at it now.  There isn't any other information 
besides OOME error.

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Reference Handler"
java.lang.Exception: Reference Handler thread died.
at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:491)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:724)

Mandy


From dmitry.nadezhin at gmail.com  Tue Dec 24 02:02:06 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Tue, 24 Dec 2013 06:02:06 +0400
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: <593BAB04-2820-497F-A6AF-C5AF5F4ABC5C@oracle.com>
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
	
	
	
	<593BAB04-2820-497F-A6AF-C5AF5F4ABC5C@oracle.com>
Message-ID: 

We have
first/0x1p57 - 1 < JAVA{first>>>57} && JAVA{first>>>57} <= first/0x1p57.
Here JAVA{.} stands for Java expression with all its truncations and
wrappings.
Expressions without JAVA{.}are exact mathematical expressions.

JAVA{first>>>57}  <= first/0x1p57 < 1p64/1p57 = 1p7, radix <=
Character.MAX_RADIX = 36, hence
JAVA{(int)(first>>>57)} = JAVA{first>>>57}.
guard = JAVA{radix * (int)(first>>>57)} = radix*JAVA{first>>>57}.

radix*(first/0x1p57 - 1) < guard && guard <= radix*first/0x1p57 .
radix*first/0x1p57 - Character.MAX_RADIX < guard && guard <=
radix*first/0x1p57 .
This means
guard*0xp57 <= first*radix && first*radix < (guard +
Character.MAX_RADIX)*0x1p57
guard*0xp57 <= first*radix + second && first*radix + second < (guard +
Character.MAX_RADIX)*0x1p57 + Character.MAX_RADIX .

Now we shall split by "guard".

When guard >= 128 = 1p7, we have first*first + second >= 1p7 * 1p57 = 1p64
hence overflow always occur in this.

When guard < 128 - Character,MAX_RADIX,  we have
guard + Character.MAX_RADIX <= 127
first*radix + second < 127*0x1p57 + 36 < 0x1p64 , hence overflow doesn't
occur in this.

When 128 - Character.MAX_RADIX <= guard && guard < 128 ,
(128 - Character.MAX_RADIX)*0xp57 <= first*radix + second && first*radix +
second < (127 + Character.MAX_RADIX)*0x1p57 + Character.MAX_RADIX.
0x1p63 < (128 - 36)*0xp57 <= first*radix + second && first*radix + second <
(128 + 36)*1p57 + 36 < 0x1p64 + 0x1p63 .
Hence JAVA{first*radix + second} = (first*radix + second - 0x1p64)
JAVA{result >= 0} = JAVA{first*radix + second >= 0} = (first*radix + second
>= 0x1p64).
Hence overflow is detected correctly in this case too.



On Tue, Dec 24, 2013 at 4:58 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> It looks like this could be rearranged to
>
> long result = first * radix + second;
> int guard = radix * (int) (first >>> 57);
> if (guard >= 128 || (result >= 0 && guard >= 128 - Character.MAX_RADIX)) {
> ?
>
> provided reasonable comments were added. I understand the first part of
> this conditional, guard >= 128, but the second part eludes me. Would you
> please explain this part.
>
> BTW this works for the test case in question, of course.
>
> On Dec 21, 2013, at 2:04 AM, Dmitry Nadezhin wrote:
>
> > I can weaken the question:
> > Is there a reason to prefer extra int multiplication to the cache ?
> >
> > long result = first * radix + second;
> > final int GUARD_BIT = 7;
> > int guard = radix * (int) (first >>> (Long.SIZE - GUARD_BIT));
> > if (guard >= (1 << GUARD_BIT) - Character.MAX_RADIX
> >     && (guard >= (1 << GUARD_BIT) || result >= 0)) {
> >  . . .
>
>


From michael.fang at oracle.com  Tue Dec 24 05:52:02 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 23 Dec 2013 21:52:02 -0800
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B72C1C.8000703@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
Message-ID: <52B92102.9090201@oracle.com>

Thanks Aleksej for addressing the ACT issue. The l10n files look fine to 
me. I agree that we should work on translation consistency issues 
separately the next time we have a translation cycle.

thanks,

-michael

On 13?12?22? 10:14 ??, Aleksej Efimov wrote:
> Hi,
> The new version of patch for TimeZone display names update is 
> available. Previous webrev contains incorrect naming for Acre timezone 
> generic name (ACT[] array) across all non-root locales. The name was 
> corrected and test TimeZoneNames_*.properties files were modified 
> accordingly.
> The new webrev: 
> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
> 
>
> -Aleksej
>
> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> Thank you for the detailed review and your comments. I tried to 
>> address all of them. The responses are below. The new webrev can be 
>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>> 
>>
>> Michael,
>> As Masayoshi mentioned, we have a list of inconsistent translations 
>> in translation files. I suggest two approaches to resolve it: 1. Log 
>> different bug with all problems in translation files. 2. Wait for the 
>> next resource file translation update to address these problems.
>>
>> -Aleksej
>>
>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>>
>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>> fix includes:
>>>
>>> Common to all modified files:
>>> - All year ranges in the copyright header should be modified 
>>> accordingly.
>>
>> Fixed.
>>
>>>
>>>>  - The translation of time zone generic names were added to all 
>>>> locales.
>>>
>>> I haven't fully reviewed translations, especially all \uxxxx 
>>> strings. But I noticed the following.
>>>
>>> Common to all TimeZoneNames_*.java:
>>> - The same generic abbreviation is used for the long name in MET. I 
>>> thought this was fixed in the root properties...
>>
>> No, the "MET" is used in root properties both for generic long and 
>> short names. I will update these names when new translation update 
>> will be available.
>>
>>> - Some generic names don't match the style of their standard and/or 
>>> daylight time names.
>>
>> The same as previous. This is a first large update for generic names 
>> and latest translations. All inconsistency in translations will be 
>> fixed during next translation update.
>>
>>>
>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>> - Some generic names use "Normalzeit". Is that OK?
>>
>> It's not good. But the resolution is same as previous two.
>>
>>>
>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>> - "Chuuk Time" isn't translated.
>>
>> I think it will be translated in next translations update.
>>
>>>
>>>>  - Time Zone names were updated according to the latest translations.
>>>>  - Added tz names regression test 
>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>> names across all locales. This test compares short/long 
>>>> standard/daylight/generic names with translations stored in 
>>>> .properties files.
>>>
>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>
>>> - lines 33, 34: unused imports?
>>
>> Removed
>>
>>> - line 75: Should it be detected as an error?
>>
>> Agree, now the test will fail if there is some incorrect entries in 
>> the test .properties files.
>>
>>> - line 108: IOException should be used as a cause. (OK to assume 
>>> "not found"?)
>>
>> The IOException cause is added. Currently, the test will stop with 
>> RuntimeException, because the test file is not found.
>>
>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>> Locale.ROOT. Regression tests are run in different locales.
>>
>> Thank you for catching this one. Fixed.
>>
>>>
>>>>  - Tests updates to address current changes ( 
>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>
>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>> removed.
>>
>> Removed
>>
>>>
>>>>
>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>> test set succeeded (new test is included in this test set).
>>>
>>> Have you executed all date-time related regression tests (including 
>>> java.time and java.text)?
>>
>> Yes, I have executed the following set of tests via JTREG:
>> test/sun/util/calendar test/java/util/Calendar 
>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
>> All tests gave "PASS" results.
>> Please, let me know if you think that some other tests should be 
>> executed.
>>
>>
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>
>>>
>>
>


From tristan.yan at oracle.com  Tue Dec 24 05:59:09 2013
From: tristan.yan at oracle.com (Tristan Yan)
Date: Tue, 24 Dec 2013 13:59:09 +0800
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
In-Reply-To: <52B4DA73.3070602@oracle.com>
References: <52B29168.9070302@oracle.com> <52B3B41C.8080003@oracle.com>
	<52B3C7A5.7050705@oracle.com> <52B4DA73.3070602@oracle.com>
Message-ID: <52B922AD.8060704@oracle.com>

Hi Stuart
I did an experiment that set a small thread stack size using the 
-Xss228k or -Xss512k. The result is surprised that jtreg reports the 
test passed. Although I can see the StackOverflowError showing in the 
log even when I set thread stack size as 512k . So the problem is old 
shell script doesn't report the error even there is a StackOverflowError.
Thank you.
Tristan

On 12/21/2013 08:01 AM, Stuart Marks wrote:
> On 12/19/13 8:29 PM, David Holmes wrote:
>> If you were always one frame from the end then it is not so 
>> surprising that a
>> simple change pushes you past the limit :) Try running the shell test 
>> with
>> additional recursive loads and see when it fails.
>
> David doesn't seem surprised, but I guess I still am. :-)
>
> Tristan, do you think you could do some investigation here, regarding 
> the shell script based test's stack consumption? Run the shell-based 
> test with some different values for -Xss and see how low you have to 
> set it before it generates a stack overflow.
>
>>> It's also kind of strange that in the two stack traces I've seen (I
>>> think I managed to capture only one in the bug report though) the
>>> StackOverflowError occurs on loading exactly the 50th class. Since 
>>> we're
>>> observing intermittent behavior (happens sometimes but not others) the
>>> stack size is apparently variable. Since it's variable I'd expect to 
>>> see
>>> it failing at different times, possibly the 49th or 48th recursive
>>> classload, not just the 50th. And in such circumstances, do we know 
>>> what
>>> the default stack size is?
>>
>> Classloading consumes a reasonable chunk of stack so if the variance 
>> elsewhere
>> is quite small it is not that surprising that the test always fails 
>> on the 50th
>> class. I would not expect run-to-run stack usage variance to be high 
>> unless
>> there is some random component to the test.
>
> Hm. There should be no variance in stack usage coming from the test 
> itself. I believe the test does the same thing every time.
>
> The thing I'm concerned about is whether the Java-based test is doing 
> something different from the shell-based test, because of the 
> execution environment (jtreg or other). We may end up simply raising 
> the stack limit anyway, but I still find it hard to believe that the 
> shell-based test was consistently just a few frames shy of a stack 
> overflow.
>
> The failure is intermittent; we've seen it twice in JPRT (our internal 
> build&test system). Possible sources of the intermittency are from the 
> different machines on which the test executes. So environmental 
> factors could be at play. How does the JVM determine the default stack 
> size? Could different test runs on different machines be running with 
> different stack sizes?
>
> Another source of variance is the JIT. I believe JIT-compiled code 
> consumes stack differently from interpreted code. At least, I've seen 
> differences in stack usage between -Xint and -Xcomp runs, and in the 
> absence of these options (which means -Xmixed, I guess) the results 
> sometimes vary unpredictably. I guess this might have to do with when 
> the JIT compiler decides to kick in.
>
> This test does perform a bunch of iterations, so JIT compilation could 
> be a factor.
>
>>> I don't know if you were able to reproduce this issue. If you were, it
>>> would be good to understand in more detail exactly what's going on.
>>
>> FWIW there was a recent change in 7u to bump up the number of stack 
>> shadow pages
>> in hotspot as "suddenly" StackOverflow tests were crashing instead of 
>> triggering
>> StackOverflowError. So something started using more stack in a way 
>> the caused
>> there to not be enough space to process a stackoverflow properly. 
>> Finding the
>> exact cause can be somewhat tedious.
>
> This seems like a different problem. We're seeing actual 
> StackOverflowErrors, not crashes. Good to look out for this, though.
>
> s'marks
>
>
>>
>> Cheers,
>> David
>>
>>> s'marks



From masayoshi.okutsu at oracle.com  Tue Dec 24 06:39:12 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 Dec 2013 15:39:12 +0900
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B72C1C.8000703@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
Message-ID: <52B92C10.2060008@oracle.com>

Looks good to me.

Masayoshi

On 12/23/2013 3:14 AM, Aleksej Efimov wrote:
> Hi,
> The new version of patch for TimeZone display names update is 
> available. Previous webrev contains incorrect naming for Acre timezone 
> generic name (ACT[] array) across all non-root locales. The name was 
> corrected and test TimeZoneNames_*.properties files were modified 
> accordingly.
> The new webrev: 
> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
> 
>
> -Aleksej
>
> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> Thank you for the detailed review and your comments. I tried to 
>> address all of them. The responses are below. The new webrev can be 
>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>> 
>>
>> Michael,
>> As Masayoshi mentioned, we have a list of inconsistent translations 
>> in translation files. I suggest two approaches to resolve it: 1. Log 
>> different bug with all problems in translation files. 2. Wait for the 
>> next resource file translation update to address these problems.
>>
>> -Aleksej
>>
>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>>
>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>> fix includes:
>>>
>>> Common to all modified files:
>>> - All year ranges in the copyright header should be modified 
>>> accordingly.
>>
>> Fixed.
>>
>>>
>>>>  - The translation of time zone generic names were added to all 
>>>> locales.
>>>
>>> I haven't fully reviewed translations, especially all \uxxxx 
>>> strings. But I noticed the following.
>>>
>>> Common to all TimeZoneNames_*.java:
>>> - The same generic abbreviation is used for the long name in MET. I 
>>> thought this was fixed in the root properties...
>>
>> No, the "MET" is used in root properties both for generic long and 
>> short names. I will update these names when new translation update 
>> will be available.
>>
>>> - Some generic names don't match the style of their standard and/or 
>>> daylight time names.
>>
>> The same as previous. This is a first large update for generic names 
>> and latest translations. All inconsistency in translations will be 
>> fixed during next translation update.
>>
>>>
>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>> - Some generic names use "Normalzeit". Is that OK?
>>
>> It's not good. But the resolution is same as previous two.
>>
>>>
>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>> - "Chuuk Time" isn't translated.
>>
>> I think it will be translated in next translations update.
>>
>>>
>>>>  - Time Zone names were updated according to the latest translations.
>>>>  - Added tz names regression test 
>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>> names across all locales. This test compares short/long 
>>>> standard/daylight/generic names with translations stored in 
>>>> .properties files.
>>>
>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>
>>> - lines 33, 34: unused imports?
>>
>> Removed
>>
>>> - line 75: Should it be detected as an error?
>>
>> Agree, now the test will fail if there is some incorrect entries in 
>> the test .properties files.
>>
>>> - line 108: IOException should be used as a cause. (OK to assume 
>>> "not found"?)
>>
>> The IOException cause is added. Currently, the test will stop with 
>> RuntimeException, because the test file is not found.
>>
>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>> Locale.ROOT. Regression tests are run in different locales.
>>
>> Thank you for catching this one. Fixed.
>>
>>>
>>>>  - Tests updates to address current changes ( 
>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>
>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>> removed.
>>
>> Removed
>>
>>>
>>>>
>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>> test set succeeded (new test is included in this test set).
>>>
>>> Have you executed all date-time related regression tests (including 
>>> java.time and java.text)?
>>
>> Yes, I have executed the following set of tests via JTREG:
>> test/sun/util/calendar test/java/util/Calendar 
>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
>> All tests gave "PASS" results.
>> Please, let me know if you think that some other tests should be 
>> executed.
>>
>>
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>
>>>
>>
>



From aleksej.efimov at oracle.com  Tue Dec 24 13:21:23 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 24 Dec 2013 17:21:23 +0400
Subject:  RFR: 8025051: Update resource files for TimeZone
	display names
In-Reply-To: <52B92C10.2060008@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
	<52B92C10.2060008@oracle.com>
Message-ID: <52B98A53.4020408@oracle.com>

Masayoshi, Michael,
Many thanks for reviewing this fix and for all your comments.

Can I ask someone for a JDK8 commit sponsorship? The hg export is 
located here: 
http://cr.openjdk.java.net/~aefimov/8025051/8/8025051_jdk8.patch

Also, I want to take this opportunity and wish a Merry Christmas and 
Happy New Year to all OpenJDK community members (at least members who 
read this letter :) ).

-Aleksej

On 12/24/2013 10:39 AM, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
> On 12/23/2013 3:14 AM, Aleksej Efimov wrote:
>> Hi,
>> The new version of patch for TimeZone display names update is 
>> available. Previous webrev contains incorrect naming for Acre 
>> timezone generic name (ACT[] array) across all non-root locales. The 
>> name was corrected and test TimeZoneNames_*.properties files were 
>> modified accordingly.
>> The new webrev: 
>> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
>> 
>>
>> -Aleksej
>>
>> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> Thank you for the detailed review and your comments. I tried to 
>>> address all of them. The responses are below. The new webrev can be 
>>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>>> 
>>>
>>> Michael,
>>> As Masayoshi mentioned, we have a list of inconsistent translations 
>>> in translation files. I suggest two approaches to resolve it: 1. Log 
>>> different bug with all problems in translation files. 2. Wait for 
>>> the next resource file translation update to address these problems.
>>>
>>> -Aleksej
>>>
>>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>>> Hi,
>>>>>
>>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>>> fix includes:
>>>>
>>>> Common to all modified files:
>>>> - All year ranges in the copyright header should be modified 
>>>> accordingly.
>>>
>>> Fixed.
>>>
>>>>
>>>>>  - The translation of time zone generic names were added to all 
>>>>> locales.
>>>>
>>>> I haven't fully reviewed translations, especially all \uxxxx 
>>>> strings. But I noticed the following.
>>>>
>>>> Common to all TimeZoneNames_*.java:
>>>> - The same generic abbreviation is used for the long name in MET. I 
>>>> thought this was fixed in the root properties...
>>>
>>> No, the "MET" is used in root properties both for generic long and 
>>> short names. I will update these names when new translation update 
>>> will be available.
>>>
>>>> - Some generic names don't match the style of their standard and/or 
>>>> daylight time names.
>>>
>>> The same as previous. This is a first large update for generic names 
>>> and latest translations. All inconsistency in translations will be 
>>> fixed during next translation update.
>>>
>>>>
>>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>>> - Some generic names use "Normalzeit". Is that OK?
>>>
>>> It's not good. But the resolution is same as previous two.
>>>
>>>>
>>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>>> - "Chuuk Time" isn't translated.
>>>
>>> I think it will be translated in next translations update.
>>>
>>>>
>>>>>  - Time Zone names were updated according to the latest translations.
>>>>>  - Added tz names regression test 
>>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>>> names across all locales. This test compares short/long 
>>>>> standard/daylight/generic names with translations stored in 
>>>>> .properties files.
>>>>
>>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>>
>>>> - lines 33, 34: unused imports?
>>>
>>> Removed
>>>
>>>> - line 75: Should it be detected as an error?
>>>
>>> Agree, now the test will fail if there is some incorrect entries in 
>>> the test .properties files.
>>>
>>>> - line 108: IOException should be used as a cause. (OK to assume 
>>>> "not found"?)
>>>
>>> The IOException cause is added. Currently, the test will stop with 
>>> RuntimeException, because the test file is not found.
>>>
>>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>>> Locale.ROOT. Regression tests are run in different locales.
>>>
>>> Thank you for catching this one. Fixed.
>>>
>>>>
>>>>>  - Tests updates to address current changes ( 
>>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>>
>>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>>> removed.
>>>
>>> Removed
>>>
>>>>
>>>>>
>>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>>> test set succeeded (new test is included in this test set).
>>>>
>>>> Have you executed all date-time related regression tests (including 
>>>> java.time and java.text)?
>>>
>>> Yes, I have executed the following set of tests via JTREG:
>>> test/sun/util/calendar test/java/util/Calendar 
>>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>>  test/java/time  test/java/util/Formatter 
>>> test/closed/java/util/Calendar
>>> All tests gave "PASS" results.
>>> Please, let me know if you think that some other tests should be 
>>> executed.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>>
>>>>
>>>
>>
>



From stuart.marks at oracle.com  Tue Dec 24 17:24:38 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 24 Dec 2013 09:24:38 -0800
Subject: RFR: 8007256: RMI testlibrary cleanup: remove JavaVMCallbackHandler
Message-ID: <52B9C356.8090206@oracle.com>

Hi all,

A simple change to the RMI test library: remove a callback-based mechanism, 
which is no longer used by any tests. A bit of associated cleanup is included as 
well.

Bug:

   https://bugs.openjdk.java.net/browse/JDK-8007256

Webrev:

   http://cr.openjdk.java.net/~smarks/reviews/8007256/webrev.0/

Thanks,

s'marks


From joe.darcy at oracle.com  Tue Dec 24 17:26:34 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 24 Dec 2013 09:26:34 -0800
Subject: RFR: 8007256: RMI testlibrary cleanup: remove
	JavaVMCallbackHandler
In-Reply-To: <52B9C356.8090206@oracle.com>
References: <52B9C356.8090206@oracle.com>
Message-ID: <52B9C3CA.2010306@oracle.com>

Looks good Stuart,

-Joe

On 12/24/2013 9:24 AM, Stuart Marks wrote:
> Hi all,
>
> A simple change to the RMI test library: remove a callback-based 
> mechanism, which is no longer used by any tests. A bit of associated 
> cleanup is included as well.
>
> Bug:
>
>   https://bugs.openjdk.java.net/browse/JDK-8007256
>
> Webrev:
>
>   http://cr.openjdk.java.net/~smarks/reviews/8007256/webrev.0/
>
> Thanks,
>
> s'marks



From stuart.marks at oracle.com  Tue Dec 24 17:28:04 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 24 Dec 2013 09:28:04 -0800
Subject: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI
	bench/serial test
In-Reply-To: <52B922AD.8060704@oracle.com>
References: <52B29168.9070302@oracle.com> <52B3B41C.8080003@oracle.com>
	<52B3C7A5.7050705@oracle.com> <52B4DA73.3070602@oracle.com>
	<52B922AD.8060704@oracle.com>
Message-ID: <52B9C424.7060804@oracle.com>

Hi Tristan,

Aha! Mystery solved. So it's not that the error started occurring after the 
conversion from shell script to Java, it merely started /*appearing*/ after this 
conversion. This makes sense now. Thanks for doing this investigation. As if we 
needed any more reason to convert shell script tests to Java....

You had previously posted a one-line patch to raise the stack size, so I'll just 
go ahead and push that for you.

Thanks,

s'marks

On 12/23/13 9:59 PM, Tristan Yan wrote:
> Hi Stuart
> I did an experiment that set a small thread stack size using the -Xss228k or 
> -Xss512k. The result is surprised that jtreg reports the test passed. Although 
> I can see the StackOverflowError showing in the log even when I set thread 
> stack size as 512k . So the problem is old shell script doesn't report the 
> error even there is a StackOverflowError.
> Thank you.
> Tristan
>
> On 12/21/2013 08:01 AM, Stuart Marks wrote:
>> On 12/19/13 8:29 PM, David Holmes wrote:
>>> If you were always one frame from the end then it is not so surprising that a
>>> simple change pushes you past the limit :) Try running the shell test with
>>> additional recursive loads and see when it fails.
>>
>> David doesn't seem surprised, but I guess I still am. :-)
>>
>> Tristan, do you think you could do some investigation here, regarding the 
>> shell script based test's stack consumption? Run the shell-based test with 
>> some different values for -Xss and see how low you have to set it before it 
>> generates a stack overflow.
>>
>>>> It's also kind of strange that in the two stack traces I've seen (I
>>>> think I managed to capture only one in the bug report though) the
>>>> StackOverflowError occurs on loading exactly the 50th class. Since we're
>>>> observing intermittent behavior (happens sometimes but not others) the
>>>> stack size is apparently variable. Since it's variable I'd expect to see
>>>> it failing at different times, possibly the 49th or 48th recursive
>>>> classload, not just the 50th. And in such circumstances, do we know what
>>>> the default stack size is?
>>>
>>> Classloading consumes a reasonable chunk of stack so if the variance elsewhere
>>> is quite small it is not that surprising that the test always fails on the 50th
>>> class. I would not expect run-to-run stack usage variance to be high unless
>>> there is some random component to the test.
>>
>> Hm. There should be no variance in stack usage coming from the test itself. I 
>> believe the test does the same thing every time.
>>
>> The thing I'm concerned about is whether the Java-based test is doing 
>> something different from the shell-based test, because of the execution 
>> environment (jtreg or other). We may end up simply raising the stack limit 
>> anyway, but I still find it hard to believe that the shell-based test was 
>> consistently just a few frames shy of a stack overflow.
>>
>> The failure is intermittent; we've seen it twice in JPRT (our internal 
>> build&test system). Possible sources of the intermittency are from the 
>> different machines on which the test executes. So environmental factors could 
>> be at play. How does the JVM determine the default stack size? Could 
>> different test runs on different machines be running with different stack sizes?
>>
>> Another source of variance is the JIT. I believe JIT-compiled code consumes 
>> stack differently from interpreted code. At least, I've seen differences in 
>> stack usage between -Xint and -Xcomp runs, and in the absence of these 
>> options (which means -Xmixed, I guess) the results sometimes vary 
>> unpredictably. I guess this might have to do with when the JIT compiler 
>> decides to kick in.
>>
>> This test does perform a bunch of iterations, so JIT compilation could be a 
>> factor.
>>
>>>> I don't know if you were able to reproduce this issue. If you were, it
>>>> would be good to understand in more detail exactly what's going on.
>>>
>>> FWIW there was a recent change in 7u to bump up the number of stack shadow 
>>> pages
>>> in hotspot as "suddenly" StackOverflow tests were crashing instead of 
>>> triggering
>>> StackOverflowError. So something started using more stack in a way the caused
>>> there to not be enough space to process a stackoverflow properly. Finding the
>>> exact cause can be somewhat tedious.
>>
>> This seems like a different problem. We're seeing actual StackOverflowErrors, 
>> not crashes. Good to look out for this, though.
>>
>> s'marks
>>
>>
>>>
>>> Cheers,
>>> David
>>>
>>>> s'marks
>



From kumar.x.srinivasan at oracle.com  Tue Dec 24 17:34:07 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 24 Dec 2013 17:34:07 +0000
Subject: hg: jdk8/tl/langtools: 8029230: Update copyright year to match last
	edit in jdk8 langtools repository for 2013
Message-ID: <20131224173411.CDE7062EE7@hg.openjdk.java.net>

Changeset: 998b10c43157
Author:    ksrini
Date:      2013-12-24 09:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/998b10c43157

8029230: Update copyright year to match last edit in jdk8 langtools repository for 2013
Reviewed-by: ksrini
Contributed-by: steve.sides at oracle.com

! make/Makefile
! src/share/classes/com/sun/javadoc/AnnotationDesc.java
! src/share/classes/com/sun/source/doctree/package-info.java
! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
! src/share/classes/com/sun/tools/jdeps/Archive.java
! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/share/classes/com/sun/tools/sjavac/CleanProperties.java
! src/share/classes/com/sun/tools/sjavac/CompileChunk.java
! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
! src/share/classes/com/sun/tools/sjavac/CompileProperties.java
! src/share/classes/com/sun/tools/sjavac/CopyFile.java
! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/Log.java
! src/share/classes/com/sun/tools/sjavac/Module.java
! src/share/classes/com/sun/tools/sjavac/Package.java
! src/share/classes/com/sun/tools/sjavac/ProblemException.java
! src/share/classes/com/sun/tools/sjavac/Source.java
! src/share/classes/com/sun/tools/sjavac/Transformer.java
! src/share/classes/com/sun/tools/sjavac/Util.java
! src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java
! src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java
! src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java
! src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java
! src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java
! src/share/classes/com/sun/tools/sjavac/server/PortFile.java
! src/share/classes/com/sun/tools/sjavac/server/SysInfo.java
! src/share/classes/javax/lang/model/element/TypeElement.java
! src/share/classes/javax/lang/model/element/VariableElement.java
! src/share/classes/javax/lang/model/element/package-info.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java
! test/com/sun/javadoc/testAbstractMethod/pkg/A.java
! test/com/sun/javadoc/testAbstractMethod/pkg/B.java
! test/com/sun/javadoc/testAbstractMethod/pkg/C.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java
! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java
! test/com/sun/javadoc/testLegacyTaglet/C.java
! test/com/sun/javadoc/testNavigation/pkg/A.java
! test/com/sun/javadoc/testNavigation/pkg/C.java
! test/com/sun/javadoc/testNavigation/pkg/E.java
! test/com/sun/javadoc/testNavigation/pkg/I.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java
! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java
! test/tools/javac/T6725036.java
! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java
! test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java
! test/tools/javac/annotations/typeAnnotations/TargetTypes.java
! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java
! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java
! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java
! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java
! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java
! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java
! test/tools/javac/cast/intersection/model/Model01.java
! test/tools/javac/cast/intersection/model/ModelChecker.java
! test/tools/javac/defaultMethods/static/Static01.java
! test/tools/javac/defaultMethods/static/Static02.java
! test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java
! test/tools/javac/defaultMethods/static/import/StaticImport1.java
! test/tools/javac/defaultMethods/static/import/StaticImport2.java
! test/tools/javac/defaultMethods/static/import/StaticImport3.java
! test/tools/javac/defaultMethods/static/import/pkg/A.java
! test/tools/javac/defaultMethods/static/import/pkg/B.java
! test/tools/javac/defaultMethods/static/import/pkg/C.java
! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java
! test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
! test/tools/javac/diags/examples/NotInProfile.java
! test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java
! test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java
! test/tools/javac/diags/examples/WhereIntersection.java
! test/tools/javac/generics/odersky/BadTest4.java
! test/tools/javac/lambda/DoubleStaticImport.java
! test/tools/javac/lambda/Intersection01.java
! test/tools/javac/lambda/Intersection02.java
! test/tools/javac/lambda/LambdaCapture06.java
! test/tools/javac/lambda/LambdaConv01.java
! test/tools/javac/lambda/LambdaExpr15.java
! test/tools/javac/lambda/MethodReference25.java
! test/tools/javac/lambda/MethodReference26.java
! test/tools/javac/lambda/MethodReference59.java
! test/tools/javac/lambda/MethodReference60.java
! test/tools/javac/lambda/TargetType51.java
! test/tools/javac/lambda/lambdaExecution/InInterface.java
! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java
! test/tools/javac/lambda/methodReference/BridgeMethod.java
! test/tools/javac/lambda/methodReference/SamConversion.java
! test/tools/javac/lambda/methodReference/SamConversionComboTest.java
! test/tools/javac/lambda/typeInference/InferenceTest2b.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/multicatch/Pos05.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java
! test/tools/javac/resolve/Pos.java
! test/tools/javac/resolve/ResolveHarness.java
! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java
! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java
! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java
! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
! test/tools/jdeps/APIDeps.java
! test/tools/jdeps/p/Foo.java



From mike.duigou at oracle.com  Tue Dec 24 18:53:13 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 24 Dec 2013 10:53:13 -0800
Subject: JDK 8 and 9 RFR of 8030212: Several api.java.util.stream tests
	got "NaN" value instead of "Infinity" or "-Infinity"
In-Reply-To: <52B6FD1E.7080509@oracle.com>
References: <52B6FD1E.7080509@oracle.com>
Message-ID: 

Approved. These changes are a reasonable solution and, as you say, we can improve it further in future releases.

Mike

On Dec 22 2013, at 06:54 , Joe Darcy  wrote:

> Hello,
> 
> Testing (eventually) revealed that changing the streams floating point sum and average algorithms to use compensated summation (JDK-8006572 DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors), changed the behavior of the code on streams with infinite values: NaN was returned instead of infinity:
> 
>    8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity"
> 
> The specification doesn't explicitly state how non-finite values in streams should be handled (and it should be updated to do so in 9, JDK-8030942 Explicitly state floating-point summation requirements on non-finite inputs), but it isn't unreasonable to assume that a properly signed infinity should result.
> 
> Towards that end, I've prepared a webrev that uses an additional simple sum to distinguish a spurious NaN sum in the result:
> 
>    http://cr.openjdk.java.net/~darcy/8030212.1/
> 
> This may not be the optimal way to track this situation, additional logic in the compensated summation code is possible, but if needed the implementation can be refined in JDK 9 and the 8 updates.
> 
> Thanks,
> 
> -Joe



From brian.burkhalter at oracle.com  Tue Dec 24 21:30:21 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 24 Dec 2013 13:30:21 -0800
Subject: Bug in Long.parseUnsignedLong
In-Reply-To: 
References: 
	
	<72290CBA-5CF6-4138-82F2-05E61935E72F@oracle.com>
	
	
	<17AF179C-E782-4D92-BC6C-30044556E4B0@oracle.com>
	<8F48C2BF-1A67-421B-B4F8-E13AF564C6B7@oracle.com>
	<057002D1-0130-4E13-8EC0-1FEDE4924A78@oracle.com>
	
	
	
	<593BAB04-2820-497F-A6AF-C5AF5F4ABC5C@oracle.com>
	
Message-ID: <65C3A36B-464F-4E07-B690-C0930F6F7857@oracle.com>

Thanks for the clarification. It looks good to me.

Does anyone have any comments on the various competing proposed fixes? As for me, I like this one with int operations and no cache.

Thanks,

Brian

On Dec 23, 2013, at 6:02 PM, Dmitry Nadezhin wrote:

> We have
> first/0x1p57 - 1 < JAVA{first>>>57} && JAVA{first>>>57} <= first/0x1p57.
> [?]
> Hence overflow is detected correctly in this case too.



From lana.steuck at oracle.com  Wed Dec 25 20:15:33 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:33 +0000
Subject: hg: jdk8/tl/jaxp: 3 new changesets
Message-ID: <20131225201549.D312B62F1A@hg.openjdk.java.net>

Changeset: 51d5d5eef0d8
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/51d5d5eef0d8

Added tag jdk8-b121 for changeset 4045edd35e8b

! .hgtags

Changeset: fad4b4d28599
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fad4b4d28599

Merge


Changeset: 93bf25903af0
Author:    lana
Date:      2013-12-25 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/93bf25903af0

Merge




From lana.steuck at oracle.com  Wed Dec 25 20:15:40 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:40 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20131225201558.4B14D62F1B@hg.openjdk.java.net>

Changeset: a42071a6d61f
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a42071a6d61f

Added tag jdk8-b121 for changeset afe63d41c699

! .hgtags

Changeset: 56943b19c119
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56943b19c119

Merge

- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif

Changeset: 232b9cf6303a
Author:    lana
Date:      2013-12-25 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/232b9cf6303a

Merge




From lana.steuck at oracle.com  Wed Dec 25 20:15:22 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:22 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20131225201526.BAC0762F16@hg.openjdk.java.net>

Changeset: 15a9cdd9d64e
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/15a9cdd9d64e

Added tag jdk8-b121 for changeset a7d3638deb2f

! .hgtags

Changeset: 2a8fa4da6ad3
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/2a8fa4da6ad3

Merge


Changeset: 0cd687347540
Author:    lana
Date:      2013-12-25 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/0cd687347540

Merge




From lana.steuck at oracle.com  Wed Dec 25 20:15:26 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:26 +0000
Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b121 for changeset 32050ab53c8a
Message-ID: <20131225201533.91F0662F17@hg.openjdk.java.net>

Changeset: bc622ba563f9
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bc622ba563f9

Added tag jdk8-b121 for changeset 32050ab53c8a

! .hgtags



From lana.steuck at oracle.com  Wed Dec 25 20:15:19 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:19 +0000
Subject: hg: jdk8/tl: Added tag jdk8-b121 for changeset 1e1f86d5d4e2
Message-ID: <20131225201520.7EFC862F15@hg.openjdk.java.net>

Changeset: 347009c58816
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/347009c58816

Added tag jdk8-b121 for changeset 1e1f86d5d4e2

! .hgtags



From lana.steuck at oracle.com  Wed Dec 25 20:16:43 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:16:43 +0000
Subject: hg: jdk8/tl/jdk: 16 new changesets
Message-ID: <20131225202046.4010562F1E@hg.openjdk.java.net>

Changeset: b822fa97c67a
Author:    rgallard
Date:      2013-12-12 22:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b822fa97c67a

8027844: Remove the JDK 1.1 compatibility part in jarsigner doc
Reviewed-by: weijun

! src/bsd/doc/man/jarsigner.1
! src/linux/doc/man/jarsigner.1
! src/solaris/doc/sun/man/man1/jarsigner.1

Changeset: 32cc35351303
Author:    rgallard
Date:      2013-12-13 14:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32cc35351303

8027709: JDK8 docs on -XX:CompileOnly option are incorrect
Summary: Alexey Zhebel (azhebel) contributed these changes.
Reviewed-by: kvn

! src/bsd/doc/man/java.1
! src/linux/doc/man/java.1
! src/solaris/doc/sun/man/man1/java.1

Changeset: ce05e132b137
Author:    katleman
Date:      2013-12-17 12:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce05e132b137

Merge


Changeset: f63994f1eab4
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f63994f1eab4

Added tag jdk8-b121 for changeset ce05e132b137

! .hgtags

Changeset: c8c4aef922ff
Author:    vadim
Date:      2013-12-13 11:49 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8c4aef922ff

8029628: Many graphic artifacts
Reviewed-by: prr, bae

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 6ecbfe5e211b
Author:    lana
Date:      2013-12-19 10:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ecbfe5e211b

Merge


Changeset: 9e0e8eed676a
Author:    pchelko
Date:      2013-12-06 17:47 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e0e8eed676a

8029565: java.awt.dnd.InvalidDnDOperationException: data translation failed on file drop
Reviewed-by: anthony, serb

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/SourceFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/TargetFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListTransferable.java

Changeset: 152cf399f16f
Author:    serb
Date:      2013-12-11 22:17 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/152cf399f16f

8029045: Regression - Unsatisfied Link Error when the Java Access Bridge is started
Summary: Rename native function name; fix make to rebuild jni header file
Reviewed-by: erikj, tbell
Contributed-by: peter.brunet at oracle.com

! make/CompileJavaClasses.gmk

Changeset: 06c655658b89
Author:    serb
Date:      2013-12-12 16:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06c655658b89

8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren't equal
Reviewed-by: anthony, azvegint

! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java

Changeset: 78d395c7c479
Author:    lana
Date:      2013-12-12 20:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78d395c7c479

Merge

- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED
- test/com/sun/jmx/snmp/NoInfoLeakTest.java
- test/com/sun/tools/attach/AgentSetup.sh
- test/com/sun/tools/attach/ApplicationSetup.sh
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
- test/com/sun/tools/attach/PermissionTests.sh
- test/com/sun/tools/attach/ProviderTests.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh

Changeset: 20d504a20a87
Author:    azvegint
Date:      2013-12-13 14:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20d504a20a87

8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native GTK libraries"
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h

Changeset: c8ec5c070592
Author:    azvegint
Date:      2013-12-18 11:09 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8ec5c070592

8029263: user's default browser can not launch after we click the button, and there is an IOException shown in the log text (java.io.IOException)
Reviewed-by: anthony, serb

! src/solaris/classes/sun/awt/X11/XDesktopPeer.java
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c
! test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java

Changeset: 4ee27281d27d
Author:    lana
Date:      2013-12-19 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ee27281d27d

Merge


Changeset: a2339db970e0
Author:    lana
Date:      2013-12-19 10:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2339db970e0

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 2f31ddf65e74
Author:    lana
Date:      2013-12-23 14:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f31ddf65e74

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 71ce5e56ca60
Author:    lana
Date:      2013-12-25 10:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71ce5e56ca60

Merge




From lana.steuck at oracle.com  Wed Dec 25 20:15:37 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:37 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20131225201541.AAE3562F18@hg.openjdk.java.net>

Changeset: 7841feee13f5
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7841feee13f5

Added tag jdk8-b121 for changeset 32631eed0fad

! .hgtags

Changeset: 9d112a0e7df7
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9d112a0e7df7

Merge




From lana.steuck at oracle.com  Wed Dec 25 20:15:33 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:15:33 +0000
Subject: hg: jdk8/tl/hotspot: 12 new changesets
Message-ID: <20131225201618.A294A62F1C@hg.openjdk.java.net>

Changeset: 990e920dcec7
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/990e920dcec7

Added tag jdk8-b121 for changeset 5f07ec8bb982

! .hgtags

Changeset: 7469c9ca967a
Author:    amurillo
Date:      2013-12-13 09:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7469c9ca967a

8030062: new hotspot build - hs25-b64
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9ecf408d4568
Author:    iveresov
Date:      2013-12-12 11:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ecf408d4568

8029668: Kithcensink crashed with guarantee(Assembler::is_simm13(disp)) failed: Do not match large constant offsets
Summary: Bailout if we try to reference a stack location that we can't encode
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad

Changeset: 68ec0a75ee22
Author:    iignatyev
Date:      2013-12-13 00:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/68ec0a75ee22

8026941: [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric
Reviewed-by: kvn, vlivanov

! test/compiler/jsr292/ConcurrentClassLoadingTest.java

Changeset: 8beff993531a
Author:    iignatyev
Date:      2013-12-12 18:57 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8beff993531a

Merge


Changeset: 00bcb186fc5a
Author:    drchase
Date:      2013-12-12 15:11 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/00bcb186fc5a

8029351: assert(bt != T_OBJECT) failed: Guard is incorrect in VM:defmeth
Summary: replace test condition with reference to the proper predicate, encode folk wisdom into an assert
Reviewed-by: twisti, coleenp

! src/share/vm/oops/generateOopMap.cpp

Changeset: b00c6d846a0a
Author:    drchase
Date:      2013-12-12 18:00 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b00c6d846a0a

Merge


Changeset: ddcb2ac2900d
Author:    drchase
Date:      2013-12-12 20:55 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddcb2ac2900d

Merge


Changeset: 22c88c127fa4
Author:    roland
Date:      2013-12-13 09:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22c88c127fa4

8029383: assert(counter_changed) failed: failed dependencies, but counter didn't change
Summary: no call to SystemDictionary::notice_modification() when class is defined through Unsafe.defineAnonymousClass() can caused missed dependency change.
Reviewed-by: kvn, twisti

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: a632dd6ef1f9
Author:    anoll
Date:      2013-12-16 00:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a632dd6ef1f9

Merge


Changeset: 61ee6bab0763
Author:    amurillo
Date:      2013-12-20 08:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61ee6bab0763

Merge


Changeset: adcc814f792a
Author:    amurillo
Date:      2013-12-20 08:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/adcc814f792a

Added tag hs25-b64 for changeset 61ee6bab0763

! .hgtags



From lana.steuck at oracle.com  Thu Dec 26 20:12:06 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Thu, 26 Dec 2013 20:12:06 +0000
Subject: hg: jdk8/tl/jdk: 8029235: Update copyright year to match last edit in
	jdk8 jdk repository for 2013
Message-ID: <20131226201246.A474162F43@hg.openjdk.java.net>

Changeset: 1a3de3cdc684
Author:    lana
Date:      2013-12-26 12:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a3de3cdc684

8029235: Update copyright year to match last edit in jdk8 jdk repository for 2013
Summary: updated files with 2011, 2012 and 2013 years according to the file's last updated date
Reviewed-by: tbell, lancea, chegar

! make/BuildJdk.gmk
! make/Bundles.gmk
! make/CompileJavaClasses.gmk
! make/CompileLaunchers.gmk
! make/CopyIntoClasses.gmk
! make/CopySamples.gmk
! make/GenerateData.gmk
! make/Makefile
! make/data/characterdata/CharacterData00.java.template
! make/data/characterdata/CharacterData01.java.template
! make/data/characterdata/CharacterData02.java.template
! make/data/characterdata/CharacterData0E.java.template
! make/data/characterdata/CharacterDataLatin1.java.template
! make/data/characterdata/CharacterDataPrivateUse.java.template
! make/data/characterdata/CharacterDataUndefined.java.template
! make/data/charsetmapping/DoubleByte-X.java.template
! make/data/charsetmapping/SingleByte-X.java.template
! make/data/dtdbuilder/html32.dtd
! make/data/jdwp/jdwp.spec
! make/data/swingbeaninfo/SwingBeanInfo.template
! make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java
! make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java
! make/data/tzdata/gmt
! make/data/tzdata/jdk11_backward
! make/gendata/GendataFontConfig.gmk
! make/gendata/GendataHtml32dtd.gmk
! make/gensrc/GensrcBuffer.gmk
! make/gensrc/GensrcCLDR.gmk
! make/gensrc/GensrcCharacterData.gmk
! make/gensrc/GensrcCharsetCoder.gmk
! make/gensrc/GensrcCharsetMapping.gmk
! make/gensrc/GensrcExceptions.gmk
! make/gensrc/GensrcJDWP.gmk
! make/gensrc/GensrcJObjC.gmk
! make/gensrc/GensrcLocaleDataMetaInfo.gmk
! make/gensrc/GensrcMisc.gmk
! make/gensrc/GensrcProperties.gmk
! make/gensrc/GensrcSwing.gmk
! make/gensrc/GensrcX11Wrappers.gmk
! make/mapfiles/launchers/mapfile-sparc
! make/mapfiles/launchers/mapfile-sparcv9
! make/mapfiles/launchers/mapfile-x86
! make/mapfiles/launchers/mapfile-x86_64
! make/mapfiles/libattach/mapfile-linux
! make/mapfiles/libattach/mapfile-solaris
! make/mapfiles/libawt/mapfile-mawt-vers
! make/mapfiles/libawt/mapfile-vers
! make/mapfiles/libawt/mapfile-vers-linux
! make/mapfiles/libawt_headless/mapfile-vers
! make/mapfiles/libawt_xawt/mapfile-vers
! make/mapfiles/libdcpr/mapfile-vers
! make/mapfiles/libdt_socket/mapfile-vers
! make/mapfiles/libfontmanager/mapfile-vers
! make/mapfiles/libfontmanager/mapfile-vers.openjdk
! make/mapfiles/libhprof/mapfile-vers
! make/mapfiles/libinstrument/mapfile-vers
! make/mapfiles/libj2gss/mapfile-vers
! make/mapfiles/libj2pcsc/mapfile-vers
! make/mapfiles/libj2ucrypto/mapfile-vers
! make/mapfiles/libjaas/mapfile-vers
! make/mapfiles/libjava_crw_demo/mapfile-vers
! make/mapfiles/libjawt/mapfile-vers
! make/mapfiles/libjdga/mapfile-vers
! make/mapfiles/libjdwp/mapfile-vers
! make/mapfiles/libjli/mapfile-vers
! make/mapfiles/libjpeg/mapfile-vers
! make/mapfiles/libjpeg/mapfile-vers-closed
! make/mapfiles/libjsdt/mapfile-vers
! make/mapfiles/libjsound/mapfile-vers
! make/mapfiles/libjsoundalsa/mapfile-vers
! make/mapfiles/libkcms/mapfile-vers
! make/mapfiles/liblcms/mapfile-vers
! make/mapfiles/libmlib_image/mapfile-vers
! make/mapfiles/libnet/mapfile-vers
! make/mapfiles/libnio/mapfile-linux
! make/mapfiles/libnio/mapfile-macosx
! make/mapfiles/libnio/mapfile-solaris
! make/mapfiles/libnpt/mapfile-vers
! make/mapfiles/libsctp/mapfile-vers
! make/mapfiles/libsplashscreen/mapfile-vers
! make/mapfiles/libsunec/mapfile-vers
! make/mapfiles/libt2k/mapfile-vers
! make/mapfiles/libunpack/mapfile-vers
! make/mapfiles/libunpack/mapfile-vers-unpack200
! make/mapfiles/libverify/mapfile-vers
! make/mapfiles/libzip/mapfile-vers
! make/netbeans/common/architectures/arch-x86_64.properties
! make/netbeans/common/architectures/name-Macosx.properties
! make/netbeans/common/closed-share-sources.ent
! make/netbeans/common/demo-view.ent
! make/netbeans/common/make.xml
! make/netbeans/common/properties.ent
! make/netbeans/common/share-sources.ent
! make/netbeans/common/shared.xml
! make/netbeans/common/unix-sources.ent
! make/netbeans/common/windows-sources.ent
! make/netbeans/j2se/build.xml
! make/netbeans/jmx/build.properties
! make/non-build-utils/reorder/Makefile
! make/non-build-utils/reorder/tests/Exit.java
! make/non-build-utils/reorder/tests/Hello.java
! make/non-build-utils/reorder/tests/IntToString.java
! make/non-build-utils/reorder/tests/JHello.java
! make/non-build-utils/reorder/tests/LoadFrame.java
! make/non-build-utils/reorder/tests/LoadJFrame.java
! make/non-build-utils/reorder/tests/LoadToolkit.java
! make/non-build-utils/reorder/tests/Null.java
! make/non-build-utils/reorder/tests/Sleep.java
! make/non-build-utils/reorder/tools/Combine.java
! make/non-build-utils/reorder/tools/MaxTime.java
! make/non-build-utils/reorder/tools/mcount.c
! make/non-build-utils/reorder/tools/remove_mcount.c
! make/non-build-utils/sharing/tests/GHello.java
! make/non-build-utils/sharing/tests/Hello.java
! make/non-build-utils/sharing/tests/JHello.java
! make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java
! make/non-build-utils/src/build/tools/dirdiff/DirDiff.java
! make/src/classes/build/tools/addjsum/AddJsum.java
! make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java
! make/src/classes/build/tools/charsetmapping/DBCS.java
! make/src/classes/build/tools/charsetmapping/EUC_TW.java
! make/src/classes/build/tools/charsetmapping/HKSCS.java
! make/src/classes/build/tools/charsetmapping/JIS0213.java
! make/src/classes/build/tools/charsetmapping/Main.java
! make/src/classes/build/tools/charsetmapping/SBCS.java
! make/src/classes/build/tools/charsetmapping/Utils.java
! make/src/classes/build/tools/classfile/RemoveMethods.java
! make/src/classes/build/tools/cldrconverter/BundleGenerator.java
! make/src/classes/build/tools/cldrconverter/Container.java
! make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java
! make/src/classes/build/tools/cldrconverter/Entry.java
! make/src/classes/build/tools/cldrconverter/IgnoredContainer.java
! make/src/classes/build/tools/cldrconverter/KeyContainer.java
! make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java
! make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java
! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
! make/src/classes/build/tools/cldrconverter/StringArrayElement.java
! make/src/classes/build/tools/cldrconverter/StringArrayEntry.java
! make/src/classes/build/tools/cldrconverter/StringEntry.java
! make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java
! make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java
! make/src/classes/build/tools/compileproperties/CompileProperties.java
! make/src/classes/build/tools/dtdbuilder/DTDBuilder.java
! make/src/classes/build/tools/dtdbuilder/DTDInputStream.java
! make/src/classes/build/tools/dtdbuilder/DTDParser.java
! make/src/classes/build/tools/dtdbuilder/PublicMapping.java
! make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
! make/src/classes/build/tools/generatebreakiteratordata/CharSet.java
! make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java
! make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
! make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
! make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
! make/src/classes/build/tools/generatecharacter/GenerateCharacter.java
! make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java
! make/src/classes/build/tools/generatecharacter/PropList.java
! make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java
! make/src/classes/build/tools/generatecharacter/UnicodeSpec.java
! make/src/classes/build/tools/generatecharacter/Utility.java
! make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java
! make/src/classes/build/tools/generatenimbus/AbstractGradient.java
! make/src/classes/build/tools/generatenimbus/Border.java
! make/src/classes/build/tools/generatenimbus/Canvas.java
! make/src/classes/build/tools/generatenimbus/ComponentColor.java
! make/src/classes/build/tools/generatenimbus/Dimension.java
! make/src/classes/build/tools/generatenimbus/Ellipse.java
! make/src/classes/build/tools/generatenimbus/Generator.java
! make/src/classes/build/tools/generatenimbus/Gradient.java
! make/src/classes/build/tools/generatenimbus/GradientStop.java
! make/src/classes/build/tools/generatenimbus/Insets.java
! make/src/classes/build/tools/generatenimbus/Layer.java
! make/src/classes/build/tools/generatenimbus/Matte.java
! make/src/classes/build/tools/generatenimbus/ObjectFactory.java
! make/src/classes/build/tools/generatenimbus/Paint.java
! make/src/classes/build/tools/generatenimbus/PainterGenerator.java
! make/src/classes/build/tools/generatenimbus/Path.java
! make/src/classes/build/tools/generatenimbus/Point.java
! make/src/classes/build/tools/generatenimbus/RadialGradient.java
! make/src/classes/build/tools/generatenimbus/Rectangle.java
! make/src/classes/build/tools/generatenimbus/Shape.java
! make/src/classes/build/tools/generatenimbus/SynthModel.java
! make/src/classes/build/tools/generatenimbus/Typeface.java
! make/src/classes/build/tools/generatenimbus/UIColor.java
! make/src/classes/build/tools/generatenimbus/UIComponent.java
! make/src/classes/build/tools/generatenimbus/UIDefault.java
! make/src/classes/build/tools/generatenimbus/UIFont.java
! make/src/classes/build/tools/generatenimbus/UIIconRegion.java
! make/src/classes/build/tools/generatenimbus/UIProperty.java
! make/src/classes/build/tools/generatenimbus/UIRegion.java
! make/src/classes/build/tools/generatenimbus/UIState.java
! make/src/classes/build/tools/generatenimbus/UIStateType.java
! make/src/classes/build/tools/generatenimbus/UIStyle.java
! make/src/classes/build/tools/generatenimbus/Utils.java
! make/src/classes/build/tools/hasher/Hasher.java
! make/src/classes/build/tools/icondata/osxapp/ToBin.java
! make/src/classes/build/tools/jarreorder/JarReorder.java
! make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java
! make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java
! make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java
! make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java
! make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java
! make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java
! make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java
! make/src/classes/build/tools/jdwpgen/AltNode.java
! make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java
! make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java
! make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java
! make/src/classes/build/tools/jdwpgen/ByteTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ClassTypeNode.java
! make/src/classes/build/tools/jdwpgen/CommandNode.java
! make/src/classes/build/tools/jdwpgen/CommandSetNode.java
! make/src/classes/build/tools/jdwpgen/CommentNode.java
! make/src/classes/build/tools/jdwpgen/ConstantNode.java
! make/src/classes/build/tools/jdwpgen/ConstantSetNode.java
! make/src/classes/build/tools/jdwpgen/Context.java
! make/src/classes/build/tools/jdwpgen/ErrorNode.java
! make/src/classes/build/tools/jdwpgen/ErrorSetNode.java
! make/src/classes/build/tools/jdwpgen/EventNode.java
! make/src/classes/build/tools/jdwpgen/FieldTypeNode.java
! make/src/classes/build/tools/jdwpgen/FrameTypeNode.java
! make/src/classes/build/tools/jdwpgen/GroupNode.java
! make/src/classes/build/tools/jdwpgen/IntTypeNode.java
! make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java
! make/src/classes/build/tools/jdwpgen/LocationTypeNode.java
! make/src/classes/build/tools/jdwpgen/LongTypeNode.java
! make/src/classes/build/tools/jdwpgen/Main.java
! make/src/classes/build/tools/jdwpgen/MethodTypeNode.java
! make/src/classes/build/tools/jdwpgen/NameNode.java
! make/src/classes/build/tools/jdwpgen/NameValueNode.java
! make/src/classes/build/tools/jdwpgen/Node.java
! make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/OutNode.java
! make/src/classes/build/tools/jdwpgen/Parse.java
! make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java
! make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java
! make/src/classes/build/tools/jdwpgen/RepeatNode.java
! make/src/classes/build/tools/jdwpgen/ReplyNode.java
! make/src/classes/build/tools/jdwpgen/RootNode.java
! make/src/classes/build/tools/jdwpgen/SelectNode.java
! make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/StringTypeNode.java
! make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java
! make/src/classes/build/tools/jdwpgen/TypeNode.java
! make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java
! make/src/classes/build/tools/jdwpgen/ValueTypeNode.java
! make/src/classes/build/tools/spp/Spp.java
! make/src/classes/build/tools/stripproperties/StripProperties.java
! make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java
! make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java
! make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java
! make/src/native/add_gnu_debuglink/add_gnu_debuglink.c
! make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
! src/macosx/bin/java_md_macosx.c
! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m
! src/macosx/classes/apple/applescript/AppleScriptEngine.java
! src/macosx/classes/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/apple/laf/JRSUIControl.java
! src/macosx/classes/apple/laf/JRSUIFocus.java
! src/macosx/classes/apple/laf/JRSUIState.java
! src/macosx/classes/apple/laf/JRSUIStateFactory.java
! src/macosx/classes/apple/laf/JRSUIUtils.java
! src/macosx/classes/com/apple/eawt/AboutHandler.java
! src/macosx/classes/com/apple/eawt/AppEvent.java
! src/macosx/classes/com/apple/eawt/AppEventListener.java
! src/macosx/classes/com/apple/eawt/AppForegroundListener.java
! src/macosx/classes/com/apple/eawt/AppHiddenListener.java
! src/macosx/classes/com/apple/eawt/AppReOpenedListener.java
! src/macosx/classes/com/apple/eawt/Application.java
! src/macosx/classes/com/apple/eawt/ApplicationAdapter.java
! src/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java
! src/macosx/classes/com/apple/eawt/ApplicationEvent.java
! src/macosx/classes/com/apple/eawt/ApplicationListener.java
! src/macosx/classes/com/apple/eawt/FullScreenAdapter.java
! src/macosx/classes/com/apple/eawt/FullScreenListener.java
! src/macosx/classes/com/apple/eawt/FullScreenUtilities.java
! src/macosx/classes/com/apple/eawt/OpenFilesHandler.java
! src/macosx/classes/com/apple/eawt/OpenURIHandler.java
! src/macosx/classes/com/apple/eawt/PreferencesHandler.java
! src/macosx/classes/com/apple/eawt/PrintFilesHandler.java
! src/macosx/classes/com/apple/eawt/QuitHandler.java
! src/macosx/classes/com/apple/eawt/QuitResponse.java
! src/macosx/classes/com/apple/eawt/QuitStrategy.java
! src/macosx/classes/com/apple/eawt/ScreenSleepListener.java
! src/macosx/classes/com/apple/eawt/SystemSleepListener.java
! src/macosx/classes/com/apple/eawt/UserSessionListener.java
! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java
! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java
! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/macosx/classes/com/apple/eawt/_AppMiscHandlers.java
! src/macosx/classes/com/apple/eawt/event/GestureAdapter.java
! src/macosx/classes/com/apple/eawt/event/GestureEvent.java
! src/macosx/classes/com/apple/eawt/event/GestureListener.java
! src/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java
! src/macosx/classes/com/apple/eawt/event/GesturePhaseListener.java
! src/macosx/classes/com/apple/eawt/event/GestureUtilities.java
! src/macosx/classes/com/apple/eawt/event/MagnificationEvent.java
! src/macosx/classes/com/apple/eawt/event/MagnificationListener.java
! src/macosx/classes/com/apple/eawt/event/RotationEvent.java
! src/macosx/classes/com/apple/eawt/event/RotationListener.java
! src/macosx/classes/com/apple/eawt/event/SwipeEvent.java
! src/macosx/classes/com/apple/eawt/event/SwipeListener.java
! src/macosx/classes/com/apple/laf/AquaBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java
! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java
! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java
! src/macosx/classes/com/apple/laf/AquaButtonRadioUI.java
! src/macosx/classes/com/apple/laf/AquaButtonToggleUI.java
! src/macosx/classes/com/apple/laf/AquaButtonUI.java
! src/macosx/classes/com/apple/laf/AquaCaret.java
! src/macosx/classes/com/apple/laf/AquaComboBoxButton.java
! src/macosx/classes/com/apple/laf/AquaComboBoxPopup.java
! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java
! src/macosx/classes/com/apple/laf/AquaEditorPaneUI.java
! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/macosx/classes/com/apple/laf/AquaFileSystemModel.java
! src/macosx/classes/com/apple/laf/AquaFileView.java
! src/macosx/classes/com/apple/laf/AquaFocus.java
! src/macosx/classes/com/apple/laf/AquaFocusHandler.java
! src/macosx/classes/com/apple/laf/AquaFonts.java
! src/macosx/classes/com/apple/laf/AquaGroupBorder.java
! src/macosx/classes/com/apple/laf/AquaHighlighter.java
! src/macosx/classes/com/apple/laf/AquaIcon.java
! src/macosx/classes/com/apple/laf/AquaImageFactory.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameBorderMetrics.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameDockIconUI.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
! src/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java
! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java
! src/macosx/classes/com/apple/laf/AquaLabelUI.java
! src/macosx/classes/com/apple/laf/AquaListUI.java
! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/com/apple/laf/AquaMenuBarBorder.java
! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java
! src/macosx/classes/com/apple/laf/AquaMenuBorder.java
! src/macosx/classes/com/apple/laf/AquaMenuItemUI.java
! src/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/macosx/classes/com/apple/laf/AquaMenuUI.java
! src/macosx/classes/com/apple/laf/AquaMnemonicHandler.java
! src/macosx/classes/com/apple/laf/AquaNativeResources.java
! src/macosx/classes/com/apple/laf/AquaOptionPaneUI.java
! src/macosx/classes/com/apple/laf/AquaPanelUI.java
! src/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java
! src/macosx/classes/com/apple/laf/AquaPopupMenuUI.java
! src/macosx/classes/com/apple/laf/AquaProgressBarUI.java
! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java
! src/macosx/classes/com/apple/laf/AquaScrollBarUI.java
! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java
! src/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java
! src/macosx/classes/com/apple/laf/AquaSliderUI.java
! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java
! src/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java
! src/macosx/classes/com/apple/laf/AquaSplitPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java
! src/macosx/classes/com/apple/laf/AquaTableHeaderUI.java
! src/macosx/classes/com/apple/laf/AquaTableUI.java
! src/macosx/classes/com/apple/laf/AquaTextAreaUI.java
! src/macosx/classes/com/apple/laf/AquaTextFieldBorder.java
! src/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java
! src/macosx/classes/com/apple/laf/AquaTextFieldSearch.java
! src/macosx/classes/com/apple/laf/AquaTextFieldUI.java
! src/macosx/classes/com/apple/laf/AquaTextPaneUI.java
! src/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java
! src/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java
! src/macosx/classes/com/apple/laf/AquaToolBarUI.java
! src/macosx/classes/com/apple/laf/AquaToolTipUI.java
! src/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/macosx/classes/com/apple/laf/AquaUtilControlSize.java
! src/macosx/classes/com/apple/laf/ClientPropertyApplicator.java
! src/macosx/classes/com/apple/laf/ScreenMenuBar.java
! src/macosx/classes/com/apple/laf/ScreenMenuBarProvider.java
! src/macosx/classes/com/apple/laf/ScreenMenuItem.java
! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java
! src/macosx/classes/com/apple/laf/ScreenMenuItemUI.java
! src/macosx/classes/com/apple/laf/ScreenMenuPropertyHandler.java
! src/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java
! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java
! src/macosx/classes/com/apple/laf/resources/aqua.properties
! src/macosx/classes/com/apple/laf/resources/aqua_de.properties
! src/macosx/classes/com/apple/laf/resources/aqua_es.properties
! src/macosx/classes/com/apple/laf/resources/aqua_fr.properties
! src/macosx/classes/com/apple/laf/resources/aqua_it.properties
! src/macosx/classes/com/apple/laf/resources/aqua_ja.properties
! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties
! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties
! src/macosx/classes/com/apple/laf/resources/aqua_sv.properties
! src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
! src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
! src/macosx/classes/java/net/DefaultInterface.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/classes/sun/awt/CGraphicsConfig.java
! src/macosx/classes/sun/awt/FullScreenCapable.java
! src/macosx/classes/sun/awt/fontconfigs/macosx.fontconfig.properties
! src/macosx/classes/sun/font/CCharToGlyphMapper.java
! src/macosx/classes/sun/font/CFont.java
! src/macosx/classes/sun/font/CFontConfiguration.java
! src/macosx/classes/sun/font/CFontManager.java
! src/macosx/classes/sun/font/CStrikeDisposer.java
! src/macosx/classes/sun/java2d/BackBufferCapsProvider.java
! src/macosx/classes/sun/java2d/CRenderer.java
! src/macosx/classes/sun/java2d/CompositeCRenderer.java
! src/macosx/classes/sun/java2d/DataBufferNIOInt.java
! src/macosx/classes/sun/java2d/IntegerNIORaster.java
! src/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java
! src/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
! src/macosx/classes/sun/lwawt/PlatformComponent.java
! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java
! src/macosx/classes/sun/lwawt/macosx/CAccessible.java
! src/macosx/classes/sun/lwawt/macosx/CAccessibleText.java
! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java
! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java
! src/macosx/classes/sun/lwawt/macosx/CImage.java
! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java
! src/macosx/classes/sun/lwawt/macosx/CMenu.java
! src/macosx/classes/sun/lwawt/macosx/CMenuBar.java
! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java
! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java
! src/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPopupMenu.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDevice.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphics.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterGraphicsConfig.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterJobDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterPageDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterSurfaceData.java
! src/macosx/classes/sun/lwawt/macosx/CRobot.java
! src/macosx/classes/sun/lwawt/macosx/CSystemTray.java
! src/macosx/classes/sun/lwawt/macosx/CTextPipe.java
! src/macosx/classes/sun/lwawt/macosx/CThreading.java
! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java
! src/macosx/classes/sun/lwawt/macosx/NSPrintInfo.java
! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/macosx/native/com/apple/laf/AquaFileView.m
! src/macosx/native/com/apple/laf/AquaLookAndFeel.m
! src/macosx/native/com/apple/laf/AquaNativeResources.m
! src/macosx/native/com/apple/laf/JRSUIConstantSync.h
! src/macosx/native/com/apple/laf/JRSUIConstantSync.m
! src/macosx/native/com/apple/laf/JRSUIFocus.m
! src/macosx/native/com/apple/laf/ScreenMenu.h
! src/macosx/native/com/apple/laf/ScreenMenu.m
! src/macosx/native/com/apple/laf/ScreenPopupFactory.m
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiIn.c
! 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/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.h
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.cpp
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.h
! src/macosx/native/java/util/SCDynamicStoreConfig.m
! src/macosx/native/jobjc/src/core/native/SEL.m
! src/macosx/native/sun/awt/AWTSurfaceLayers.h
! src/macosx/native/sun/awt/AWTView.h
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/ApplicationDelegate.h
! src/macosx/native/sun/awt/ApplicationDelegate.m
! src/macosx/native/sun/awt/CClipboard.h
! src/macosx/native/sun/awt/CClipboard.m
! src/macosx/native/sun/awt/CCursorManager.m
! src/macosx/native/sun/awt/CDataTransferer.h
! src/macosx/native/sun/awt/CDataTransferer.m
! src/macosx/native/sun/awt/CDesktopPeer.m
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.h
! src/macosx/native/sun/awt/CDropTarget.m
! src/macosx/native/sun/awt/CDropTargetContextPeer.m
! src/macosx/native/sun/awt/CFRetainedResource.m
! src/macosx/native/sun/awt/CFileDialog.h
! src/macosx/native/sun/awt/CGraphicsConfig.m
! src/macosx/native/sun/awt/CGraphicsEnv.m
! src/macosx/native/sun/awt/CImage.m
! src/macosx/native/sun/awt/CInputMethod.m
! src/macosx/native/sun/awt/CMenu.h
! src/macosx/native/sun/awt/CMenu.m
! src/macosx/native/sun/awt/CMenuBar.h
! src/macosx/native/sun/awt/CMenuBar.m
! src/macosx/native/sun/awt/CMenuComponent.h
! src/macosx/native/sun/awt/CMenuComponent.m
! src/macosx/native/sun/awt/CMenuItem.h
! src/macosx/native/sun/awt/CPopupMenu.h
! src/macosx/native/sun/awt/CPopupMenu.m
! src/macosx/native/sun/awt/CPrinterJob.m
! src/macosx/native/sun/awt/CRobot.m
! src/macosx/native/sun/awt/CSystemColors.h
! src/macosx/native/sun/awt/CSystemColors.m
! src/macosx/native/sun/awt/CTextPipe.m
! src/macosx/native/sun/awt/CTrayIcon.h
! src/macosx/native/sun/awt/CTrayIcon.m
! src/macosx/native/sun/awt/CWrapper.h
! src/macosx/native/sun/awt/DnDUtilities.h
! src/macosx/native/sun/awt/DnDUtilities.m
! src/macosx/native/sun/awt/GeomUtilities.h
! src/macosx/native/sun/awt/GeomUtilities.m
! src/macosx/native/sun/awt/ImageSurfaceData.h
! src/macosx/native/sun/awt/ImageSurfaceData.m
! src/macosx/native/sun/awt/InitIDs.h
! src/macosx/native/sun/awt/InitIDs.m
! src/macosx/native/sun/awt/JavaAccessibilityAction.h
! src/macosx/native/sun/awt/JavaAccessibilityAction.m
! src/macosx/native/sun/awt/JavaAccessibilityUtilities.h
! src/macosx/native/sun/awt/JavaAccessibilityUtilities.m
! src/macosx/native/sun/awt/JavaComponentAccessibility.h
! src/macosx/native/sun/awt/JavaComponentAccessibility.m
! src/macosx/native/sun/awt/JavaTextAccessibility.h
! src/macosx/native/sun/awt/JavaTextAccessibility.m
! src/macosx/native/sun/awt/LWCToolkit.h
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/awt/OSVersion.h
! src/macosx/native/sun/awt/OSVersion.m
! src/macosx/native/sun/awt/PrintModel.h
! src/macosx/native/sun/awt/PrintModel.m
! src/macosx/native/sun/awt/PrinterSurfaceData.h
! src/macosx/native/sun/awt/PrinterSurfaceData.m
! src/macosx/native/sun/awt/PrinterView.h
! src/macosx/native/sun/awt/QuartzRenderer.m
! src/macosx/native/sun/awt/QuartzSurfaceData.h
! src/macosx/native/sun/awt/QuartzSurfaceData.m
! src/macosx/native/sun/awt/awt.m
! src/macosx/native/sun/awt/awt_DrawingSurface.m
! src/macosx/native/sun/awt/jawt.m
! src/macosx/native/sun/awt/splashscreen/splashscreen_config.h
! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
! src/macosx/native/sun/font/AWTFont.h
! src/macosx/native/sun/font/AWTFont.m
! src/macosx/native/sun/font/CCharToGlyphMapper.m
! src/macosx/native/sun/font/CGGlyphImages.h
! src/macosx/native/sun/font/CGGlyphOutlines.h
! src/macosx/native/sun/font/CGGlyphOutlines.m
! src/macosx/native/sun/font/CoreTextSupport.h
! src/macosx/native/sun/font/CoreTextSupport.m
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.h
! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h
! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m
! src/macosx/native/sun/java2d/opengl/J2D_GL/cglext.h
! src/macosx/native/sun/java2d/opengl/OGLFuncs_md.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m
! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! src/share/back/SDE.c
! src/share/back/ThreadGroupReferenceImpl.c
! src/share/back/commonRef.c
! src/share/back/eventFilter.c
! src/share/back/export/sys.h
! src/share/back/outStream.c
! src/share/back/transport.c
! src/share/back/util.c
! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java
! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java
! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java
! src/share/classes/com/sun/beans/decoder/CharElementHandler.java
! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java
! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java
! src/share/classes/com/sun/beans/decoder/ElementHandler.java
! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java
! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java
! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java
! src/share/classes/com/sun/beans/decoder/IntElementHandler.java
! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java
! src/share/classes/com/sun/beans/decoder/LongElementHandler.java
! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java
! src/share/classes/com/sun/beans/decoder/NewElementHandler.java
! src/share/classes/com/sun/beans/decoder/NullElementHandler.java
! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java
! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java
! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java
! src/share/classes/com/sun/beans/decoder/StringElementHandler.java
! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java
! src/share/classes/com/sun/beans/decoder/VarElementHandler.java
! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java
! src/share/classes/com/sun/beans/finder/Signature.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/share/classes/com/sun/crypto/provider/PCBC.java
! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java
! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java
! src/share/classes/com/sun/java/util/jar/pack/Code.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/jdi/AbsentInformationException.java
! src/share/classes/com/sun/jdi/Accessible.java
! src/share/classes/com/sun/jdi/ArrayReference.java
! src/share/classes/com/sun/jdi/ArrayType.java
! src/share/classes/com/sun/jdi/BooleanType.java
! src/share/classes/com/sun/jdi/BooleanValue.java
! src/share/classes/com/sun/jdi/Bootstrap.java
! src/share/classes/com/sun/jdi/ByteType.java
! src/share/classes/com/sun/jdi/ByteValue.java
! src/share/classes/com/sun/jdi/CharType.java
! src/share/classes/com/sun/jdi/CharValue.java
! src/share/classes/com/sun/jdi/ClassLoaderReference.java
! src/share/classes/com/sun/jdi/ClassNotLoadedException.java
! src/share/classes/com/sun/jdi/ClassNotPreparedException.java
! src/share/classes/com/sun/jdi/ClassObjectReference.java
! src/share/classes/com/sun/jdi/ClassType.java
! src/share/classes/com/sun/jdi/DoubleType.java
! src/share/classes/com/sun/jdi/DoubleValue.java
! src/share/classes/com/sun/jdi/Field.java
! src/share/classes/com/sun/jdi/FloatType.java
! src/share/classes/com/sun/jdi/FloatValue.java
! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java
! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java
! src/share/classes/com/sun/jdi/IntegerType.java
! src/share/classes/com/sun/jdi/IntegerValue.java
! src/share/classes/com/sun/jdi/InterfaceType.java
! src/share/classes/com/sun/jdi/InternalException.java
! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java
! src/share/classes/com/sun/jdi/InvalidLineNumberException.java
! src/share/classes/com/sun/jdi/InvalidStackFrameException.java
! src/share/classes/com/sun/jdi/InvalidTypeException.java
! src/share/classes/com/sun/jdi/InvocationException.java
! src/share/classes/com/sun/jdi/JDIPermission.java
! src/share/classes/com/sun/jdi/LocalVariable.java
! src/share/classes/com/sun/jdi/Locatable.java
! src/share/classes/com/sun/jdi/Location.java
! src/share/classes/com/sun/jdi/LongType.java
! src/share/classes/com/sun/jdi/LongValue.java
! src/share/classes/com/sun/jdi/Method.java
! src/share/classes/com/sun/jdi/Mirror.java
! src/share/classes/com/sun/jdi/MonitorInfo.java
! src/share/classes/com/sun/jdi/NativeMethodException.java
! src/share/classes/com/sun/jdi/ObjectCollectedException.java
! src/share/classes/com/sun/jdi/ObjectReference.java
! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java
! src/share/classes/com/sun/jdi/PrimitiveType.java
! src/share/classes/com/sun/jdi/PrimitiveValue.java
! src/share/classes/com/sun/jdi/ReferenceType.java
! src/share/classes/com/sun/jdi/ShortType.java
! src/share/classes/com/sun/jdi/ShortValue.java
! src/share/classes/com/sun/jdi/StackFrame.java
! src/share/classes/com/sun/jdi/StringReference.java
! src/share/classes/com/sun/jdi/ThreadGroupReference.java
! src/share/classes/com/sun/jdi/ThreadReference.java
! src/share/classes/com/sun/jdi/Type.java
! src/share/classes/com/sun/jdi/TypeComponent.java
! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java
! src/share/classes/com/sun/jdi/VMDisconnectedException.java
! src/share/classes/com/sun/jdi/VMMismatchException.java
! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java
! src/share/classes/com/sun/jdi/Value.java
! src/share/classes/com/sun/jdi/VirtualMachine.java
! src/share/classes/com/sun/jdi/VirtualMachineManager.java
! src/share/classes/com/sun/jdi/VoidType.java
! src/share/classes/com/sun/jdi/VoidValue.java
! src/share/classes/com/sun/jdi/connect/AttachingConnector.java
! src/share/classes/com/sun/jdi/connect/Connector.java
! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java
! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java
! src/share/classes/com/sun/jdi/connect/ListeningConnector.java
! src/share/classes/com/sun/jdi/connect/Transport.java
! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java
! src/share/classes/com/sun/jdi/connect/VMStartException.java
! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java
! src/share/classes/com/sun/jdi/connect/spi/Connection.java
! src/share/classes/com/sun/jdi/connect/spi/TransportService.java
! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java
! src/share/classes/com/sun/jdi/event/BreakpointEvent.java
! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java
! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java
! src/share/classes/com/sun/jdi/event/Event.java
! src/share/classes/com/sun/jdi/event/EventIterator.java
! src/share/classes/com/sun/jdi/event/EventQueue.java
! src/share/classes/com/sun/jdi/event/EventSet.java
! src/share/classes/com/sun/jdi/event/ExceptionEvent.java
! src/share/classes/com/sun/jdi/event/LocatableEvent.java
! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java
! src/share/classes/com/sun/jdi/event/MethodExitEvent.java
! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java
! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java
! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java
! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java
! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java
! src/share/classes/com/sun/jdi/event/StepEvent.java
! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java
! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java
! src/share/classes/com/sun/jdi/event/VMDeathEvent.java
! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java
! src/share/classes/com/sun/jdi/event/VMStartEvent.java
! src/share/classes/com/sun/jdi/event/WatchpointEvent.java
! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java
! src/share/classes/com/sun/jdi/request/BreakpointRequest.java
! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java
! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java
! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java
! src/share/classes/com/sun/jdi/request/EventRequest.java
! src/share/classes/com/sun/jdi/request/EventRequestManager.java
! src/share/classes/com/sun/jdi/request/ExceptionRequest.java
! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java
! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java
! src/share/classes/com/sun/jdi/request/MethodExitRequest.java
! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java
! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java
! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java
! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java
! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java
! src/share/classes/com/sun/jdi/request/StepRequest.java
! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java
! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java
! src/share/classes/com/sun/jdi/request/VMDeathRequest.java
! src/share/classes/com/sun/jdi/request/WatchpointRequest.java
! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java
! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java
! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java
! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java
! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java
! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java
! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
! src/share/classes/com/sun/jmx/snmp/Enumerated.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java
! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java
! src/share/classes/com/sun/jmx/snmp/SnmpString.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java
! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java
! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java
! src/share/classes/com/sun/jndi/dns/DnsContext.java
! src/share/classes/com/sun/jndi/ldap/BasicControl.java
! src/share/classes/com/sun/jndi/ldap/BerDecoder.java
! src/share/classes/com/sun/jndi/ldap/BerEncoder.java
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/Filter.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java
! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java
! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java
! src/share/classes/com/sun/management/GarbageCollectorMXBean.java
! src/share/classes/com/sun/management/GcInfo.java
! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/share/classes/com/sun/management/ThreadMXBean.java
! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java
! src/share/classes/com/sun/management/VMOption.java
! src/share/classes/com/sun/media/sound/FastSysexMessage.java
! src/share/classes/com/sun/media/sound/SunFileReader.java
! src/share/classes/com/sun/naming/internal/ResourceManager.java
! src/share/classes/com/sun/net/httpserver/Authenticator.java
! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
! src/share/classes/com/sun/net/httpserver/Filter.java
! src/share/classes/com/sun/net/httpserver/Headers.java
! src/share/classes/com/sun/net/httpserver/HttpContext.java
! src/share/classes/com/sun/net/httpserver/HttpExchange.java
! src/share/classes/com/sun/net/httpserver/HttpHandler.java
! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java
! src/share/classes/com/sun/net/httpserver/HttpServer.java
! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java
! src/share/classes/com/sun/net/httpserver/HttpsExchange.java
! src/share/classes/com/sun/net/httpserver/HttpsParameters.java
! src/share/classes/com/sun/net/httpserver/HttpsServer.java
! src/share/classes/com/sun/net/httpserver/package-info.java
! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java
! src/share/classes/com/sun/net/httpserver/spi/package-info.java
! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java
! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java
! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java
! src/share/classes/com/sun/nio/sctp/Association.java
! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java
! src/share/classes/com/sun/nio/sctp/HandlerResult.java
! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/Notification.java
! src/share/classes/com/sun/nio/sctp/NotificationHandler.java
! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java
! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java
! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java
! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java
! src/share/classes/com/sun/nio/sctp/package-info.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java
! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/BaseRow.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/package.html
! src/share/classes/com/sun/security/auth/LdapPrincipal.java
! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java
! src/share/classes/com/sun/security/auth/NTNumericCredential.java
! src/share/classes/com/sun/security/auth/NTSid.java
! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java
! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java
! src/share/classes/com/sun/security/auth/NTUserPrincipal.java
! src/share/classes/com/sun/security/auth/PrincipalComparator.java
! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java
! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java
! src/share/classes/com/sun/security/auth/SolarisPrincipal.java
! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java
! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java
! src/share/classes/com/sun/security/auth/UnixPrincipal.java
! src/share/classes/com/sun/security/auth/UserPrincipal.java
! src/share/classes/com/sun/security/auth/X500Principal.java
! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java
! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java
! src/share/classes/com/sun/security/auth/module/NTLoginModule.java
! src/share/classes/com/sun/security/auth/module/NTSystem.java
! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java
! src/share/classes/com/sun/security/auth/module/SolarisSystem.java
! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java
! src/share/classes/com/sun/security/auth/module/UnixSystem.java
! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java
! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java
! src/share/classes/com/sun/security/jgss/GSSUtil.java
! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java
! src/share/classes/com/sun/security/jgss/InquireType.java
! src/share/classes/com/sun/security/ntlm/Client.java
! src/share/classes/com/sun/security/ntlm/NTLM.java
! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
! src/share/classes/com/sun/tools/attach/AgentInitializationException.java
! src/share/classes/com/sun/tools/attach/AgentLoadException.java
! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java
! src/share/classes/com/sun/tools/attach/AttachPermission.java
! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java
! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java
! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java
! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java
! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java
! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java
! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java
! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html
! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java
! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java
! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java
! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/com/sun/tools/jdi/SDE.java
! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java
! src/share/classes/com/sun/tools/jdi/ThreadListener.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/com/sun/tools/script/shell/messages.properties
! src/share/classes/java/applet/Applet.java
! src/share/classes/java/applet/AppletStub.java
! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/AWTEventMulticaster.java
! src/share/classes/java/awt/AWTKeyStroke.java
! src/share/classes/java/awt/AWTPermission.java
! src/share/classes/java/awt/AttributeValue.java
! src/share/classes/java/awt/BorderLayout.java
! src/share/classes/java/awt/BufferCapabilities.java
! src/share/classes/java/awt/Button.java
! src/share/classes/java/awt/CardLayout.java
! src/share/classes/java/awt/Checkbox.java
! src/share/classes/java/awt/CheckboxGroup.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Color.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Event.java
! src/share/classes/java/awt/EventFilter.java
! src/share/classes/java/awt/FlowLayout.java
! src/share/classes/java/awt/FocusTraversalPolicy.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/FontMetrics.java
! src/share/classes/java/awt/Frame.java
! src/share/classes/java/awt/GradientPaintContext.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsConfiguration.java
! src/share/classes/java/awt/GraphicsEnvironment.java
! src/share/classes/java/awt/GridBagConstraints.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/GridLayout.java
! src/share/classes/java/awt/ImageCapabilities.java
! src/share/classes/java/awt/Insets.java
! src/share/classes/java/awt/JobAttributes.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/Label.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/LinearGradientPaintContext.java
! src/share/classes/java/awt/MediaTracker.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/MultipleGradientPaintContext.java
! src/share/classes/java/awt/PageAttributes.java
! src/share/classes/java/awt/Polygon.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/Rectangle.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/ScrollPane.java
! src/share/classes/java/awt/ScrollPaneAdjustable.java
! src/share/classes/java/awt/Scrollbar.java
! src/share/classes/java/awt/SequencedEvent.java
! src/share/classes/java/awt/Shape.java
! src/share/classes/java/awt/SplashScreen.java
! src/share/classes/java/awt/SystemTray.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/TexturePaintContext.java
! src/share/classes/java/awt/TrayIcon.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/java/awt/color/ICC_ColorSpace.java
! src/share/classes/java/awt/color/ICC_ProfileGray.java
! src/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/share/classes/java/awt/color/package.html
! src/share/classes/java/awt/datatransfer/Clipboard.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/FlavorMap.java
! src/share/classes/java/awt/datatransfer/MimeType.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/java/awt/datatransfer/Transferable.java
! src/share/classes/java/awt/datatransfer/package.html
! src/share/classes/java/awt/dnd/DnDEventMulticaster.java
! src/share/classes/java/awt/dnd/DragGestureEvent.java
! src/share/classes/java/awt/dnd/DragGestureListener.java
! src/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/share/classes/java/awt/dnd/DragSource.java
! src/share/classes/java/awt/dnd/DragSourceContext.java
! src/share/classes/java/awt/dnd/DragSourceDragEvent.java
! src/share/classes/java/awt/dnd/DragSourceDropEvent.java
! src/share/classes/java/awt/dnd/DragSourceEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/dnd/DropTargetDragEvent.java
! src/share/classes/java/awt/dnd/DropTargetDropEvent.java
! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/share/classes/java/awt/dnd/package.html
! src/share/classes/java/awt/doc-files/AWTThreadIssues.html
! src/share/classes/java/awt/doc-files/DesktopProperties.html
! src/share/classes/java/awt/doc-files/FocusSpec.html
! src/share/classes/java/awt/doc-files/Modality.html
! src/share/classes/java/awt/event/ActionListener.java
! src/share/classes/java/awt/event/ComponentAdapter.java
! src/share/classes/java/awt/event/ComponentListener.java
! src/share/classes/java/awt/event/ContainerAdapter.java
! src/share/classes/java/awt/event/ContainerEvent.java
! src/share/classes/java/awt/event/ContainerListener.java
! src/share/classes/java/awt/event/FocusAdapter.java
! src/share/classes/java/awt/event/FocusListener.java
! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/awt/event/InvocationEvent.java
! src/share/classes/java/awt/event/ItemEvent.java
! src/share/classes/java/awt/event/ItemListener.java
! src/share/classes/java/awt/event/KeyAdapter.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/java/awt/event/MouseAdapter.java
! src/share/classes/java/awt/event/MouseEvent.java
! src/share/classes/java/awt/event/MouseListener.java
! src/share/classes/java/awt/event/MouseMotionAdapter.java
! src/share/classes/java/awt/event/MouseMotionListener.java
! src/share/classes/java/awt/event/NativeLibLoader.java
! src/share/classes/java/awt/event/WindowAdapter.java
! src/share/classes/java/awt/event/WindowFocusListener.java
! src/share/classes/java/awt/event/WindowListener.java
! src/share/classes/java/awt/event/package.html
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/GlyphMetrics.java
! src/share/classes/java/awt/font/GlyphVector.java
! src/share/classes/java/awt/font/LineBreakMeasurer.java
! src/share/classes/java/awt/font/MultipleMaster.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/font/StyledParagraph.java
! src/share/classes/java/awt/font/TextAttribute.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/font/TextLine.java
! src/share/classes/java/awt/font/TextMeasurer.java
! src/share/classes/java/awt/font/TransformAttribute.java
! src/share/classes/java/awt/font/package.html
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/Arc2D.java
! src/share/classes/java/awt/geom/Dimension2D.java
! src/share/classes/java/awt/geom/FlatteningPathIterator.java
! src/share/classes/java/awt/geom/Line2D.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/geom/Point2D.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/geom/RectangularShape.java
! src/share/classes/java/awt/geom/package.html
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/java/awt/im/InputMethodHighlight.java
! src/share/classes/java/awt/im/InputMethodRequests.java
! src/share/classes/java/awt/image/BandedSampleModel.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorConvertOp.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/ComponentColorModel.java
! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageFilter.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/Kernel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/Raster.java
! src/share/classes/java/awt/image/SampleModel.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java
! src/share/classes/java/awt/image/package.html
! src/share/classes/java/awt/image/renderable/RenderableImage.java
! src/share/classes/java/awt/image/renderable/RenderableImageOp.java
! src/share/classes/java/awt/image/renderable/package.html
! src/share/classes/java/awt/package.html
! src/share/classes/java/awt/peer/CheckboxPeer.java
! src/share/classes/java/awt/peer/DesktopPeer.java
! src/share/classes/java/awt/peer/FramePeer.java
! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java
! src/share/classes/java/awt/peer/TextComponentPeer.java
! src/share/classes/java/awt/print/Book.java
! src/share/classes/java/awt/print/PrinterJob.java
! src/share/classes/java/awt/print/package.html
! src/share/classes/java/beans/BeanDescriptor.java
! src/share/classes/java/beans/Encoder.java
! src/share/classes/java/beans/FeatureDescriptor.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/NameGenerator.java
! src/share/classes/java/beans/PropertyEditorManager.java
! src/share/classes/java/beans/PropertyEditorSupport.java
! src/share/classes/java/beans/SimpleBeanInfo.java
! src/share/classes/java/beans/XMLEncoder.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java
! src/share/classes/java/io/BufferedWriter.java
! src/share/classes/java/io/ByteArrayInputStream.java
! src/share/classes/java/io/ByteArrayOutputStream.java
! src/share/classes/java/io/Console.java
! src/share/classes/java/io/DataOutput.java
! src/share/classes/java/io/EOFException.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/FileSystem.java
! src/share/classes/java/io/ObjectStreamConstants.java
! src/share/classes/java/io/PipedReader.java
! src/share/classes/java/io/PrintStream.java
! src/share/classes/java/io/PushbackInputStream.java
! src/share/classes/java/io/PushbackReader.java
! src/share/classes/java/io/Serializable.java
! src/share/classes/java/io/SerializablePermission.java
! src/share/classes/java/io/StringReader.java
! src/share/classes/java/lang/ArrayStoreException.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/ClassCastException.java
! src/share/classes/java/lang/ClassValue.java
! src/share/classes/java/lang/ConditionalSpecialCasing.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/ProcessBuilder.java
! src/share/classes/java/lang/RuntimePermission.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/StackTraceElement.java
! src/share/classes/java/lang/StringBuilder.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
! src/share/classes/java/lang/instrument/package.html
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/ConstantCallSite.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/LambdaForm.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/MutableCallSite.java
! src/share/classes/java/lang/invoke/Stable.java
! src/share/classes/java/lang/invoke/SwitchPoint.java
! src/share/classes/java/lang/invoke/package-info.java
! src/share/classes/java/lang/management/CompilationMXBean.java
! src/share/classes/java/lang/management/ManagementPermission.java
! src/share/classes/java/lang/management/package.html
! src/share/classes/java/lang/reflect/Array.java
! src/share/classes/java/lang/reflect/Member.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/java/lang/reflect/Type.java
! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/share/classes/java/net/Inet4AddressImpl.java
! src/share/classes/java/net/Inet6AddressImpl.java
! src/share/classes/java/net/SocketAddress.java
! src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/nio/Buffer.java
! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
! src/share/classes/java/nio/ByteOrder.java
! src/share/classes/java/nio/Direct-X-Buffer.java.template
! src/share/classes/java/nio/Heap-X-Buffer.java.template
! src/share/classes/java/nio/MappedByteBuffer.java
! src/share/classes/java/nio/StringCharBuffer.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/channels/AsynchronousByteChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/Channel.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/FileLock.java
! src/share/classes/java/nio/channels/MembershipKey.java
! src/share/classes/java/nio/channels/MulticastChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/Pipe.java
! src/share/classes/java/nio/channels/SelectableChannel.java
! src/share/classes/java/nio/channels/SelectionKey.java
! src/share/classes/java/nio/channels/Selector.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectionKey.java
! src/share/classes/java/nio/channels/spi/AbstractSelector.java
! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java
! src/share/classes/java/nio/channels/spi/SelectorProvider.java
! src/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/share/classes/java/nio/charset/CoderResult.java
! src/share/classes/java/nio/charset/CodingErrorAction.java
! src/share/classes/java/nio/charset/spi/CharsetProvider.java
! src/share/classes/java/nio/file/FileStore.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/FileSystems.java
! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/WatchEvent.java
! src/share/classes/java/nio/file/WatchService.java
! src/share/classes/java/nio/file/attribute/AclEntry.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/AttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java
! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileAttribute.java
! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java
! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/share/classes/java/nio/file/spi/FileSystemProvider.java
! src/share/classes/java/nio/package.html
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/sql/Array.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DataTruncation.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/DriverPropertyInfo.java
! src/share/classes/java/sql/SQLException.java
! src/share/classes/java/sql/SQLFeatureNotSupportedException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLNonTransientException.java
! src/share/classes/java/sql/SQLRecoverableException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java
! src/share/classes/java/sql/SQLTransientException.java
! src/share/classes/java/sql/SQLWarning.java
! src/share/classes/java/sql/Struct.java
! src/share/classes/java/sql/Time.java
! src/share/classes/java/sql/Timestamp.java
! src/share/classes/java/text/CharacterIterator.java
! src/share/classes/java/text/Collator.java
! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractMap.java
! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayPrefixHelpers.java
! src/share/classes/java/util/ArraysParallelSortHelpers.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/ConcurrentModificationException.java
! src/share/classes/java/util/Date.java
! src/share/classes/java/util/DualPivotQuicksort.java
! src/share/classes/java/util/EnumSet.java
! src/share/classes/java/util/Formattable.java
! src/share/classes/java/util/ListResourceBundle.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/LocaleISOData.java
! src/share/classes/java/util/MissingFormatWidthException.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/PropertyResourceBundle.java
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/TimerTask.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/function/ToIntBiFunction.java
! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
! src/share/classes/java/util/jar/Manifest.java
! src/share/classes/java/util/logging/ConsoleHandler.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/Level.java
! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/SimpleFormatter.java
! src/share/classes/java/util/logging/SocketHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
! src/share/classes/java/util/logging/XMLFormatter.java
! src/share/classes/java/util/prefs/Preferences.java
! src/share/classes/java/util/regex/UnicodeProp.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
! src/share/classes/java/util/zip/DeflaterInputStream.java
! src/share/classes/java/util/zip/DeflaterOutputStream.java
! src/share/classes/java/util/zip/GZIPOutputStream.java
! src/share/classes/java/util/zip/InflaterInputStream.java
! src/share/classes/java/util/zip/InflaterOutputStream.java
! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipConstants64.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/javax/accessibility/AccessibleAction.java
! src/share/classes/javax/accessibility/AccessibleContext.java
! src/share/classes/javax/accessibility/AccessibleText.java
! src/share/classes/javax/crypto/JceSecurityManager.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/crypto/spec/IvParameterSpec.java
! src/share/classes/javax/crypto/spec/PBEParameterSpec.java
! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java
! src/share/classes/javax/crypto/spec/SecretKeySpec.java
! src/share/classes/javax/imageio/IIOParam.java
! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/event/IIOReadProgressListener.java
! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java
! src/share/classes/javax/imageio/event/IIOReadWarningListener.java
! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java
! src/share/classes/javax/imageio/metadata/IIOMetadata.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/IIORegistry.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java
! src/share/classes/javax/management/AttributeList.java
! src/share/classes/javax/management/BadAttributeValueExpException.java
! src/share/classes/javax/management/BooleanValueExp.java
! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/DescriptorKey.java
! src/share/classes/javax/management/ImmutableDescriptor.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanNotificationInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/MBeanServerConnection.java
! src/share/classes/javax/management/MBeanServerFactory.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java
! src/share/classes/javax/management/MBeanServerNotification.java
! src/share/classes/javax/management/MBeanTrustPermission.java
! src/share/classes/javax/management/MXBean.java
! src/share/classes/javax/management/NumericValueExp.java
! src/share/classes/javax/management/ObjectName.java
! src/share/classes/javax/management/PersistentMBean.java
! src/share/classes/javax/management/Query.java
! src/share/classes/javax/management/StandardEmitterMBean.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/loading/MLetParser.java
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! src/share/classes/javax/management/monitor/Monitor.java
! src/share/classes/javax/management/monitor/package.html
! src/share/classes/javax/management/openmbean/ArrayType.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/CompositeType.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
! src/share/classes/javax/management/openmbean/SimpleType.java
! src/share/classes/javax/management/openmbean/TabularType.java
! src/share/classes/javax/management/package.html
! src/share/classes/javax/management/relation/Relation.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationServiceMBean.java
! src/share/classes/javax/management/relation/RelationSupport.java
! src/share/classes/javax/management/remote/JMXConnectionNotification.java
! src/share/classes/javax/management/remote/JMXConnector.java
! src/share/classes/javax/management/remote/JMXConnectorFactory.java
! src/share/classes/javax/management/remote/JMXConnectorProvider.java
! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java
! src/share/classes/javax/management/remote/JMXPrincipal.java
! src/share/classes/javax/management/remote/JMXServiceURL.java
! src/share/classes/javax/management/remote/NotificationResult.java
! src/share/classes/javax/management/remote/TargetedNotification.java
! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java
! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java
! src/share/classes/javax/management/remote/rmi/package.html
! src/share/classes/javax/naming/BinaryRefAddr.java
! src/share/classes/javax/naming/Binding.java
! src/share/classes/javax/naming/InsufficientResourcesException.java
! src/share/classes/javax/naming/directory/Attribute.java
! src/share/classes/javax/naming/ldap/InitialLdapContext.java
! src/share/classes/javax/naming/ldap/LdapName.java
! src/share/classes/javax/naming/ldap/PagedResultsControl.java
! src/share/classes/javax/naming/ldap/SortControl.java
! src/share/classes/javax/net/ssl/HttpsURLConnection.java
! src/share/classes/javax/net/ssl/SSLContextSpi.java
! src/share/classes/javax/net/ssl/SSLEngineResult.java
! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java
! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java
! src/share/classes/javax/net/ssl/SSLSession.java
! src/share/classes/javax/net/ssl/SSLSessionContext.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/print/CancelablePrintJob.java
! src/share/classes/javax/print/Doc.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDoc.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/package.html
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/JobStateReasons.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/MediaTray.java
! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
! src/share/classes/javax/print/attribute/standard/Sides.java
! src/share/classes/javax/print/attribute/standard/package.html
! src/share/classes/javax/print/event/package.html
! src/share/classes/javax/print/package.html
! src/share/classes/javax/script/AbstractScriptEngine.java
! src/share/classes/javax/script/CompiledScript.java
! src/share/classes/javax/script/ScriptEngine.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java
! src/share/classes/javax/smartcardio/CardChannel.java
! src/share/classes/javax/smartcardio/CardTerminal.java
! src/share/classes/javax/smartcardio/ResponseAPDU.java
! src/share/classes/javax/sound/midi/Soundbank.java
! src/share/classes/javax/sound/sampled/DataLine.java
! src/share/classes/javax/sound/sampled/ReverbType.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/JoinRowSet.java
! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java
! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java
! src/share/classes/javax/sql/rowset/spi/XmlReader.java
! src/share/classes/javax/sql/rowset/spi/XmlWriter.java
! src/share/classes/javax/swing/AbstractAction.java
! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/AbstractCellEditor.java
! src/share/classes/javax/swing/AbstractListModel.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/ActionMap.java
! src/share/classes/javax/swing/ActionPropertyChangeListener.java
! src/share/classes/javax/swing/ArrayTable.java
! src/share/classes/javax/swing/BorderFactory.java
! src/share/classes/javax/swing/BoundedRangeModel.java
! src/share/classes/javax/swing/Box.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/ButtonGroup.java
! src/share/classes/javax/swing/CellRendererPane.java
! src/share/classes/javax/swing/ClientPropertyKey.java
! src/share/classes/javax/swing/ComboBoxModel.java
! src/share/classes/javax/swing/ComponentInputMap.java
! src/share/classes/javax/swing/DefaultBoundedRangeModel.java
! src/share/classes/javax/swing/DefaultButtonModel.java
! src/share/classes/javax/swing/DefaultCellEditor.java
! src/share/classes/javax/swing/DefaultFocusManager.java
! src/share/classes/javax/swing/DefaultListCellRenderer.java
! src/share/classes/javax/swing/DefaultListModel.java
! src/share/classes/javax/swing/DefaultListSelectionModel.java
! src/share/classes/javax/swing/DefaultRowSorter.java
! src/share/classes/javax/swing/DefaultSingleSelectionModel.java
! src/share/classes/javax/swing/DesktopManager.java
! src/share/classes/javax/swing/FocusManager.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/ImageIcon.java
! src/share/classes/javax/swing/InputMap.java
! src/share/classes/javax/swing/InputVerifier.java
! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JButton.java
! src/share/classes/javax/swing/JCheckBox.java
! src/share/classes/javax/swing/JCheckBoxMenuItem.java
! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/JDesktopPane.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JEditorPane.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/JFormattedTextField.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JLayer.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JMenuBar.java
! src/share/classes/javax/swing/JMenuItem.java
! src/share/classes/javax/swing/JOptionPane.java
! src/share/classes/javax/swing/JPanel.java
! src/share/classes/javax/swing/JPasswordField.java
! src/share/classes/javax/swing/JProgressBar.java
! src/share/classes/javax/swing/JRadioButton.java
! src/share/classes/javax/swing/JRadioButtonMenuItem.java
! src/share/classes/javax/swing/JRootPane.java
! src/share/classes/javax/swing/JScrollBar.java
! src/share/classes/javax/swing/JScrollPane.java
! src/share/classes/javax/swing/JSeparator.java
! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/JSpinner.java
! src/share/classes/javax/swing/JSplitPane.java
! src/share/classes/javax/swing/JTabbedPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JTextArea.java
! src/share/classes/javax/swing/JTextField.java
! src/share/classes/javax/swing/JTextPane.java
! src/share/classes/javax/swing/JToggleButton.java
! src/share/classes/javax/swing/JToolBar.java
! src/share/classes/javax/swing/JToolTip.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/JViewport.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/KeyStroke.java
! src/share/classes/javax/swing/KeyboardManager.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/MenuSelectionManager.java
! src/share/classes/javax/swing/MutableComboBoxModel.java
! src/share/classes/javax/swing/OverlayLayout.java
! src/share/classes/javax/swing/Painter.java
! src/share/classes/javax/swing/Popup.java
! src/share/classes/javax/swing/PopupFactory.java
! src/share/classes/javax/swing/ProgressMonitor.java
! src/share/classes/javax/swing/ProgressMonitorInputStream.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/javax/swing/RootPaneContainer.java
! src/share/classes/javax/swing/RowFilter.java
! src/share/classes/javax/swing/ScrollPaneConstants.java
! src/share/classes/javax/swing/ScrollPaneLayout.java
! src/share/classes/javax/swing/SizeRequirements.java
! src/share/classes/javax/swing/SizeSequence.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/javax/swing/SpinnerDateModel.java
! src/share/classes/javax/swing/SpinnerListModel.java
! src/share/classes/javax/swing/SpinnerModel.java
! src/share/classes/javax/swing/SpinnerNumberModel.java
! src/share/classes/javax/swing/Spring.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingUtilities.java
! src/share/classes/javax/swing/Timer.java
! src/share/classes/javax/swing/TimerQueue.java
! src/share/classes/javax/swing/ToolTipManager.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIDefaults.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java
! src/share/classes/javax/swing/ViewportLayout.java
! src/share/classes/javax/swing/WindowConstants.java
! src/share/classes/javax/swing/border/AbstractBorder.java
! src/share/classes/javax/swing/border/BevelBorder.java
! src/share/classes/javax/swing/border/Border.java
! src/share/classes/javax/swing/border/CompoundBorder.java
! src/share/classes/javax/swing/border/EmptyBorder.java
! src/share/classes/javax/swing/border/EtchedBorder.java
! src/share/classes/javax/swing/border/LineBorder.java
! src/share/classes/javax/swing/border/MatteBorder.java
! src/share/classes/javax/swing/border/SoftBevelBorder.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/border/package.html
! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java
! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java
! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java
! src/share/classes/javax/swing/colorchooser/ColorPanel.java
! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java
! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java
! src/share/classes/javax/swing/colorchooser/package.html
! src/share/classes/javax/swing/event/AncestorEvent.java
! src/share/classes/javax/swing/event/CaretEvent.java
! src/share/classes/javax/swing/event/ChangeEvent.java
! src/share/classes/javax/swing/event/DocumentEvent.java
! src/share/classes/javax/swing/event/EventListenerList.java
! src/share/classes/javax/swing/event/HyperlinkEvent.java
! src/share/classes/javax/swing/event/InternalFrameAdapter.java
! src/share/classes/javax/swing/event/InternalFrameEvent.java
! src/share/classes/javax/swing/event/InternalFrameListener.java
! src/share/classes/javax/swing/event/ListDataEvent.java
! src/share/classes/javax/swing/event/ListSelectionEvent.java
! src/share/classes/javax/swing/event/MenuDragMouseEvent.java
! src/share/classes/javax/swing/event/MenuEvent.java
! src/share/classes/javax/swing/event/MenuKeyEvent.java
! src/share/classes/javax/swing/event/PopupMenuEvent.java
! src/share/classes/javax/swing/event/TableColumnModelEvent.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeExpansionEvent.java
! src/share/classes/javax/swing/event/TreeExpansionListener.java
! src/share/classes/javax/swing/event/TreeModelEvent.java
! src/share/classes/javax/swing/event/TreeModelListener.java
! src/share/classes/javax/swing/event/TreeSelectionEvent.java
! src/share/classes/javax/swing/event/TreeSelectionListener.java
! src/share/classes/javax/swing/event/TreeWillExpandListener.java
! src/share/classes/javax/swing/event/UndoableEditEvent.java
! src/share/classes/javax/swing/event/package.html
! src/share/classes/javax/swing/filechooser/FileFilter.java
! src/share/classes/javax/swing/filechooser/FileSystemView.java
! src/share/classes/javax/swing/filechooser/FileView.java
! src/share/classes/javax/swing/filechooser/package.html
! src/share/classes/javax/swing/package.html
! src/share/classes/javax/swing/plaf/BorderUIResource.java
! src/share/classes/javax/swing/plaf/ColorUIResource.java
! src/share/classes/javax/swing/plaf/ComboBoxUI.java
! src/share/classes/javax/swing/plaf/ComponentUI.java
! src/share/classes/javax/swing/plaf/DimensionUIResource.java
! src/share/classes/javax/swing/plaf/FontUIResource.java
! src/share/classes/javax/swing/plaf/IconUIResource.java
! src/share/classes/javax/swing/plaf/InsetsUIResource.java
! src/share/classes/javax/swing/plaf/LayerUI.java
! src/share/classes/javax/swing/plaf/TextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java
! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java
! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java
! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java
! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java
! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java
! src/share/classes/javax/swing/plaf/basic/BasicListUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java
! src/share/classes/javax/swing/plaf/basic/ComboPopup.java
! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java
! src/share/classes/javax/swing/plaf/basic/package.html
! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/share/classes/javax/swing/plaf/metal/MetalBorders.java
! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java
! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java
! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java
! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java
! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java
! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java
! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java
! src/share/classes/javax/swing/plaf/metal/package.html
! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java
! src/share/classes/javax/swing/plaf/multi/package.html
! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
! src/share/classes/javax/swing/plaf/nimbus/package.html
! src/share/classes/javax/swing/plaf/package.html
! src/share/classes/javax/swing/plaf/synth/Region.java
! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthListUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPainter.java
! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java
! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/share/classes/javax/swing/plaf/synth/package.html
! src/share/classes/javax/swing/table/AbstractTableModel.java
! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java
! src/share/classes/javax/swing/table/DefaultTableColumnModel.java
! src/share/classes/javax/swing/table/DefaultTableModel.java
! src/share/classes/javax/swing/table/JTableHeader.java
! src/share/classes/javax/swing/table/TableCellRenderer.java
! src/share/classes/javax/swing/table/TableColumn.java
! src/share/classes/javax/swing/table/TableColumnModel.java
! src/share/classes/javax/swing/table/TableModel.java
! src/share/classes/javax/swing/table/package.html
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/AbstractWriter.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/AttributeSet.java
! src/share/classes/javax/swing/text/BadLocationException.java
! src/share/classes/javax/swing/text/BoxView.java
! src/share/classes/javax/swing/text/Caret.java
! src/share/classes/javax/swing/text/ComponentView.java
! src/share/classes/javax/swing/text/CompositeView.java
! src/share/classes/javax/swing/text/DateFormatter.java
! src/share/classes/javax/swing/text/DefaultCaret.java
! src/share/classes/javax/swing/text/DefaultEditorKit.java
! src/share/classes/javax/swing/text/DefaultFormatter.java
! src/share/classes/javax/swing/text/DefaultFormatterFactory.java
! src/share/classes/javax/swing/text/DefaultHighlighter.java
! src/share/classes/javax/swing/text/DefaultStyledDocument.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/DocumentFilter.java
! src/share/classes/javax/swing/text/EditorKit.java
! src/share/classes/javax/swing/text/Element.java
! src/share/classes/javax/swing/text/ElementIterator.java
! src/share/classes/javax/swing/text/FieldView.java
! src/share/classes/javax/swing/text/GapContent.java
! src/share/classes/javax/swing/text/GapVector.java
! src/share/classes/javax/swing/text/GlyphPainter2.java
! src/share/classes/javax/swing/text/Highlighter.java
! src/share/classes/javax/swing/text/IconView.java
! src/share/classes/javax/swing/text/InternationalFormatter.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/MaskFormatter.java
! src/share/classes/javax/swing/text/NavigationFilter.java
! src/share/classes/javax/swing/text/NumberFormatter.java
! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/PasswordView.java
! src/share/classes/javax/swing/text/PlainDocument.java
! src/share/classes/javax/swing/text/PlainView.java
! src/share/classes/javax/swing/text/Position.java
! src/share/classes/javax/swing/text/StringContent.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/StyleContext.java
! src/share/classes/javax/swing/text/StyledDocument.java
! src/share/classes/javax/swing/text/StyledEditorKit.java
! src/share/classes/javax/swing/text/TabExpander.java
! src/share/classes/javax/swing/text/TabSet.java
! src/share/classes/javax/swing/text/TabStop.java
! src/share/classes/javax/swing/text/TabableView.java
! src/share/classes/javax/swing/text/TableView.java
! src/share/classes/javax/swing/text/TextAction.java
! src/share/classes/javax/swing/text/Utilities.java
! src/share/classes/javax/swing/text/WrappedPlainView.java
! src/share/classes/javax/swing/text/ZoneView.java
! src/share/classes/javax/swing/text/html/AccessibleHTML.java
! src/share/classes/javax/swing/text/html/BlockView.java
! src/share/classes/javax/swing/text/html/CSS.java
! src/share/classes/javax/swing/text/html/CSSParser.java
! src/share/classes/javax/swing/text/html/FormSubmitEvent.java
! src/share/classes/javax/swing/text/html/FormView.java
! src/share/classes/javax/swing/text/html/FrameSetView.java
! src/share/classes/javax/swing/text/html/HTML.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java
! src/share/classes/javax/swing/text/html/HTMLWriter.java
! src/share/classes/javax/swing/text/html/ImageView.java
! src/share/classes/javax/swing/text/html/InlineView.java
! src/share/classes/javax/swing/text/html/ObjectView.java
! src/share/classes/javax/swing/text/html/Option.java
! src/share/classes/javax/swing/text/html/OptionComboBoxModel.java
! src/share/classes/javax/swing/text/html/OptionListModel.java
! src/share/classes/javax/swing/text/html/ParagraphView.java
! src/share/classes/javax/swing/text/html/StyleSheet.java
! src/share/classes/javax/swing/text/html/TableView.java
! src/share/classes/javax/swing/text/html/package.html
! src/share/classes/javax/swing/text/html/parser/ContentModel.java
! src/share/classes/javax/swing/text/html/parser/DocumentParser.java
! src/share/classes/javax/swing/text/html/parser/Element.java
! src/share/classes/javax/swing/text/html/parser/package.html
! src/share/classes/javax/swing/text/package.html
! src/share/classes/javax/swing/text/rtf/RTFReader.java
! src/share/classes/javax/swing/text/rtf/package.html
! src/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java
! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java
! src/share/classes/javax/swing/tree/DefaultTreeModel.java
! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
! src/share/classes/javax/swing/tree/ExpandVetoException.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
! src/share/classes/javax/swing/tree/TreeCellRenderer.java
! src/share/classes/javax/swing/tree/TreeModel.java
! src/share/classes/javax/swing/tree/TreeNode.java
! src/share/classes/javax/swing/tree/TreePath.java
! src/share/classes/javax/swing/tree/TreeSelectionModel.java
! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java
! src/share/classes/javax/swing/tree/package.html
! src/share/classes/javax/swing/undo/CannotRedoException.java
! src/share/classes/javax/swing/undo/CannotUndoException.java
! src/share/classes/javax/swing/undo/UndoManager.java
! src/share/classes/javax/swing/undo/package.html
! src/share/classes/javax/xml/crypto/KeySelector.java
! src/share/classes/javax/xml/crypto/MarshalException.java
! src/share/classes/javax/xml/crypto/dsig/Manifest.java
! src/share/classes/javax/xml/crypto/dsig/TransformException.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java
! src/share/classes/jdk/internal/org/xml/sax/Attributes.java
! src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java
! src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java
! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java
! src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java
! src/share/classes/jdk/internal/org/xml/sax/InputSource.java
! src/share/classes/jdk/internal/org/xml/sax/Locator.java
! src/share/classes/jdk/internal/org/xml/sax/SAXException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java
! src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java
! src/share/classes/jdk/internal/org/xml/sax/XMLReader.java
! src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java
! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java
! src/share/classes/jdk/internal/util/xml/XMLStreamException.java
! src/share/classes/jdk/internal/util/xml/impl/Parser.java
! src/share/classes/org/ietf/jgss/GSSContext.java
! src/share/classes/org/ietf/jgss/GSSCredential.java
! src/share/classes/org/ietf/jgss/GSSException.java
! src/share/classes/org/ietf/jgss/GSSManager.java
! src/share/classes/org/ietf/jgss/GSSName.java
! src/share/classes/org/ietf/jgss/package.html
! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java
! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java
! src/share/classes/sun/applet/AppletClassLoader.java
! src/share/classes/sun/applet/AppletPanel.java
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/applet/AppletViewer.java
! src/share/classes/sun/applet/Main.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/awt/CausedFocusEvent.java
! src/share/classes/sun/awt/CharsetString.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/EventListenerAggregate.java
! src/share/classes/sun/awt/FontConfiguration.java
! src/share/classes/sun/awt/FontDescriptor.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/ModalityEvent.java
! src/share/classes/sun/awt/NativeLibLoader.java
! src/share/classes/sun/awt/NullComponentPeer.java
! src/share/classes/sun/awt/PaintEventDispatcher.java
! src/share/classes/sun/awt/PeerEvent.java
! src/share/classes/sun/awt/ScrollPaneWheelScroller.java
! src/share/classes/sun/awt/SunDisplayChanger.java
! src/share/classes/sun/awt/SunGraphicsCallback.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/UngrabEvent.java
! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/TransferableProxy.java
! src/share/classes/sun/awt/im/CompositionArea.java
! src/share/classes/sun/awt/im/CompositionAreaHandler.java
! src/share/classes/sun/awt/im/ExecutableInputMethodManager.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/awt/im/InputMethodContext.java
! src/share/classes/sun/awt/im/InputMethodJFrame.java
! src/share/classes/sun/awt/im/InputMethodManager.java
! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java
! src/share/classes/sun/awt/image/ByteBandedRaster.java
! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/ByteInterleavedRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/ImageRepresentation.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java
! src/share/classes/sun/awt/image/JPEGImageDecoder.java
! src/share/classes/sun/awt/image/NativeLibLoader.java
! src/share/classes/sun/awt/image/ShortBandedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/classes/sun/awt/image/ShortInterleavedRaster.java
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/awt/image/VolatileSurfaceManager.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/font/CMap.java
! src/share/classes/sun/font/CreatedFontTracker.java
! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/classes/sun/font/FileFont.java
! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManagerFactory.java
! src/share/classes/sun/font/FontManagerForSGE.java
! src/share/classes/sun/font/FreetypeFontScaler.java
! src/share/classes/sun/font/GlyphLayout.java
! src/share/classes/sun/font/GlyphList.java
! src/share/classes/sun/font/LayoutPathImpl.java
! src/share/classes/sun/font/StandardGlyphVector.java
! src/share/classes/sun/font/StandardTextSource.java
! src/share/classes/sun/font/StrikeCache.java
! src/share/classes/sun/font/SunFontManager.java
! src/share/classes/sun/font/TextLabelFactory.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/font/Type1Font.java
! src/share/classes/sun/instrument/InstrumentationImpl.java
! src/share/classes/sun/invoke/WrapperInstance.java
! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/invoke/util/VerifyType.java
! src/share/classes/sun/java2d/Disposer.java
! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/SurfaceDataProxy.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/PCMM.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/classes/sun/java2d/loops/Blit.java
! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java
! src/share/classes/sun/java2d/loops/MaskFill.java
! src/share/classes/sun/java2d/loops/ProcessPath.java
! src/share/classes/sun/java2d/loops/SurfaceType.java
! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java
! src/share/classes/sun/java2d/opengl/OGLDrawImage.java
! src/share/classes/sun/java2d/opengl/OGLPaints.java
! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java
! src/share/classes/sun/java2d/opengl/OGLRenderer.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java
! src/share/classes/sun/java2d/pipe/AAShapePipe.java
! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java
! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/GlyphListPipe.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java
! src/share/classes/sun/java2d/pipe/Region.java
! src/share/classes/sun/java2d/pipe/RegionIterator.java
! src/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java
! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/management/Agent.java
! src/share/classes/sun/management/AgentConfigurationError.java
! src/share/classes/sun/management/BaseOperatingSystemImpl.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/counter/perf/InstrumentationException.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/management/resources/agent_de.properties
! src/share/classes/sun/management/resources/agent_es.properties
! src/share/classes/sun/management/resources/agent_fr.properties
! src/share/classes/sun/management/resources/agent_it.properties
! src/share/classes/sun/management/resources/agent_ja.properties
! src/share/classes/sun/management/resources/agent_ko.properties
! src/share/classes/sun/management/resources/agent_pt_BR.properties
! src/share/classes/sun/management/resources/agent_sv.properties
! src/share/classes/sun/management/resources/agent_zh_CN.properties
! src/share/classes/sun/management/resources/agent_zh_TW.properties
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/misc/CRC16.java
! src/share/classes/sun/misc/CharacterDecoder.java
! src/share/classes/sun/misc/ClassFileTransformer.java
! src/share/classes/sun/misc/ExtensionDependency.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/PerfCounter.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/VM.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/misc/resources/Messages_de.java
! src/share/classes/sun/misc/resources/Messages_es.java
! src/share/classes/sun/misc/resources/Messages_fr.java
! src/share/classes/sun/misc/resources/Messages_it.java
! src/share/classes/sun/misc/resources/Messages_ja.java
! src/share/classes/sun/misc/resources/Messages_ko.java
! src/share/classes/sun/misc/resources/Messages_pt_BR.java
! src/share/classes/sun/misc/resources/Messages_sv.java
! src/share/classes/sun/misc/resources/Messages_zh_CN.java
! src/share/classes/sun/misc/resources/Messages_zh_TW.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/TelnetOutputStream.java
! src/share/classes/sun/net/ftp/FtpClient.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/ChunkedInputStream.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
! src/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/share/classes/sun/net/spi/DefaultProxySelector.java
! src/share/classes/sun/net/www/MessageHeader.java
! src/share/classes/sun/net/www/content/image/gif.java
! src/share/classes/sun/net/www/content/image/jpeg.java
! src/share/classes/sun/net/www/content/image/png.java
! src/share/classes/sun/net/www/content/image/x_xbitmap.java
! src/share/classes/sun/net/www/content/image/x_xpixmap.java
! src/share/classes/sun/net/www/http/ChunkedInputStream.java
! src/share/classes/sun/net/www/http/ChunkedOutputStream.java
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java
! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOStatus.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/ThreadPool.java
! src/share/classes/sun/nio/ch/Util.java
! src/share/classes/sun/nio/cs/UTF_8.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
! src/share/classes/sun/nio/cs/ext/HKSCS.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java
! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java
! src/share/classes/sun/nio/fs/Util.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PSPrinterJob.java
! src/share/classes/sun/print/PathGraphics.java
! src/share/classes/sun/print/PrintJob2D.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/print/ServiceDialog.java
! src/share/classes/sun/reflect/AccessorGenerator.java
! src/share/classes/sun/reflect/MethodAccessorGenerator.java
! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java
! src/share/classes/sun/reflect/generics/repository/ClassRepository.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
! src/share/classes/sun/reflect/misc/MethodUtil.java
! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/RemoteClass.java
! src/share/classes/sun/rmi/rmic/Util.java
! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java
! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/server/MarshalInputStream.java
! src/share/classes/sun/rmi/server/resources/rmid_de.properties
! src/share/classes/sun/rmi/server/resources/rmid_es.properties
! src/share/classes/sun/rmi/server/resources/rmid_fr.properties
! src/share/classes/sun/rmi/server/resources/rmid_it.properties
! src/share/classes/sun/rmi/server/resources/rmid_ja.properties
! src/share/classes/sun/rmi/server/resources/rmid_ko.properties
! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties
! src/share/classes/sun/rmi/server/resources/rmid_sv.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java
! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/security/ec/CurveDB.java
! src/share/classes/sun/security/ec/ECDHKeyAgreement.java
! src/share/classes/sun/security/ec/ECDSASignature.java
! src/share/classes/sun/security/ec/ECKeyPairGenerator.java
! src/share/classes/sun/security/ec/ECParameters.java
! src/share/classes/sun/security/ec/ECPublicKeyImpl.java
! src/share/classes/sun/security/ec/NamedCurve.java
! src/share/classes/sun/security/ec/SunECEntries.java
! src/share/classes/sun/security/jca/GetInstance.java
! src/share/classes/sun/security/jgss/GSSCaller.java
! src/share/classes/sun/security/jgss/GSSManagerImpl.java
! src/share/classes/sun/security/jgss/HttpCaller.java
! src/share/classes/sun/security/jgss/LoginConfigImpl.java
! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java
! src/share/classes/sun/security/jgss/krb5/InitialToken.java
! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/krb5/MessageToken.java
! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java
! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/classes/sun/security/krb5/EncryptedData.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/KrbApRep.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! src/share/classes/sun/security/krb5/internal/NetClient.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/share/classes/sun/security/krb5/internal/rcache/AuthList.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/pkcs10/PKCS10.java
! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11KeyStore.java
! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! src/share/classes/sun/security/provider/DSA.java
! src/share/classes/sun/security/provider/PolicyFile.java
! src/share/classes/sun/security/provider/X509Factory.java
! src/share/classes/sun/security/provider/certpath/AdjacencyList.java
! src/share/classes/sun/security/provider/certpath/CertPathHelper.java
! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java
! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java
! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
! src/share/classes/sun/security/ssl/AppInputStream.java
! src/share/classes/sun/security/ssl/ByteBufferInputStream.java
! src/share/classes/sun/security/ssl/CipherSuiteList.java
! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHCrypt.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/Krb5Proxy.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SessionId.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
! src/share/classes/sun/security/timestamp/TSRequest.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/jarsigner/Resources.java
! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java
! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java
! src/share/classes/sun/security/util/AuthResources_pt_BR.java
! src/share/classes/sun/security/util/AuthResources_zh_CN.java
! src/share/classes/sun/security/util/AuthResources_zh_TW.java
! src/share/classes/sun/security/util/DerIndefLenConverter.java
! src/share/classes/sun/security/util/ECKeySizeParameterSpec.java
! src/share/classes/sun/security/util/ECUtil.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
! src/share/classes/sun/security/util/Resources.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_TW.java
! src/share/classes/sun/security/util/SecurityConstants.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! src/share/classes/sun/security/x509/URIName.java
! src/share/classes/sun/swing/DefaultLayoutStyle.java
! src/share/classes/sun/swing/FilePane.java
! src/share/classes/sun/swing/PrintingStatus.java
! src/share/classes/sun/swing/SwingAccessor.java
! src/share/classes/sun/swing/SwingLazyValue.java
! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/share/classes/sun/swing/text/TextComponentPrintable.java
! src/share/classes/sun/text/bidi/BidiBase.java
! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java
! src/share/classes/sun/text/normalizer/UCharacter.java
! src/share/classes/sun/text/resources/th/CollationData_th.java
! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java
! src/share/classes/sun/tools/jar/JarException.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/Manifest.java
! src/share/classes/sun/tools/jar/SignatureFile.java
! src/share/classes/sun/tools/jar/resources/jar.properties
! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties
! src/share/classes/sun/tools/java/BinaryConstantPool.java
! src/share/classes/sun/tools/java/ClassDeclaration.java
! src/share/classes/sun/tools/java/MemberDefinition.java
! src/share/classes/sun/tools/java/RuntimeConstants.java
! src/share/classes/sun/tools/jconsole/AboutDialog.java
! src/share/classes/sun/tools/jconsole/BorderedComponent.java
! src/share/classes/sun/tools/jconsole/JConsole.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/share/classes/sun/tools/jconsole/SummaryTab.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/inspector/Utils.java
! src/share/classes/sun/tools/jconsole/inspector/XObject.java
! src/share/classes/sun/tools/jconsole/inspector/XTextField.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jps/Jps.java
! src/share/classes/sun/tools/jstack/JStack.java
! src/share/classes/sun/tools/jstat/ColumnFormat.java
! src/share/classes/sun/tools/jstat/RowClosure.java
! src/share/classes/sun/tools/jstat/resources/jstat_options
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java
! src/share/classes/sun/tools/serialver/SerialVer.java
! src/share/classes/sun/tools/tree/ExprExpression.java
! src/share/classes/sun/tools/tree/FieldExpression.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
! src/share/classes/sun/tracing/dtrace/DTraceProvider.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/locale/LanguageTag.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.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/CollatorProviderImpl.java
! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.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/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java
! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/resources/logging.properties
! src/share/classes/sun/util/logging/resources/logging_de.properties
! src/share/classes/sun/util/logging/resources/logging_es.properties
! src/share/classes/sun/util/logging/resources/logging_fr.properties
! src/share/classes/sun/util/logging/resources/logging_it.properties
! src/share/classes/sun/util/logging/resources/logging_ja.properties
! src/share/classes/sun/util/logging/resources/logging_ko.properties
! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
! src/share/classes/sun/util/logging/resources/logging_sv.properties
! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! 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/pt/TimeZoneNames_pt_BR.java
! 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/zh/CurrencyNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java
! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java
! 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/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
! src/share/demo/applets/MoleculeViewer/XYZApp.java
! src/share/demo/applets/WireFrame/ThreeD.java
! src/share/demo/java2d/J2DBench/build.xml
! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java
! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java
! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java
! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java
! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java
! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java
! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java
! src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java
! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java
! src/share/demo/jfc/Font2DTest/FontPanel.java
! src/share/demo/jfc/TableExample/TableExample4.java
! src/share/demo/jvmti/hprof/debug_malloc.c
! src/share/demo/jvmti/hprof/hprof_class.c
! src/share/demo/jvmti/hprof/hprof_event.c
! src/share/demo/jvmti/hprof/hprof_init.c
! src/share/demo/jvmti/hprof/hprof_md.h
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
! src/share/javavm/export/jawt.h
! src/share/lib/calendars.properties
! src/share/native/com/sun/media/sound/DirectAudioDevice.c
! src/share/native/com/sun/media/sound/Platform.c
! src/share/native/com/sun/media/sound/PlatformMidi.h
! src/share/native/com/sun/media/sound/SoundDefs.h
! src/share/native/com/sun/media/sound/Utilities.h
! src/share/native/java/lang/SecurityManager.c
! src/share/native/java/lang/System.c
! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c
! src/share/native/java/lang/java_props.h
! src/share/native/java/net/Inet4Address.c
! src/share/native/java/net/Inet6Address.c
! src/share/native/java/net/InetAddress.c
! src/share/native/java/net/net_util.c
! src/share/native/java/net/net_util.h
! src/share/native/java/util/zip/Inflater.c
! src/share/native/java/util/zip/ZipFile.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/java/util/zip/zip_util.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/awt/debug/debug_util.h
! src/share/native/sun/awt/image/BufImgSurfaceData.c
! src/share/native/sun/awt/image/DataBufferNative.c
! src/share/native/sun/awt/image/awt_ImageRep.c
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/image/awt_parseImage.h
! src/share/native/sun/awt/image/cvutils/img_dcm.h
! src/share/native/sun/awt/image/cvutils/img_dcm8.h
! src/share/native/sun/awt/image/cvutils/img_globals.c
! src/share/native/sun/awt/image/cvutils/img_replscale.h
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
! src/share/native/sun/awt/image/jpeg/jpegdecoder.c
! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageAffine.c
! src/share/native/sun/awt/medialib/mlib_ImageAffine.h
! src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c
! src/share/native/sun/awt/medialib/mlib_ImageColorTrue2Index.c
! src/share/native/sun/awt/medialib/mlib_ImageConv.h
! src/share/native/sun/awt/medialib/mlib_ImageConvMxN.c
! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_D64nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_F32nw.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c
! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c
! src/share/native/sun/awt/medialib/mlib_ImageCopy_Bit.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h
! src/share/native/sun/awt/medialib/mlib_image.h
! src/share/native/sun/awt/medialib/mlib_sys.c
! src/share/native/sun/awt/medialib/mlib_types.h
! src/share/native/sun/awt/medialib/safe_alloc.h
! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c
! src/share/native/sun/awt/splashscreen/splashscreen_gif.c
! src/share/native/sun/awt/splashscreen/splashscreen_impl.h
! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c
! src/share/native/sun/awt/splashscreen/splashscreen_png.c
! src/share/native/sun/font/AccelGlyphCache.c
! src/share/native/sun/font/DrawGlyphList.c
! src/share/native/sun/font/FontInstanceAdapter.cpp
! src/share/native/sun/font/FontInstanceAdapter.h
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/freetypeScaler.c
! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h
! src/share/native/sun/java2d/Disposer.c
! src/share/native/sun/java2d/SurfaceData.c
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! src/share/native/sun/java2d/loops/AnyByteBinary.h
! src/share/native/sun/java2d/loops/Blit.c
! src/share/native/sun/java2d/loops/BlitBg.c
! src/share/native/sun/java2d/loops/ByteIndexed.h
! src/share/native/sun/java2d/loops/DrawPath.c
! src/share/native/sun/java2d/loops/DrawPolygons.c
! src/share/native/sun/java2d/loops/FillPath.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c
! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/native/sun/java2d/loops/IntArgb.h
! src/share/native/sun/java2d/loops/IntArgbBm.h
! src/share/native/sun/java2d/loops/IntArgbPre.h
! src/share/native/sun/java2d/loops/MaskBlit.c
! src/share/native/sun/java2d/loops/MaskFill.c
! src/share/native/sun/java2d/loops/ProcessPath.c
! src/share/native/sun/java2d/loops/ScaledBlit.c
! src/share/native/sun/java2d/loops/TransformHelper.c
! src/share/native/sun/java2d/loops/Ushort4444Argb.h
! src/share/native/sun/java2d/loops/UshortIndexed.h
! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
! src/share/native/sun/java2d/opengl/OGLContext.c
! src/share/native/sun/java2d/opengl/OGLContext.h
! src/share/native/sun/java2d/opengl/OGLFuncs.h
! src/share/native/sun/java2d/opengl/OGLRenderQueue.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.h
! src/share/native/sun/java2d/opengl/OGLTextRenderer.c
! src/share/native/sun/java2d/opengl/OGLVertexCache.c
! src/share/native/sun/java2d/opengl/OGLVertexCache.h
! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c
! src/share/native/sun/java2d/pipe/Region.c
! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c
! src/share/native/sun/java2d/pipe/SpanClipRenderer.c
! src/share/native/sun/management/HotSpotDiagnostic.c
! src/share/native/sun/reflect/Reflection.c
! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/jgss/wrapper/NativeUtil.c
! src/share/native/sun/security/jgss/wrapper/gssapi.h
! src/share/native/sun/security/krb5/nativeccache.c
! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c
! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/npt/npt.h
! src/share/npt/utf.c
! src/share/sample/jmx/jmx-scandir/index.html
! src/share/sample/scripting/scriptpad/src/scripts/memory.sh
! src/share/transport/socket/socketTransport.c
! src/share/transport/socket/sysSocket.h
! src/solaris/back/linker_md.c
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/classes/java/net/DefaultInterface.java
! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/ListHelper.java
! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XChoicePeerListener.java
! src/solaris/classes/sun/awt/X11/XClipboard.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/solaris/classes/sun/awt/X11/XDesktopPeer.java
! src/solaris/classes/sun/awt/X11/XDialogPeer.java
! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java
! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XMSelection.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/XMenuWindow.java
! src/solaris/classes/sun/awt/X11/XPanelPeer.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XRepaintArea.java
! src/solaris/classes/sun/awt/X11/XRobotPeer.java
! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XlibWrapper.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h
! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/awt/X11GraphicsDevice.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties
! src/solaris/classes/sun/awt/motif/X11JIS0201.java
! src/solaris/classes/sun/awt/motif/X11JIS0208.java
! src/solaris/classes/sun/awt/motif/X11JIS0212.java
! src/solaris/classes/sun/font/DelegateStrike.java
! src/solaris/classes/sun/font/FontConfigManager.java
! src/solaris/classes/sun/font/NativeStrike.java
! src/solaris/classes/sun/font/XMap.java
! src/solaris/classes/sun/font/XRGlyphCacheEntry.java
! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/java2d/jules/TileTrapContainer.java
! src/solaris/classes/sun/java2d/x11/X11Renderer.java
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java
! src/solaris/classes/sun/java2d/xr/MaskTile.java
! src/solaris/classes/sun/java2d/xr/MaskTileManager.java
! src/solaris/classes/sun/java2d/xr/XRBackend.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRColor.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/classes/sun/java2d/xr/XRDrawImage.java
! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java
! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRPaints.java
! src/solaris/classes/sun/java2d/xr/XRRenderer.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/classes/sun/java2d/xr/XRUtils.java
! src/solaris/classes/sun/management/OperatingSystemImpl.java
! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EventPortWrapper.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/KQueue.java
! src/solaris/classes/sun/nio/ch/KQueuePort.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixCopyFile.java
! src/solaris/classes/sun/nio/fs/UnixException.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixMountEntry.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUriUtils.java
! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java
! src/solaris/classes/sun/print/AttributeClass.java
! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintJob.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! src/solaris/demo/jni/Poller/Poller.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/solaris/javavm/export/jni_md.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_CommonUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiIn.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiOut.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_MidiUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_PCMUtils.h
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h
! src/solaris/native/com/sun/security/auth/module/Solaris.c
! src/solaris/native/com/sun/security/auth/module/Unix.c
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/UNIXProcess_md.c
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/linux_close.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/sun/awt/CUPSfuncs.c
! src/solaris/native/sun/awt/VDrawingArea.c
! src/solaris/native/sun/awt/X11Color.c
! src/solaris/native/sun/awt/awt.h
! src/solaris/native/sun/awt/awt_AWTEvent.c
! src/solaris/native/sun/awt/awt_Component.h
! src/solaris/native/sun/awt/awt_Font.c
! src/solaris/native/sun/awt/awt_Font.h
! src/solaris/native/sun/awt/awt_LoadLibrary.c
! src/solaris/native/sun/awt/awt_Mlib.c
! src/solaris/native/sun/awt/awt_Mlib.h
! src/solaris/native/sun/awt/awt_Robot.c
! src/solaris/native/sun/awt/awt_UNIXToolkit.c
! src/solaris/native/sun/awt/awt_p.h
! src/solaris/native/sun/awt/canvas.h
! src/solaris/native/sun/awt/fontpath.c
! src/solaris/native/sun/awt/initIDs.c
! src/solaris/native/sun/awt/jawt.c
! src/solaris/native/sun/awt/multiVis.c
! src/solaris/native/sun/awt/multi_font.c
! src/solaris/native/sun/awt/multi_font.h
! src/solaris/native/sun/awt/robot_common.c
! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h
! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c
! src/solaris/native/sun/awt/swing_GTKEngine.c
! src/solaris/native/sun/font/X11FontScaler.c
! src/solaris/native/sun/font/X11TextRenderer.c
! src/solaris/native/sun/java2d/j2d_md.h
! src/solaris/native/sun/java2d/loops/mlib_ImageZoom_NN.c
! src/solaris/native/sun/java2d/loops/vis_FuncArray.c
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h
! src/solaris/native/sun/java2d/opengl/OGLFuncs_md.h
! src/solaris/native/sun/java2d/x11/X11Renderer.c
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
! src/solaris/native/sun/java2d/x11/XRSurfaceData.c
! src/solaris/native/sun/management/LinuxOperatingSystem.c
! src/solaris/native/sun/management/MacosxOperatingSystem.c
! src/solaris/native/sun/management/OperatingSystemImpl.c
! src/solaris/native/sun/management/SolarisOperatingSystem.c
! src/solaris/native/sun/nio/ch/Net.c
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
! src/solaris/native/sun/security/smartcardio/pcsc_md.c
! src/solaris/native/sun/xawt/XToolkit.c
! src/solaris/native/sun/xawt/XWindow.c
! src/solaris/transport/socket/socket_md.c
! src/windows/back/linker_md.c
! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java
! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java
! src/windows/classes/java/lang/ProcessImpl.java
! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java
! src/windows/classes/java/net/DefaultInterface.java
! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java
! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/classes/java/net/PlainSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java
! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
! src/windows/classes/sun/awt/windows/WBufferStrategy.java
! src/windows/classes/sun/awt/windows/WCanvasPeer.java
! src/windows/classes/sun/awt/windows/WClipboard.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
! src/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/windows/classes/sun/awt/windows/WDialogPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/windows/classes/sun/awt/windows/WFramePeer.java
! src/windows/classes/sun/awt/windows/WInputMethod.java
! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java
! src/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java
! src/windows/classes/sun/awt/windows/WPageDialog.java
! src/windows/classes/sun/awt/windows/WPageDialogPeer.java
! src/windows/classes/sun/awt/windows/WPathGraphics.java
! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialog.java
! src/windows/classes/sun/awt/windows/WPrinterJob.java
! src/windows/classes/sun/awt/windows/WRobotPeer.java
! src/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/classes/sun/awt/windows/fontconfig.properties
! src/windows/classes/sun/java2d/ScreenUpdateManager.java
! src/windows/classes/sun/java2d/d3d/D3DRenderer.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/windows/classes/sun/java2d/windows/GDIRenderer.java
! src/windows/classes/sun/management/OperatingSystemImpl.java
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/nio/ch/DatagramDispatcher.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/ch/FileKey.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/PipeImpl.java
! src/windows/classes/sun/nio/ch/PollArrayWrapper.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsFileCopy.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! src/windows/classes/sun/nio/fs/WindowsSecurity.java
! src/windows/classes/sun/nio/fs/WindowsWatchService.java
! src/windows/classes/sun/print/Win32MediaTray.java
! src/windows/classes/sun/print/Win32PrintJob.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java
! src/windows/demo/jvmti/hprof/hprof_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/java/io/Console_md.c
! src/windows/native/java/lang/ProcessImpl_md.c
! src/windows/native/java/lang/java_props_md.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/SocketInputStream.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/icmp.h
! src/windows/native/java/net/net_util_md.c
! src/windows/native/java/net/net_util_md.h
! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
! src/windows/native/sun/font/fontpath.c
! src/windows/native/sun/font/lcdglyph.c
! src/windows/native/sun/java2d/d3d/D3DBadHardware.h
! src/windows/native/sun/java2d/d3d/D3DPipeline.h
! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp
! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h
! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
! src/windows/native/sun/java2d/windows/GDIRenderer.cpp
! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp
! src/windows/native/sun/management/OperatingSystemImpl.c
! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c
! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c
! src/windows/native/sun/nio/ch/Net.c
! src/windows/native/sun/nio/ch/SocketChannelImpl.c
! src/windows/native/sun/nio/ch/SocketDispatcher.c
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c
! src/windows/native/sun/security/krb5/NativeCreds.c
! src/windows/native/sun/windows/CmdIDList.cpp
! src/windows/native/sun/windows/Devices.cpp
! src/windows/native/sun/windows/Devices.h
! src/windows/native/sun/windows/DllUtil.cpp
! src/windows/native/sun/windows/DllUtil.h
! src/windows/native/sun/windows/ObjectList.cpp
! src/windows/native/sun/windows/ObjectList.h
! src/windows/native/sun/windows/ShellFolder2.cpp
! src/windows/native/sun/windows/ThemeReader.cpp
! src/windows/native/sun/windows/WPrinterJob.cpp
! src/windows/native/sun/windows/alloc.h
! src/windows/native/sun/windows/awt.h
! src/windows/native/sun/windows/awt_BitmapUtil.cpp
! src/windows/native/sun/windows/awt_Button.cpp
! src/windows/native/sun/windows/awt_Checkbox.cpp
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Choice.h
! src/windows/native/sun/windows/awt_Clipboard.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_Debug.cpp
! src/windows/native/sun/windows/awt_Debug.h
! src/windows/native/sun/windows/awt_DesktopProperties.cpp
! src/windows/native/sun/windows/awt_Dialog.h
! src/windows/native/sun/windows/awt_DnDDT.cpp
! src/windows/native/sun/windows/awt_Font.h
! src/windows/native/sun/windows/awt_Frame.h
! src/windows/native/sun/windows/awt_InputMethod.cpp
! src/windows/native/sun/windows/awt_InputTextInfor.cpp
! src/windows/native/sun/windows/awt_List.h
! src/windows/native/sun/windows/awt_Menu.cpp
! src/windows/native/sun/windows/awt_Menu.h
! src/windows/native/sun/windows/awt_MenuBar.cpp
! src/windows/native/sun/windows/awt_MenuBar.h
! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_MenuItem.h
! src/windows/native/sun/windows/awt_Mlib.cpp
! src/windows/native/sun/windows/awt_Mlib.h
! src/windows/native/sun/windows/awt_Object.cpp
! src/windows/native/sun/windows/awt_Object.h
! src/windows/native/sun/windows/awt_PopupMenu.cpp
! src/windows/native/sun/windows/awt_PopupMenu.h
! src/windows/native/sun/windows/awt_PrintControl.h
! src/windows/native/sun/windows/awt_PrintJob.cpp
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Robot.h
! src/windows/native/sun/windows/awt_ScrollPane.cpp
! src/windows/native/sun/windows/awt_TextArea.cpp
! src/windows/native/sun/windows/awt_TextArea.h
! src/windows/native/sun/windows/awt_TextComponent.cpp
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_TextField.cpp
! src/windows/native/sun/windows/awt_TextField.h
! src/windows/native/sun/windows/awt_Toolkit.h
! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp
! src/windows/native/sun/windows/awt_Window.h
! src/windows/native/sun/windows/awt_ole.cpp
! src/windows/native/sun/windows/awtmsg.h
! src/windows/native/sun/windows/stdhdrs.h
! src/windows/transport/socket/socket_md.c
! test/com/oracle/net/sanity.sh
! test/com/sun/jdi/ExceptionEvents.java
! test/com/sun/jdi/FilterNoMatch.java
! test/com/sun/jdi/JDIScaffold.java
! test/com/sun/jdi/MethodEntryExitEvents.java
! test/com/sun/jdi/MethodExitReturnValuesTest.java
! test/com/sun/jdi/NativeInstanceFilter.java
! test/com/sun/jdi/NoLaunchOptionTest.java
! test/com/sun/jdi/RepStep.java
! test/com/sun/jdi/TestScaffold.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java
! test/com/sun/jndi/cosnaming/CNNameParser.java
! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java
! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java
! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh
! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh
! test/com/sun/net/httpserver/Test9a.java
! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java
! test/com/sun/tools/attach/Application.java
! test/com/sun/tools/attach/RedefineAgent.java
! test/com/sun/tools/extcheck/TestExtcheckArgs.sh
! test/demo/jvmti/mtrace/TraceJFrame.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh
! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java
! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html
! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html
! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html
! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html
! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java
! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html
! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java
! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java
! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html
! test/java/awt/FileDialog/MultipleMode/MultipleMode.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java
! test/java/awt/Focus/6981400/Test1.java
! test/java/awt/Focus/6981400/Test2.java
! test/java/awt/Focus/6981400/Test3.java
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java
! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html
! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java
! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html
! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html
! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java
! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html
! test/java/awt/FontMetrics/StyledSpaceAdvance.java
! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java
! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html
! test/java/awt/Frame/ShownOnPack/ShownOnPack.html
! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java
! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java
! test/java/awt/Graphics/LineClipTest.java
! test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java
! test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java
! test/java/awt/GraphicsDevice/CloneConfigsTest.java
! 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
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html
! test/java/awt/List/SetFontTest/SetFontTest.html
! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/Menu/OpensWithNoGrab/OpensWithNoGrab.java
! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java
! test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java
! test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java
! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html
! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html
! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java
! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html
! test/java/awt/PrintJob/Text/stringwidth.sh
! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
! test/java/awt/Robot/ManualInstructions/ManualInstructions.java
! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java
! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html
! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java
! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html
! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java
! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java
! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
! test/java/awt/Window/Grab/GrabTest.java
! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java
! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java
! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java
! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html
! test/java/awt/dnd/Button2DragTest/Button2DragTest.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java
! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html
! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java
! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html
! test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java
! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java
! test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java
! test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java
! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html
! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html
! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java
! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html
! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html
! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java
! test/java/awt/im/4490692/bug4490692.html
! test/java/awt/im/4959409/bug4959409.html
! test/java/awt/im/JTextFieldTest.html
! test/java/awt/image/BufferedImage/TinyScale.java
! test/java/awt/image/GetSamplesTest.java
! test/java/awt/image/IncorrectSampleMaskTest.java
! test/java/awt/image/mlib/MlibOpsTest.java
! test/java/awt/print/PageFormat/PageFormatFromAttributes.java
! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java
! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java
! test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java
! test/java/awt/regtesthelpers/Util.java
! test/java/beans/Beans/6669869/TestDesignTime.java
! test/java/beans/Beans/6669869/TestGuiAvailable.java
! test/java/beans/EventHandler/Test6277266.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
! test/java/beans/Introspector/6380849/beans/FirstBean.java
! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java
! test/java/beans/Introspector/6380849/beans/SecondBean.java
! test/java/beans/Introspector/6380849/beans/ThirdBean.java
! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java
! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java
! test/java/beans/Introspector/6976577/test/Accessor.java
! test/java/beans/Introspector/7122138/pack/Sub.java
! test/java/beans/Introspector/7122138/pack/Super.java
! test/java/beans/Introspector/Test4683761.java
! test/java/beans/Introspector/Test6660539.java
! test/java/beans/Performance/Test7122740.java
! test/java/beans/Performance/Test7184799.java
! test/java/beans/XMLEncoder/6380849/Bean.java
! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java
! test/java/beans/XMLEncoder/AbstractTest.java
! test/java/beans/XMLEncoder/BeanValidator.java
! test/java/beans/XMLEncoder/Test4631471.java
! test/java/beans/XMLEncoder/Test4679556.java
! test/java/beans/XMLEncoder/java_awt_BorderLayout.java
! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java
! test/java/io/File/GetXSpace.sh
! test/java/io/FileInputStream/OpsAfterClose.java
! test/java/io/FileOutputStream/OpsAfterClose.java
! test/java/io/RandomAccessFile/OpsAfterClose.java
! test/java/io/Serializable/class/run.sh
! test/java/io/Serializable/evolution/AddedExternField/run.sh
! test/java/io/Serializable/evolution/RenamePackage/run.sh
! test/java/io/Serializable/maskSyntheticModifier/run.sh
! test/java/io/Serializable/packageAccess/run.sh
! test/java/io/Serializable/resolveClass/consTest/run.sh
! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java
! test/java/io/Serializable/resolveClass/deserializeButton/Test.java
! test/java/io/Serializable/resolveClass/deserializeButton/run.sh
! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java
! test/java/io/Serializable/subclass/run.sh
! test/java/io/Serializable/superclassDataLoss/run.sh
! test/java/io/Serializable/unnamedPackageSwitch/run.sh
! test/java/lang/CharSequence/DefaultTest.java
! test/java/lang/Class/forName/NonJavaNames.sh
! test/java/lang/Class/getEnclosingClass/build.sh
! test/java/lang/ClassLoader/Assert.sh
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
! test/java/lang/ClassLoader/getdotresource.sh
! test/java/lang/Double/ParseDouble.java
! test/java/lang/Float/ParseFloat.java
! test/java/lang/IntegralPrimitiveToString.java
! test/java/lang/Math/CubeRootTests.java
! test/java/lang/Math/ExactArithTests.java
! test/java/lang/Math/Expm1Tests.java
! test/java/lang/Math/HyperbolicTests.java
! test/java/lang/Math/Log10Tests.java
! test/java/lang/Math/Log1pTests.java
! test/java/lang/Math/Tests.java
! test/java/lang/PrimitiveSumMinMaxTest.java
! test/java/lang/String/Split.java
! test/java/lang/String/ToLowerCase.java
! test/java/lang/StringBuffer/BufferForwarding.java
! test/java/lang/StringBuffer/TestSynchronization.java
! test/java/lang/StringBuilder/BuilderForwarding.java
! test/java/lang/StringBuilder/Supplementary.java
! test/java/lang/System/MacEncoding/ExpectedEncoding.java
! test/java/lang/Thread/GenerifyStackTraces.java
! test/java/lang/Thread/ThreadStateTest.java
! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java
! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh
! test/java/lang/instrument/ManifestTest.sh
! test/java/lang/instrument/ParallelTransformerLoader.sh
! test/java/lang/instrument/RedefineClassWithNativeMethod.sh
! test/java/lang/instrument/RedefineMethodAddInvoke.sh
! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh
! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh
! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeDynamicPrintArgs.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/PrivateInvokeTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/java/lang/invoke/lambda/LUtils.java
! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
! test/java/lang/invoke/lambda/LambdaAccessControlTest.java
! test/java/lang/invoke/remote/RemoteExample.java
! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java
! test/java/lang/management/CompilationMXBean/Basic.java
! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java
! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
! test/java/lang/management/MemoryMXBean/MemoryTest.java
! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
! test/java/lang/management/RuntimeMXBean/UpTime.java
! test/java/lang/management/ThreadMXBean/LockedMonitors.java
! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java
! test/java/lang/management/ThreadMXBean/Locks.java
! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java
! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java
! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java
! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java
! test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java
! test/java/lang/ref/ReferenceEnqueuePending.java
! test/java/lang/reflect/Array/ExceedMaxDim.java
! test/java/lang/reflect/Generics/Probe.java
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/lang/reflect/Proxy/Basic1.java
! test/java/lang/reflect/Proxy/ClassRestrictions.java
! test/java/math/BigDecimal/CompareToTests.java
! test/java/math/BigDecimal/FloatDoubleValueTests.java
! test/java/math/BigDecimal/IntegralDivisionTests.java
! test/java/math/BigDecimal/StrippingZerosTest.java
! test/java/math/BigInteger/CompareToTests.java
! test/java/math/BigInteger/DivisionOverflow.java
! test/java/math/BigInteger/ExtremeShiftingTests.java
! test/java/net/Authenticator/B4933582.sh
! test/java/net/BindException/Test.java
! test/java/net/CookieHandler/CookieManagerTest.java
! test/java/net/CookieHandler/TestHttpCookie.java
! test/java/net/Inet6Address/serialize/Serialize.java
! test/java/net/InterfaceAddress/NetworkPrefixLength.java
! test/java/net/MulticastSocket/TestInterfaces.java
! test/java/net/NetworkInterface/Equals.java
! test/java/net/NetworkInterface/IndexTest.java
! test/java/net/NetworkInterface/Test.java
! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh
! test/java/net/Socket/LingerTest.java
! test/java/net/Socks/SocksProxyVersion.java
! test/java/net/URI/Test.java
! test/java/net/URL/HandlerLoop.java
! test/java/net/URL/Test.java
! test/java/net/URL/URIToURLTest.java
! test/java/net/URLClassLoader/closetest/CloseTest.java
! test/java/net/URLClassLoader/closetest/Common.java
! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java
! test/java/net/URLClassLoader/getresourceasstream/test.sh
! test/java/net/URLConnection/RequestPropertyValues.java
! test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
! test/java/net/URLPermission/nstest/SimpleNameService.java
! test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java
! test/java/net/ipv6tests/B6521014.java
! test/java/net/ipv6tests/BadIPv6Addresses.java
! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java
! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh
! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
! test/java/nio/channels/DatagramChannel/Connect.java
! test/java/nio/channels/DatagramChannel/ConnectedSend.java
! test/java/nio/channels/DatagramChannel/SendToUnresolved.java
! test/java/nio/channels/Pipe/PipeInterrupt.java
! test/java/nio/channels/Selector/LotsOfChannels.java
! test/java/nio/channels/Selector/SelectorLimit.java
! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
! test/java/nio/channels/SocketChannel/ShortWrite.java
! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh
! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java
! test/java/nio/file/Files/CheckPermissions.java
! test/java/nio/file/Files/delete_on_close.sh
! test/java/nio/file/Files/walkFileTree/CreateFileTree.java
! test/java/nio/file/Files/walkFileTree/MaxDepth.java
! test/java/nio/file/Files/walkFileTree/SkipSiblings.java
! test/java/nio/file/Files/walkFileTree/TerminateWalk.java
! test/java/nio/file/Files/walkFileTree/find.sh
! test/java/nio/file/WatchService/SensitivityModifier.java
! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java
! test/java/nio/file/attribute/FileTime/Basic.java
! test/java/rmi/MarshalledObject/compare/Compare.java
! test/java/rmi/MarshalledObject/compare/HashCode.java
! test/java/rmi/MarshalledObject/compare/NullReference.java
! test/java/rmi/Naming/DefaultRegistryPort.java
! test/java/rmi/Naming/LookupIPv6.java
! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java
! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java
! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java
! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java
! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java
! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java
! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java
! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java
! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh
! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java
! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java
! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java
! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java
! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java
! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java
! test/java/rmi/activation/Activatable/restartService/RestartService.java
! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java
! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java
! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java
! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java
! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java
! test/java/rmi/activation/CommandEnvironment/NullOptions.java
! test/java/rmi/activation/log/LogTest.java
! test/java/rmi/dgc/VMID/CheckVMID.java
! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java
! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java
! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java
! test/java/rmi/invalidName/InvalidName.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java
! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java
! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java
! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java
! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Installed.java
! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Property.java
! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java
! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java
! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java
! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java
! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java
! test/java/rmi/server/Unmarshal/PrimitiveClasses.java
! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java
! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java
! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java
! test/java/rmi/server/clientStackTrace/ClientStackTrace.java
! test/java/rmi/server/getRemoteClass/GetRemoteClass.java
! test/java/rmi/server/serverStackTrace/ServerStackTrace.java
! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java
! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java
! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java
! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java
! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
! test/java/security/Principal/Implies.java
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh
! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java
! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh
! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh
! test/java/security/cert/CertStore/NoLDAP.java
! test/java/security/cert/CertificateFactory/slowstream.sh
! test/java/security/cert/CertificateRevokedException/Basic.java
! test/java/security/cert/pkix/policyChanges/TestPolicy.java
! test/java/text/Bidi/BidiConformance.java
! test/java/text/Format/DecimalFormat/TieRoundingTest.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/util/TestFormatter.java
! test/java/util/Arrays/ParallelSorting.java
! test/java/util/Base64/TestBase64.java
! test/java/util/Base64/TestBase64Golden.java
! test/java/util/Calendar/GenericTimeZoneNamesTest.sh
! test/java/util/Calendar/NarrowNamesTest.sh
! test/java/util/Collection/CollectionDefaults.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collection/testlibrary/CollectionSupplier.java
! test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java
! test/java/util/Collection/testlibrary/ExtendsAbstractList.java
! test/java/util/Collection/testlibrary/ExtendsAbstractSet.java
! test/java/util/Collections/CheckedIdentityMap.java
! test/java/util/Collections/CheckedMapBash.java
! test/java/util/Collections/CheckedSetBash.java
! test/java/util/Collections/EmptyCollectionSerialization.java
! test/java/util/Collections/EmptyIterator.java
! test/java/util/Collections/ReverseOrder.java
! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/Basic.sh
! test/java/util/Formatter/BasicBigDecimal.java
! test/java/util/Formatter/BasicDouble.java
! test/java/util/Formatter/BasicDoubleObject.java
! test/java/util/Formatter/BasicFloat.java
! test/java/util/Formatter/BasicFloatObject.java
! test/java/util/Iterator/IteratorDefaults.java
! test/java/util/LinkedHashMap/Basic.java
! test/java/util/List/ListDefaults.java
! test/java/util/Locale/InternationalBAT.java
! test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
! test/java/util/Locale/tools/EquivMapsGenerator.java
! test/java/util/Map/BasicSerialization.java
! test/java/util/Map/Collisions.java
! test/java/util/Map/EntryComparators.java
! test/java/util/Map/LockStep.java
! test/java/util/NavigableMap/LockStep.java
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
! 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/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PriorityQueue/RemoveContains.java
! test/java/util/ResourceBundle/Bug6299235Test.sh
! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh
! test/java/util/ResourceBundle/ResourceBundleTest.java
! test/java/util/ServiceLoader/basic.sh
! test/java/util/TimeZone/Bug6912560.java
! test/java/util/TimeZone/CLDRDisplayNamesTest.java
! test/java/util/TimeZone/ListTimeZones.java
! test/java/util/TimeZone/OldIDMappingTest.java
! test/java/util/TimeZone/OldIDMappingTest.sh
! test/java/util/TimeZone/TzIDOldMapping.java
! test/java/util/TreeMap/Clone.java
! test/java/util/concurrent/Executors/PrivilegedCallables.java
! test/java/util/concurrent/FutureTask/Throw.java
! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
! test/java/util/concurrent/atomic/AtomicReferenceTest.java
! test/java/util/concurrent/locks/Lock/FlakyMutex.java
! test/java/util/function/BinaryOperator/BasicTest.java
! test/java/util/jar/TestExtra.java
! test/java/util/logging/CheckLockLocationTest.java
! test/java/util/logging/LoggerSupplierAPIsTest.java
! test/java/util/logging/ParentLoggersTest.java
! test/java/util/logging/Reflect.java
! test/java/util/prefs/AddNodeChangeListener.java
! test/java/util/prefs/CheckUserPrefFirst.java
! test/java/util/prefs/CheckUserPrefLater.java
! test/java/util/prefs/CommentsInXml.java
! test/java/util/prefs/ConflictInFlush.java
! test/java/util/prefs/ExportNode.java
! test/java/util/prefs/ExportSubtree.java
! test/java/util/prefs/RemoveReadOnlyNode.java
! test/java/util/prefs/RemoveUnregedListener.java
! test/java/util/regex/POSIX_Unicode.java
! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java
! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java
! test/java/util/zip/3GBZipFiles.sh
! test/java/util/zip/LargeZip.java
! test/java/util/zip/StoredCRC.java
! test/java/util/zip/TotalInOut.java
! test/java/util/zip/ZipFile/Assortment.java
! test/java/util/zip/ZipFile/FinalizeZipFile.java
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/imageio/plugins/gif/GIFPassListenerTest.java
! test/javax/imageio/plugins/gif/GifTransparencyTest.java
! test/javax/management/MBeanInfo/SerializationTest1.java
! test/javax/management/modelmbean/LoggingExceptionTest.java
! test/javax/management/monitor/CounterMonitorThresholdTest.java
! test/javax/management/monitor/NullAttributeValueTest.java
! test/javax/management/remote/mandatory/connection/AddressableTest.java
! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java
! test/javax/management/remote/mandatory/connection/CloseableTest.java
! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java
! test/javax/management/remote/mandatory/connection/ConnectionTest.java
! test/javax/management/remote/mandatory/connection/IIOPURLTest.java
! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java
! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java
! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java
! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java
! test/javax/management/remote/mandatory/loading/MissingClassTest.java
! test/javax/management/remote/mandatory/notif/DeadListenerTest.java
! test/javax/management/remote/mandatory/provider/ProviderTest.java
! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java
! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java
! test/javax/print/DialogMargins.java
! test/javax/print/StreamPrintingOrientation.java
! test/javax/print/applet/AppletPrintLookup.html
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
! test/javax/rmi/ssl/SocketFactoryTest.java
! test/javax/script/CauseExceptionTest.java
! test/javax/script/ExceptionTest.java
! test/javax/script/GetInterfaceTest.java
! test/javax/script/Helper.java
! test/javax/script/ProviderTest.sh
! test/javax/script/StringWriterPrintTest.java
! test/javax/script/Test5.java
! test/javax/script/Test6.java
! test/javax/script/UnescapedBracketRegExTest.java
! test/javax/script/VersionTest.java
! test/javax/security/auth/kerberos/KerberosTixDateTest.java
! test/javax/sound/midi/File/SMPTESequence.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java
! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java
! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java
! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/Controller.java
! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java
! test/javax/sound/midi/Gervill/SoftChannel/Mono.java
! test/javax/sound/midi/Gervill/SoftChannel/Mute.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java
! test/javax/sound/midi/Gervill/SoftChannel/Omni.java
! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java
! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftChannel/Solo.java
! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java
! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java
! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java
! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Close.java
! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
! test/javax/sound/midi/Gervill/SoftTuning/GetName.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java
! test/javax/sound/midi/Gervill/SoftTuning/Load1.java
! test/javax/sound/midi/Gervill/SoftTuning/Load2.java
! test/javax/sound/midi/Gervill/SoftTuning/Load4.java
! test/javax/sound/midi/Gervill/SoftTuning/Load5.java
! test/javax/sound/midi/Gervill/SoftTuning/Load6.java
! test/javax/sound/midi/Gervill/SoftTuning/Load7.java
! test/javax/sound/midi/Gervill/SoftTuning/Load8.java
! test/javax/sound/midi/Gervill/SoftTuning/Load9.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java
! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java
! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java
! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java
! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java
! test/javax/sound/sampled/Clip/ClipSetPos.java
! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java
! test/javax/sound/sampled/DirectAudio/bug6400879.java
! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java
! test/javax/sound/sampled/FileWriter/WriterCloseInput.java
! test/javax/swing/JCheckBox/4449413/bug4449413.html
! test/javax/swing/JColorChooser/Test4222508.html
! test/javax/swing/JColorChooser/Test4759306.html
! test/javax/swing/JColorChooser/Test4759934.html
! test/javax/swing/JColorChooser/Test4887836.html
! test/javax/swing/JColorChooser/Test6348456.html
! test/javax/swing/JColorChooser/Test6977726.html
! test/javax/swing/JComboBox/7082443/bug7082443.java
! test/javax/swing/JComponent/4337267/bug4337267.java
! test/javax/swing/JComponent/6683775/bug6683775.java
! test/javax/swing/JEditorPane/4492274/test.html
! test/javax/swing/JEditorPane/6917744/test.html
! test/javax/swing/JEditorPane/bug4714674.java
! test/javax/swing/JFileChooser/6570445/bug6570445.java
! test/javax/swing/JFileChooser/6698013/bug6698013.html
! test/javax/swing/JFileChooser/6698013/bug6698013.java
! test/javax/swing/JFileChooser/6798062/bug6798062.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.java
! test/javax/swing/JList/6462008/bug6462008.java
! test/javax/swing/JPopupMenu/4966112/bug4966112.java
! test/javax/swing/JPopupMenu/6694823/bug6694823.java
! test/javax/swing/JSlider/4987336/bug4987336.html
! test/javax/swing/JSlider/6524424/bug6524424.html
! test/javax/swing/JSlider/6587742/bug6587742.html
! test/javax/swing/JSlider/6742358/bug6742358.html
! test/javax/swing/JSplitPane/4885629/bug4885629.java
! test/javax/swing/JTabbedPane/4310381/bug4310381.html
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/8005019/bug8005019.java
! test/javax/swing/JTextArea/7049024/bug7049024.java
! test/javax/swing/JTree/4314199/bug4314199.html
! test/javax/swing/JTree/4908142/bug4908142.java
! test/javax/swing/JTree/6263446/bug6263446.java
! test/javax/swing/SpringLayout/4726194/bug4726194.java
! test/javax/swing/SwingUtilities/7170657/bug7170657.java
! test/javax/swing/border/Test4129681.html
! test/javax/swing/border/Test4243289.html
! test/javax/swing/border/Test4247606.html
! test/javax/swing/border/Test4252164.html
! test/javax/swing/border/Test4760089.html
! test/javax/swing/border/Test6910490.html
! test/javax/swing/border/Test7022041.java
! test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java
! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java
! test/javax/swing/text/html/TableView/7030332/bug7030332.html
! test/javax/swing/text/html/parser/Parser/7003777/bug7003777.java
! test/jdk/lambda/ArrayCtorRefTest.java
! test/jdk/lambda/FDTest.java
! test/jdk/lambda/LambdaTranslationCompoundSamTest.java
! test/jdk/lambda/LambdaTranslationInInterface.java
! test/jdk/lambda/LambdaTranslationTest1.java
! test/jdk/lambda/LambdaTranslationTest2.java
! test/jdk/lambda/MethodReferenceTestInnerDefault.java
! test/jdk/lambda/MethodReferenceTestInnerInstance.java
! test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java
! test/jdk/lambda/MethodReferenceTestInstance.java
! test/jdk/lambda/MethodReferenceTestInstanceMethod.java
! test/jdk/lambda/MethodReferenceTestKinds.java
! test/jdk/lambda/MethodReferenceTestNew.java
! test/jdk/lambda/MethodReferenceTestNewInner.java
! test/jdk/lambda/MethodReferenceTestSuper.java
! test/jdk/lambda/MethodReferenceTestSuperDefault.java
! test/jdk/lambda/MethodReferenceTestTypeConversion.java
! test/jdk/lambda/MethodReferenceTestVarArgs.java
! test/jdk/lambda/MethodReferenceTestVarArgsExt.java
! test/jdk/lambda/MethodReferenceTestVarArgsSuper.java
! test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java
! test/jdk/lambda/MethodReferenceTestVarArgsThis.java
! test/jdk/lambda/TestInnerCtorRef.java
! test/jdk/lambda/TestPrivateCtorRef.java
! test/jdk/lambda/separate/AttributeInjector.java
! test/jdk/lambda/separate/ClassFile.java
! test/jdk/lambda/separate/ClassFilePreprocessor.java
! test/jdk/lambda/separate/ClassToInterfaceConverter.java
! test/jdk/lambda/separate/Compiler.java
! test/jdk/lambda/separate/DirectedClassLoader.java
! test/jdk/lambda/separate/SourceModel.java
! test/jdk/lambda/separate/TestHarness.java
! test/jdk/lambda/shapegen/ClassCase.java
! test/jdk/lambda/shapegen/Hierarchy.java
! test/jdk/lambda/shapegen/HierarchyGenerator.java
! test/jdk/lambda/shapegen/Rule.java
! test/jdk/lambda/shapegen/RuleGroup.java
! test/jdk/lambda/shapegen/TTNode.java
! test/jdk/lambda/shapegen/TTParser.java
! test/jdk/lambda/shapegen/TTShape.java
! test/jdk/lambda/vm/DefaultMethodRegressionTests.java
! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java
! test/jdk/lambda/vm/StrictfpDefault.java
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/invoke/util/ValueConversionsTest.java
! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java
! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java
! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html
! test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java
! test/sun/java2d/cmm/ColorConvertOp/MTColConvTest.java
! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java
! test/sun/java2d/cmm/ProfileOp/SetDataTest.java
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh
! test/sun/jvmstat/testlibrary/JavaProcess.java
! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java
! test/sun/management/jdp/ClientConnection.java
! test/sun/management/jdp/JdpTestUtil.java
! test/sun/management/jdp/JdpTestUtilTest.java
! test/sun/management/jdp/JdpUnitTest.java
! test/sun/management/jdp/PacketTest.java
! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java
! test/sun/misc/Cleaner/ExitOnThrow.java
! test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java
! test/sun/misc/JavaLangAccess/NewUnsafeString.java
! test/sun/net/ftp/MarkResetTest.java
! test/sun/net/ftp/MarkResetTest.sh
! test/sun/net/sdp/sanity.sh
! test/sun/net/www/http/HttpClient/ProxyTest.java
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/protocol/file/DirPermissionDenied.sh
! test/sun/net/www/protocol/http/B6299712.java
! test/sun/net/www/protocol/http/ProxyTunnelServer.java
! test/sun/net/www/protocol/http/StackTraceTest.java
! test/sun/nio/cs/EUC_TW_OLD.java
! test/sun/nio/cs/TestIBMBugs.java
! test/sun/nio/cs/TestStringCoding.java
! test/sun/nio/cs/X11CNS11643.java
! test/sun/nio/cs/X11CNS11643P1.java
! test/sun/nio/cs/X11CNS11643P2.java
! test/sun/nio/cs/X11CNS11643P3.java
! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java
! test/sun/rmi/log/ReliableLog/SnapshotSize.java
! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java
! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh
! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh
! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java
! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java
! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java
! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
! test/sun/security/krb5/MicroTime.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/ServiceCredsCombination.java
! test/sun/security/krb5/auto/AcceptPermissions.java
! test/sun/security/krb5/auto/AcceptorSubKey.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/CleanState.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/CrossRealm.java
! test/sun/security/krb5/auto/DiffNameSameKey.java
! test/sun/security/krb5/auto/DupEtypes.java
! test/sun/security/krb5/auto/DynamicKeytab.java
! test/sun/security/krb5/auto/GSSUnbound.java
! test/sun/security/krb5/auto/HttpNegotiateServer.java
! test/sun/security/krb5/auto/KDC.java
! test/sun/security/krb5/auto/KeyTabCompat.java
! test/sun/security/krb5/auto/MoreKvno.java
! test/sun/security/krb5/auto/OneKDC.java
! test/sun/security/krb5/auto/ReplayCacheTest.java
! test/sun/security/krb5/auto/SaslUnbound.java
! test/sun/security/krb5/auto/TwoOrThree.java
! test/sun/security/krb5/auto/UnboundService.java
! test/sun/security/krb5/ccache/EmptyCC.java
! test/sun/security/krb5/config/dns.sh
! test/sun/security/krb5/etype/WeakCrypto.java
! test/sun/security/krb5/runNameEquals.sh
! test/sun/security/krb5/tools/ktcheck.sh
! test/sun/security/pkcs11/SecmodTest.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/provider/PolicyFile/Comparator.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java
! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java
! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java
! test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/checkusage.sh
! test/sun/security/tools/jarsigner/concise_jarsigner.sh
! test/sun/security/tools/jarsigner/crl.sh
! test/sun/security/tools/jarsigner/emptymanifest.sh
! test/sun/security/tools/jarsigner/newsize7.sh
! test/sun/security/tools/jarsigner/onlymanifest.sh
! test/sun/security/tools/jarsigner/passtype.sh
! test/sun/security/tools/jarsigner/samename.sh
! test/sun/security/tools/jarsigner/ts.sh
! test/sun/security/tools/keytool/AltProviderPath.sh
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/DummyProvider.java
! test/sun/security/tools/keytool/ListKeychainStore.sh
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/console.sh
! test/sun/security/tools/keytool/emptysubject.sh
! test/sun/security/tools/keytool/importreadall.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/readjar.sh
! test/sun/security/tools/keytool/selfissued.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/tools/keytool/trystore.sh
! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.sh
! test/sun/security/validator/certreplace.sh
! test/sun/security/validator/samedn.sh
! test/sun/security/x509/X509CRLImpl/Verify.java
! test/sun/security/x509/X509CertImpl/Verify.java
! test/sun/tools/jps/jps-V_2.sh
! test/sun/tools/jrunscript/CheckEngine.java
! test/sun/util/calendar/zi/BackEnd.java
! test/sun/util/calendar/zi/Checksum.java
! test/sun/util/calendar/zi/DayOfWeek.java
! test/sun/util/calendar/zi/Gen.java
! test/sun/util/calendar/zi/GenDoc.java
! test/sun/util/calendar/zi/Main.java
! test/sun/util/calendar/zi/Mappings.java
! test/sun/util/calendar/zi/Month.java
! test/sun/util/calendar/zi/Rule.java
! test/sun/util/calendar/zi/RuleDay.java
! test/sun/util/calendar/zi/RuleRec.java
! test/sun/util/calendar/zi/Simple.java
! test/sun/util/calendar/zi/TestZoneInfo310.java
! test/sun/util/calendar/zi/Time.java
! test/sun/util/calendar/zi/Timezone.java
! test/sun/util/calendar/zi/TzIDOldMapping.java
! test/sun/util/calendar/zi/Zone.java
! test/sun/util/calendar/zi/ZoneInfoFile.java
! test/sun/util/calendar/zi/ZoneInfoOld.java
! test/sun/util/calendar/zi/ZoneRec.java
! test/sun/util/calendar/zi/Zoneinfo.java
! test/sun/util/calendar/zi/tzdata/gmt
! test/sun/util/calendar/zi/tzdata/jdk11_backward
! test/sun/util/calendar/zi/tzdata_jdk/gmt
! test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward
! test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward
! test/sun/util/resources/Locale/Bug6275682.java
! test/sun/util/resources/TimeZone/Bug6317929.java
! test/tools/jar/ChangeDir.java
! test/tools/jar/JarEntryTime.java
! test/tools/pack200/NoBeans.java
! test/tools/pack200/Reflect.java



From brian.burkhalter at oracle.com  Thu Dec 26 22:35:36 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 26 Dec 2013 14:35:36 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG 
Message-ID: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>

This follows from the last two paragraphs of this message:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022736.html

The issue is https://bugs.openjdk.java.net/browse/JDK-8027595.

The change is to change "@ test" to "@test" in the affected test files

test/java/math/BigInteger/BitLengthOverflow.java
test/java/math/BigInteger/DivisionOverflow.java
test/java/math/BigInteger/DoubleValueOverflow.java
test/java/math/BigInteger/StringConstructorOverflow.java

for example

 /*
- * @ test
+ * @test

in all cases.

Thanks,

Brian


From joe.darcy at oracle.com  Thu Dec 26 22:50:48 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 26 Dec 2013 14:50:48 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in
	JTREG
In-Reply-To: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>
References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>
Message-ID: <52BCB2C8.50000@oracle.com>

Hi Brian,

Can you determine the minimum maximum memory needed to run these tests?

Thanks,

-Joe

On 12/26/2013 2:35 PM, Brian Burkhalter wrote:
> This follows from the last two paragraphs of this message:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022736.html
>
> The issue is https://bugs.openjdk.java.net/browse/JDK-8027595.
>
> The change is to change "@ test" to "@test" in the affected test files
>
> test/java/math/BigInteger/BitLengthOverflow.java
> test/java/math/BigInteger/DivisionOverflow.java
> test/java/math/BigInteger/DoubleValueOverflow.java
> test/java/math/BigInteger/StringConstructorOverflow.java
>
> for example
>
>   /*
> - * @ test
> + * @test
>
> in all cases.
>
> Thanks,
>
> Brian



From brian.burkhalter at oracle.com  Thu Dec 26 23:05:06 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 26 Dec 2013 15:05:06 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in
	JTREG
In-Reply-To: <52BCB2C8.50000@oracle.com>
References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>
	<52BCB2C8.50000@oracle.com>
Message-ID: <818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com>

Hi Joe,

I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:

jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger

Brian

On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:

> Can you determine the minimum maximum memory needed to run these tests?



From brian.burkhalter at oracle.com  Fri Dec 27 00:18:55 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 26 Dec 2013 16:18:55 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in
	JTREG
In-Reply-To: <818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com>
References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>
	<52BCB2C8.50000@oracle.com>
	<818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com>
Message-ID: <93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com>

The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError.

Brian

On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:

> I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
> 
> jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
> 
> On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
> 
>> Can you determine the minimum maximum memory needed to run these tests?



From joe.darcy at oracle.com  Fri Dec 27 00:30:16 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 26 Dec 2013 16:30:16 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in
	JTREG
In-Reply-To: <93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com>
References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>	<52BCB2C8.50000@oracle.com>	<818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com>
	<93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com>
Message-ID: <52BCCA18.4010604@oracle.com>

I believe Alan knows the memory requirement that are currently called 
out separately in some tests; I think we should know how -Xmx1175m 
compares to those numbers before these test changes go back.

-Joe

On 12/26/2013 04:18 PM, Brian Burkhalter wrote:
> The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError.
>
> Brian
>
> On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:
>
>> I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
>>
>> jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
>>
>> On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
>>
>>> Can you determine the minimum maximum memory needed to run these tests?



From brian.burkhalter at oracle.com  Fri Dec 27 00:34:11 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 26 Dec 2013 16:34:11 -0800
Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in
	JTREG
In-Reply-To: <52BCCA18.4010604@oracle.com>
References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com>	<52BCB2C8.50000@oracle.com>	<818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com>
	<93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com>
	<52BCCA18.4010604@oracle.com>
Message-ID: 

Sounds reasonable. There was previously mention of this getting in before b01 so I wanted to resurface it now.

Brian

On Dec 26, 2013, at 4:30 PM, Joe Darcy wrote:

> I believe Alan knows the memory requirement that are currently called out separately in some tests; I think we should know how -Xmx1175m compares to those numbers before these test changes go back.
> 
> -Joe
> 
> On 12/26/2013 04:18 PM, Brian Burkhalter wrote:
>> The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError.
>> 
>> Brian
>> 
>> On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:
>> 
>>> I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
>>> 
>>> jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
>>> 
>>> On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
>>> 
>>>> Can you determine the minimum maximum memory needed to run these tests?
> 



From brian.burkhalter at oracle.com  Fri Dec 27 22:04:12 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 27 Dec 2013 14:04:12 -0800
Subject: JDK 9 RFC on JDK-8029561: Optimization in Integer to string conversion
Message-ID: 

I performed some micro-benchmarking on my MacBookPro5,3 with respect to  https://bugs.openjdk.java.net/browse/JDK-8029561.

With this patch applied to JDK 9

--- a/src/share/classes/java/lang/Integer.java	Tue Dec 24 20:07:12 2013 -0800
+++ b/src/share/classes/java/lang/Integer.java	Fri Dec 27 13:45:28 2013 -0800
@@ -453,7 +453,11 @@
         // Fall thru to fast mode for smaller numbers
         // assert(i <= 65536, i);
         for (;;) {
-            q = (i * 52429) >>> (16+3);
+            // The value of z1 ends up being 52429*i
+            int z1 = (i << 3) + (i << 2);
+            z1 = (z1 << 4) + z1;
+            z1 = (z1 << 8) + z1 + i;
+            q = z1 >>> 19; // 19 = 16 + 3
             r = i - ((q << 3) + (q << 1));  // r = i-(q*10) ...
             buf [--charPos] = digits [r];
             i = q;

The performance of toString() over 100 random ints in the range [0,0xffff) was actually about 12% slower than without the patch applied.

Similarly, micro-benchmarks of

    int z1 = y*52429

versus

    int z1 = (y << 3) + (y << 2);
    z1 = (z1 << 4) + z1;
    z1 = (z1 << 8) + z1 + y;

showed the latter to be about 8% slower than the former.

The foregoing results suggest that the patch should be rejected and the issue resolved (as "Won't Fix").

Brian

From dl at cs.oswego.edu  Sat Dec 28 13:47:41 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 28 Dec 2013 08:47:41 -0500
Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc
Message-ID: <52BED67D.3050005@cs.oswego.edu>


There might have been some mis-communication about whether the
new @implSpec tag would be used in existing java.util.AbstractX
classes. I had assumed that it would be, and pulled out a few
javadoc overrides in java.util.concurrent classes that would
not be needed if @implSpec were used. With @implSpec, you do
not need to paste in the interface-level spec in an overridden
method just to suppress inclusion of (incorrect) doc comments
about the default implementation.

Is it too late to do this for JDK8? It is easy -- just add a line
with @implSpec for each defined method. AbstractMap diffs
below. (They could be tweaked to get rid of now-unnecessary
paragraph markup, but I don't think this would improve display.)

If this isn't done, then minimally we'd need to paste in
interface-level specs in ConcurrentHashMap.{size, isEmpty}
since the JDK8 javadocs as they stand are wrong. There
may be other cases as well.

...


diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java
--- a/src/share/classes/java/util/AbstractMap.java	Thu Nov 21 09:23:03 2013 -0800
+++ b/src/share/classes/java/util/AbstractMap.java	Sat Dec 28 08:33:42 2013 -0500
@@ -78,6 +78,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation returns entrySet().size().
       */
      public int size() {
@@ -87,6 +88,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation returns size() == 0.
       */
      public boolean isEmpty() {
@@ -96,6 +98,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation iterates over entrySet() searching
       * for an entry with the specified value.  If such an entry is found,
       * true is returned.  If the iteration terminates without
@@ -126,6 +129,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation iterates over entrySet() searching
       * for an entry with the specified key.  If such an entry is found,
       * true is returned.  If the iteration terminates without
@@ -157,6 +161,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation iterates over entrySet() searching
       * for an entry with the specified key.  If such an entry is found,
       * the entry's value is returned.  If the iteration terminates without
@@ -191,6 +196,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation always throws an
       * UnsupportedOperationException.
       *
@@ -206,6 +212,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation iterates over entrySet() searching for an
       * entry with the specified key.  If such an entry is found, its value is
       * obtained with its getValue operation, the entry is removed
@@ -255,6 +262,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation iterates over the specified map's
       * entrySet() collection, and calls this map's put
       * operation once for each entry returned by the iteration.
@@ -276,6 +284,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation calls entrySet().clear().
       *
       * 
        Note that this implementation throws an
@@ -302,6 +311,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation returns a set that subclasses {@link AbstractSet}.
       * The subclass's iterator method returns a "wrapper object" over this
       * map's entrySet() iterator.  The size method
@@ -358,6 +368,7 @@
      /**
       * {@inheritDoc}
       *
+     * @implSpec
       * 
        This implementation returns a collection that subclasses {@link
       * AbstractCollection}.  The subclass's iterator method returns a
       * "wrapper object" over this map's entrySet() iterator.
@@ -425,6 +436,7 @@
       * equals method works properly across different implementations
       * of the Map interface.
       *
+     * @implSpec
       * 
        This implementation first checks if the specified object is this map;
       * if so it returns true.  Then, it checks if the specified
       * object is a map whose size is identical to the size of this map; if
@@ -478,6 +490,7 @@
       * m1 and m2, as required by the general contract of
       * {@link Object#hashCode}.
       *
+     * @implSpec
       * 
        This implementation iterates over entrySet(), calling
       * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the
       * set, and adding up the results.


From Alan.Bateman at oracle.com  Mon Dec 30 09:49:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Dec 2013 09:49:22 +0000
Subject: Why do we need LinkOption.NOFOLLOW_LINKS on the target file in
	CopyMoveHelper.copyToForeignTarget?
In-Reply-To: 
References: 
Message-ID: <52C141A2.4040802@oracle.com>

On 23/12/2013 15:48, Volker Simonis wrote:
> Hi,
>
> while running the jdk/jtreg tests for our ppc-aix-port I found a
> problem for the demo/zipfs/basic.sh test on AIX:
>
> Exception in thread "main" java.io.IOException: NOFOLLOW_LINKS is not
> supported on this platform
>      at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:773)
>      at sun.nio.fs.UnixFileAttributeViews$Basic.setTimes(UnixFileAttributeViews.java:74)
>      at java.nio.file.CopyMoveHelper.copyToForeignTarget(CopyMoveHelper.java:135)
>      at java.nio.file.CopyMoveHelper.moveToForeignTarget(CopyMoveHelper.java:157)
>      at java.nio.file.Files.move(Files.java:1395)
>      at ZipFSTester.test1(ZipFSTester.java:141)
>      at ZipFSTester.main(ZipFSTester.java:50)
>
> :
>
> However, I don't think that we need to set the
> LinkOption.NOFOLLOW_LINKS option when calling
> Files.getFileAttributeView() on the target file, because the target
> file can not be a symbolic link anyway
You're right, it's not needed here and can be removed.

-Alan


From snazy at gmx.de  Sun Dec 15 10:29:48 2013
From: snazy at gmx.de (Robert Stupp)
Date: Sun, 15 Dec 2013 10:29:48 -0000
Subject: ObjectIn/OutputStream improvements
Message-ID: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>

Hi,

I digged through the object serialization code and found some lines that could be optimized to reduce the number of calls to System.arraycopy() and temporary object allocations especially during string (de)serialization.
In short sentences the changes are:
ObjectInputStream:
- skip primitive/object reading if no primitive/objects in class (defaultReadFields method)
- use shared StringBuilder for string reading (prevent superfluous object allocations of one StingBuilder and one implicit char[] for each string being deserialized)
ObjectOutputStream:
- skip primitive/object writing if no primitive/objects in class (defaultWriteFields method)
- use unsafe access to calculate UTF-length
- use unsafe access in readBytes() and writeChars() methods to access String value field
- removed cbuf field
ObjectStreamClass/ObjectStreamField:
- minor improvement in getClassSignature ; share method code with ObjectStreamField (return constant string for primitives)

I have tested the changes in a big Java installation at a customer (backported the Java8 ObjectIn/OutputStream including the changes to Java6) and a long running real application performance test resulted in reduced CPU usage (from about 60% per server to 50%).
The changes I made in openjdk8 pass all tests.

Since I have no experience how to contribute code to openjdk in form of a push/changeset I have added the diff (hg export -g) to this email.

Robert




From snazy at gmx.de  Sun Dec 15 10:34:07 2013
From: snazy at gmx.de (Robert Stupp)
Date: Sun, 15 Dec 2013 10:34:07 -0000
Subject: Optimization in collections API
Message-ID: 

Hello,

many real business applications make intensive use of the collections api. I have spend some time and tried to improve it a bit:
I've added a shared empty array instances to java.util.Arrays and use Arrays.EMPTY_OBJECT_ARRAY where appropriate in collection classes and reduce use of new java.util.Iterator instances where possible

The changes pass the existing tests in openjdk8 build (make test).

Robert



From anthony.scarpino at oracle.com  Wed Dec  4 19:00:30 2013
From: anthony.scarpino at oracle.com (anthony.scarpino at oracle.com)
Date: Wed, 04 Dec 2013 19:00:30 -0000
Subject: hg: jdk8/tl/jdk: 8027218: TEST_BUG: sun/security/pkcs11/ec tests fail
	because of ever-changing key size restrictions
Message-ID: <20131204185956.6CE1A62A6D@hg.openjdk.java.net>

Changeset: 6deabb82f72b
Author:    ascarpino
Date:      2013-12-04 10:59 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6deabb82f72b

8027218: TEST_BUG: sun/security/pkcs11/ec tests fail because of ever-changing key size restrictions
Reviewed-by: vinnie

! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/TestCurves.java



From anthony.scarpino at oracle.com  Thu Dec  5 02:05:08 2013
From: anthony.scarpino at oracle.com (anthony.scarpino at oracle.com)
Date: Thu, 05 Dec 2013 02:05:08 -0000
Subject: hg: jdk8/tl/jdk: 8029550: javadoc since tag for recent Hashtable
	updates
Message-ID: <20131205013820.2138962A85@hg.openjdk.java.net>

Changeset: 014c04fd7460
Author:    ascarpino
Date:      2013-12-04 17:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/014c04fd7460

8029550: javadoc since tag for recent Hashtable updates
Reviewed-by: mullan

! src/share/classes/java/security/Provider.java