From yiming.wang at oracle.com Tue Oct 1 03:25:43 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 01 Oct 2013 11:25:43 +0800 Subject: Question about JDK-8023087 In-Reply-To: <524A35EA.60101@oracle.com> References: <1207DFC8-AA5B-4A05-BD92-E69D16E8A923@oracle.com> <419997E8-9FB7-43DF-8C35-619D10A90210@oracle.com> <523B309A.2070606@oracle.com> <55D8369D-EF20-4F39-8089-7BC5BD84C203@oracle.com> <915ED0A1-393D-4EAC-96F8-23DA8FAE57A8@oracle.com> <524A35EA.60101@oracle.com> Message-ID: <524A40B7.8050201@oracle.com> Including the corelibs-dev team, so someone may help me. Thanks, Eric On 2013/10/1 10:39, Eric Wang wrote: > Hi Alan, > > I'm looking at the bug > https://bugs.openjdk.java.net/browse/JDK-8023087 which is filed for > CCC changes https://bugs.openjdk.java.net/browse/JDK-8007405. > > There're 2 simple APIs isImplicit() and isSynthetic() changed in > java.lang.reflect.Parameter, which are not covered by a test. > > However, based on the API desciptions below, I have no idea how to > test them as I can't find such case, Can you please give some > suggestion or some examples? > > /** > * Returns true if this parameter is implicitly declared in source > code; returns ode false otherwise. > * > * @return true if and only if this parameter is implicitly declared > as defined by The Java Language Specification. > */ > public boolean isImplicit() {return Modifier.isMandated(getModifiers());} > > /** > * Returns true if this parameter is neither implicitly nor explicitly > declared in source code; returns false otherwise. > * > * @jls 13.1 The Form of a Binary > * @return true if and only if this parameter is a synthetic construct > as defined by The Java Language Specification. > */ > public boolean isSynthetic() {return > Modifier.isSynthetic(getModifiers());} > > Thanks, > Eric > On 2013/10/1 9:05, Michel Trudeau wrote: >> Eric, >> >> Any update on this bug ? We really need to close this down as soon >> as possible. >> >> https://bugs.openjdk.java.net/browse/JDK-8023087 >> >> Thanks, >> Michel >> >> On Sep 19, 2013, at 10:18 AM, Michel Trudeau >> wrote: >> >> Hopefully the right Eric this time around. >> >> Michel >> >> On Sep 19, 2013, at 10:12 AM, eric wang wrote: >> >> wrong Eric Wang I assume. >> >> Eric >> On 9/19/2013 8:58 AM, Michel Trudeau wrote: >>> Eric, >>> >>> Any update on this ? We really need to get those tests in ASAP. >>> >>> Thanks, >>> Michel >>> >>> On Sep 12, 2013, at 10:40 AM, Michel Trudeau >>> wrote: >>> >>> Eric, >>> >>> This bug got assigned to you yesterday. Not sure if this is really >>> a P4, sounds like a P3 since we need those tests. >>> >>> Is this a top priority for you ? I would really like to get this >>> done sooner than later. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8023087 >>> >>> Thanks, >>> Michel >>> >>> >> >> > From joe.darcy at oracle.com Tue Oct 1 06:41:07 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Sep 2013 23:41:07 -0700 Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions In-Reply-To: <5241E4CB.5030807@oracle.com> References: <5233260C.3010607@oracle.com> <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com> <52334CED.1030900@oracle.com> <52335156.3050308@gmail.com> <52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com> <523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com> <523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com> <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com> <5241E4CB.5030807@oracle.com> Message-ID: <524A6E83.5000802@oracle.com> Hello, I've looked over the 05 version of the webrev. The code on line 494 in modifier is incorrect: 484 /** 485 * Return an {@code int} value OR-ing together the source language 486 * modifiers that can be applied to a parameter. 487 * @return an {@code int} value OR-ing together the source language 488 * modifiers that can be applied to a parameter. 489 * 490 * @jls 8.4.1 Formal Parameters 491 * @since 1.8 492 */ 493 public static int parameterModifiers() { 494 return Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; 495 } Synthetic and mandated are *not* source language modifiers. The bit mask you want will have to be constructed based on parameterModifiers rather than solely as parameterModifiers. It would be more on topic for the list of malformed conditions in Executable: 294 *

This implementation will throw a {@code 295 * MalformedParametersException} if the MethodParameters attribute 296 * describing the parameters contains invalid data. The following 297 * is a list of conditions under which this can occur: 298 *

    299 *
  • The number of parameters (parameter_count) is wrong for the method 300 *
  • A constant pool index is out of bounds. 301 *
  • A constant pool index does not refer to a UTF-8 entry 302 *
  • A parameter's name is "", or contains an illegal character 303 *
  • The flags field contains an illegal flag (something other than 304 * FINAL, SYNTHETIC, or MANDATED) 305 *
to instead be detailed in MalformedParametersException.java. I think the test is acceptable as-is, but an RFE could be filed for some refactoring (having each bad class be represented as a diff from a base byte[], avoiding sending the bytes through the file system). Cheers, -Joe On 9/24/2013 12:15 PM, Eric McCorkle wrote: > Webrev updated to address these issues. > > On 09/24/13 07:51, Joel Borggren-Franck wrote: > >> 364 try { >> 365 tmp = getParameters0(); >> 366 } catch(IllegalArgumentException e) { >> 367 // Rethrow ClassFormatErrors >> 368 throw new MalformedParametersException("Invalid constant pool index"); >> 369 } >> >> What is causing the IAE? Have you considered having >> MalformedParametersExcepton taking a Throwable cause and having the IAE >> as cause? >> > The IAE comes from hotspot itself. There is a standard constant pool > index verifying function that throws IAE if given a bad index. > >> On 2013-09-19, Eric McCorkle wrote: >>> The webrev has been updated with Joe's comments addressed. >>> >>> On 09/19/13 00:11, David Holmes wrote: >>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote: >>>>> This still needs to be reviewed. >>>> You seem to have ignored Joe's comments regarding the change to Modifier >>>> being incorrect. >>>> >>>> David >>>> >>>>> On 09/16/13 14:50, Eric McCorkle wrote: >>>>>> I pulled the class files into byte array constants, as a temporary >>>>>> measure until a viable method for testing bad class files is developed. >>>>>> >>>>>> The webrev has been refreshed. The class files will be taken out before >>>>>> I push. >>>>>> >>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>> >>>>>> On 09/13/13 20:48, Joe Darcy wrote: >>>>>>> To avoid storing binaries in Hg, you could try something like: >>>>>>> >>>>>>> * uuencode / ascii armor the class file >>>>>>> * convert to byte array in the test >>>>>>> * load classes from byte array >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote: >>>>>>>> I did it by hand with emacs. >>>>>>>> >>>>>>>> I would really rather tackle the bad class files for testing issue >>>>>>>> once >>>>>>>> and for all, the Right Way (tm). But with ZBB looming, now is not the >>>>>>>> time to do it. >>>>>>>> >>>>>>>> Hence, I have created this task >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674 >>>>>>>> >>>>>>>> I also just created this one: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812 >>>>>>>> >>>>>>>> On 09/13/13 13:54, Peter Levart wrote: >>>>>>>>> Hi Eric, >>>>>>>>> >>>>>>>>> How did you create those class files? By hand using a HEX editor? Did >>>>>>>>> you create a program that patched the original class file? If the >>>>>>>>> later >>>>>>>>> is the case, you could pack that patching logic inside a custom >>>>>>>>> ClassLoader... >>>>>>>>> >>>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad >>>>>>>>> name" >>>>>>>>> patching could be performed trivially and reliably, I think: >>>>>>>>> search and >>>>>>>>> replace with same-length string. >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote: >>>>>>>>>> Ugh. Byte arrays of class file data is really a horrible solution. >>>>>>>>>> >>>>>>>>>> I have already filed a task for test development post ZBB to >>>>>>>>>> develop a >>>>>>>>>> solution for generating bad class files. I'd prefer to file a >>>>>>>>>> follow-up >>>>>>>>>> to this to add the bad class file tests when that's done. >>>>>>>>>> >>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>> I think the right thing to do is to include the original compiling >>>>>>>>>>> source in a comment, together with a comment on how you modify >>>>>>>>>>> them, and then the result as a byte array. >>>>>>>>>>> >>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our repo. >>>>>>>>>>> >>>>>>>>>>> cheers >>>>>>>>>>> /Joel >>>>>>>>>>> >>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> There is no simple means of generating bad class files for >>>>>>>>>>>> testing. >>>>>>>>>>>> This is a huge deficiency in our testing abilities. >>>>>>>>>>>> >>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no choice >>>>>>>>>>>> but >>>>>>>>>>>> to check in no test for this patch. >>>>>>>>>>>> >>>>>>>>>>>> However, anyone can run the test I've provided with the class >>>>>>>>>>>> files and >>>>>>>>>>>> see that it works. >>>>>>>>>>>> >>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>> >>>>>>>>>>>>> IIRC we don't check in classfiles into the repo. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk, >>>>>>>>>>>>> but ASM might be an option, or storing the class file as an >>>>>>>>>>>>> embedded byte array in the test. >>>>>>>>>>>>> >>>>>>>>>>>>> cheers >>>>>>>>>>>>> /Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which actually >>>>>>>>>>>>>> validates >>>>>>>>>>>>>> parameter names correctly. Apologies for the last one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review this patch, which implements correct behavior for >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The bug report is here: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The webrev is here: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This review is also on crucible. The ID is CR-JDK8TL-182. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>> >>>>>>>>>>>> From eric.mccorkle at oracle.com Tue Oct 1 07:12:40 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 01 Oct 2013 03:12:40 -0400 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Message-ID: <524A75E8.30206@oracle.com> Hello, please review this simple patch which fixes a problem in the type annotations handling API. This manifests as a problem with both j.l.r.Parameter.getAnnotatedType().getType() as well as j.l.r.Executable.getAnnotatedParameterTypes().getType(). The webrev is here: http://cr.openjdk.java.net/~emc/8021398/ The bug report is here: https://bugs.openjdk.java.net/browse/JDK-8021398 Thanks, Eric From joel.franck at oracle.com Tue Oct 1 08:06:04 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Tue, 1 Oct 2013 10:06:04 +0200 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524A75E8.30206@oracle.com> References: <524A75E8.30206@oracle.com> Message-ID: <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> Hi Eric, Thanks for fixing this. On 2013-10-01, Eric McCorkle wrote: > Hello, please review this simple patch which fixes a problem in the type > annotations handling API. This manifests as a problem with both > j.l.r.Parameter.getAnnotatedType().getType() as well as > j.l.r.Executable.getAnnotatedParameterTypes().getType(). > > The webrev is here: > http://cr.openjdk.java.net/~emc/8021398/ > > The bug report is here: > https://bugs.openjdk.java.net/browse/JDK-8021398 > Fix looks mostly fine, but please use the shared array on line 47 instead of allocating a new one. Also you lack a test, adopt the test from the bug and add it to jdk/test/java/lang/annotations/typeAnnotations/ cheers /Joel From chris.hegarty at oracle.com Tue Oct 1 08:15:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 01 Oct 2013 09:15:32 +0100 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524A75E8.30206@oracle.com> References: <524A75E8.30206@oracle.com> Message-ID: <524A84A4.3060904@oracle.com> The source changes look ok to me. I presume a test is not needed as this is already covered by JCK? -Chris. On 10/01/2013 08:12 AM, Eric McCorkle wrote: > Hello, please review this simple patch which fixes a problem in the type > annotations handling API. This manifests as a problem with both > j.l.r.Parameter.getAnnotatedType().getType() as well as > j.l.r.Executable.getAnnotatedParameterTypes().getType(). > > The webrev is here: > http://cr.openjdk.java.net/~emc/8021398/ > > The bug report is here: > https://bugs.openjdk.java.net/browse/JDK-8021398 > > Thanks, > Eric > From paul.sandoz at oracle.com Tue Oct 1 08:23:23 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 10:23:23 +0200 Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE for null op In-Reply-To: References: <9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com> Message-ID: <294FAB76-738B-443F-9A6B-A796808D356A@oracle.com> On Oct 1, 2013, at 12:39 AM, Mike Duigou wrote: > After posting the webrev I decided that an update to the regression test was going to be necessary. Here's the updated webrev including additional unit tests. Unfortunately I had to cut-and-paste some "library" code for exception checking. The "library" code will need to be cleaned up eventually. > > http://cr.openjdk.java.net/~mduigou/JDK-8025067/1/webrev/ > +1 FWIW i am not sure i like things by default catching Throwable since it could obfuscate infrastructure errors and test errors. IMHO it would be better to re-use Runnable for runtime exceptions and another iface for checked exceptions of type T. Re: "library code, yes, we need a more concerted effort for tests to re-use a common test utility library. Paul. From paul.sandoz at oracle.com Tue Oct 1 08:34:32 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 10:34:32 +0200 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524A75E8.30206@oracle.com> References: <524A75E8.30206@oracle.com> Message-ID: On Oct 1, 2013, at 9:12 AM, Eric McCorkle wrote: > Hello, please review this simple patch which fixes a problem in the type > annotations handling API. This manifests as a problem with both > j.l.r.Parameter.getAnnotatedType().getType() as well as > j.l.r.Executable.getAnnotatedParameterTypes().getType(). > > The webrev is here: > http://cr.openjdk.java.net/~emc/8021398/ > A minor optimization. Since we know the size we can change: 133 typeAnnotations = list.toArray(new TypeAnnotation[0]); to: 133 typeAnnotations = list.toArray(new TypeAnnotation[list.size()]); There are also other similar cases in the same source file that could be updated. Also for the case of the empty array there is already: 47 private static final TypeAnnotation[] EMPTY_TYPE_ANNOTATION_ARRAY = new TypeAnnotation[0]; which can be reused. Paul. > The bug report is here: > https://bugs.openjdk.java.net/browse/JDK-8021398 > > Thanks, > Eric From chris.hegarty at oracle.com Tue Oct 1 08:48:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 01 Oct 2013 09:48:43 +0100 Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE for null op In-Reply-To: <5FA24890-15C2-4DEB-A38B-3259060B005D@oracle.com> References: <9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com> <5FA24890-15C2-4DEB-A38B-3259060B005D@oracle.com> Message-ID: <524A8C6B.3050308@oracle.com> > On Sep 30, 2013, at 3:39 PM, Mike Duigou wrote: > >> After posting the webrev I decided that an update to the regression test was going to be necessary. Here's the updated webrev including additional unit tests. Unfortunately I had to cut-and-paste some "library" code for exception checking. The "library" code will need to be cleaned up eventually. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8025067/1/webrev/ The source changes look good to me. Thanks Mike. -Chris. >> >> Mike From jhuxhorn at googlemail.com Tue Oct 1 08:50:41 2013 From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=) Date: Tue, 1 Oct 2013 10:50:41 +0200 Subject: 9 days left for getCallerClass solution Message-ID: ?just saying? From sean.coffey at oracle.com Tue Oct 1 09:09:30 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Oct 2013 10:09:30 +0100 Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054 In-Reply-To: <52445D7E.2050703@oracle.com> References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com> <52445D7E.2050703@oracle.com> Message-ID: <524A914A.1070304@oracle.com> Miran, I'm assuming that all these changes were reviewed when integrated to the upstream JAX-WS project. I confirm that my changes from 8016271 are present and look fine. I'm not an OpenJDK reviewer though so you'll need someone else as reviewer. regards, Sean. On 26/09/2013 17:14, Miroslav Kos wrote: > Hi Sean, > anything new about this? > > I fixed the copyright/indentation problems (the only change), so the > updated jaxws-webrev is located here: > http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/ > > Since the timestamp (version number) changed too, I updated also the > JIRA issue: > https://bugs.openjdk.java.net/browse/JDK-8025054 > > It would be good to push it soon. > > Thanks > Miran > > > On 9/23/13 5:38 PM, Alan Bateman wrote: >> On 23/09/2013 02:19, Miroslav Kos wrote: >>> Hi everybody, >>> >>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to >>> most recent development version. >>> >>> As usually, it is quite big changeset (6k+ LOC changed) and includes >>> several bug fixes, for details see the issue description: >>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>> >>> Please, see weberevs here: >>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00 >>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/ >> Just a passing comment (not a code review) on the copyright headers >> of the new source files. I assume they must have been copied from >> another file as they say 1997. You might want to also check for tabs >> too (although jcheck will catch those) because it looks like some of >> the javadoc comments and annotations have inconsistent indentation. >> >> -Alan > From chris.hegarty at oracle.com Tue Oct 1 09:29:11 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 01 Oct 2013 10:29:11 +0100 Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054 In-Reply-To: <524A914A.1070304@oracle.com> References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com> <52445D7E.2050703@oracle.com> <524A914A.1070304@oracle.com> Message-ID: <524A95E7.9000004@oracle.com> On 10/01/2013 10:09 AM, Se?n Coffey wrote: > Miran, > > I'm assuming that all these changes were reviewed when integrated to the > upstream JAX-WS project. I confirm that my changes from 8016271 are > present and look fine. I'm not an OpenJDK reviewer though so you'll need > someone else as reviewer. From a quick skim, I don't see anything objectionable. I see a new test has been added to the jdk repo. Since it defines a TestService, is it a bit of a land grab on javax/xml/ws? Or can other jaxws test be put in javax/xml/ws without interference? -Chris. > > regards, > Sean. > > On 26/09/2013 17:14, Miroslav Kos wrote: >> Hi Sean, >> anything new about this? >> >> I fixed the copyright/indentation problems (the only change), so the >> updated jaxws-webrev is located here: >> http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/ >> >> Since the timestamp (version number) changed too, I updated also the >> JIRA issue: >> https://bugs.openjdk.java.net/browse/JDK-8025054 >> >> It would be good to push it soon. >> >> Thanks >> Miran >> >> >> On 9/23/13 5:38 PM, Alan Bateman wrote: >>> On 23/09/2013 02:19, Miroslav Kos wrote: >>>> Hi everybody, >>>> >>>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to >>>> most recent development version. >>>> >>>> As usually, it is quite big changeset (6k+ LOC changed) and includes >>>> several bug fixes, for details see the issue description: >>>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>>> >>>> Please, see weberevs here: >>>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00 >>>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/ >>> Just a passing comment (not a code review) on the copyright headers >>> of the new source files. I assume they must have been copied from >>> another file as they say 1997. You might want to also check for tabs >>> too (although jcheck will catch those) because it looks like some of >>> the javadoc comments and annotations have inconsistent indentation. >>> >>> -Alan >> > From chris.hegarty at oracle.com Tue Oct 1 09:32:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 01 Oct 2013 10:32:16 +0100 Subject: RFR: JDK-8025686 : (s) Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support In-Reply-To: <43DF08F8-4558-43AD-BADD-9085563C1AD9@oracle.com> References: <43DF08F8-4558-43AD-BADD-9085563C1AD9@oracle.com> Message-ID: <524A96A0.7050800@oracle.com> The changes look ok to me Mike. Thanks, -Chris, On 09/30/2013 09:48 PM, Mike Duigou wrote: > Hello all; > > When JDK-8006709 (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cff8d7768d72) was pushed it changed the default source level for the jdk project NetBeans projects to 1.8. This was a reasonable change since at this point there was already a small amount of Java 8 "-source 1.8" code in the jdk repo. Since that time the amount of source has increased. This change meant, unfortunately, that it was no longer possible to use a release version of netbeans as 7.3 did not support Java 8 source. Users wanting to use the jdk projects had to use either special lambda builds of NetBeans or the nightly dev builds. > > NetBeans 7.4 will support Java 8 source. This changeset adjusts the projects so that they are recognized by NetBeans. The same change also works with NetBeans dev and lambda builds. > > http://cr.openjdk.java.net/~mduigou/JDK-8025686/0/webrev/ > > In addition to updating the projects this change also adjusts the location where classes would be written (assuming that compilation from within NetBeans wasn't broken--it is currently broken). This change is incomplete in that it doesn't properly understand the SPEC variable from the new makefiles but at least it prevents writing output to the repo directory. This will be further cleaned up in JDK-8016210 (https://bugs.openjdk.java.net/browse/JDK-8016210) > > Cheers, > > Mike > From sean.coffey at oracle.com Tue Oct 1 09:41:37 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Oct 2013 10:41:37 +0100 Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054 In-Reply-To: <524A95E7.9000004@oracle.com> References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com> <52445D7E.2050703@oracle.com> <524A914A.1070304@oracle.com> <524A95E7.9000004@oracle.com> Message-ID: <524A98D1.9050901@oracle.com> On 01/10/2013 10:29, Chris Hegarty wrote: > On 10/01/2013 10:09 AM, Se?n Coffey wrote: >> Miran, >> >> I'm assuming that all these changes were reviewed when integrated to the >> upstream JAX-WS project. I confirm that my changes from 8016271 are >> present and look fine. I'm not an OpenJDK reviewer though so you'll need >> someone else as reviewer. > > From a quick skim, I don't see anything objectionable. > > I see a new test has been added to the jdk repo. Since it defines a > TestService, is it a bit of a land grab on javax/xml/ws? Or can other > jaxws test be put in javax/xml/ws without interference? Good point. Hopefully Miran can move them to a sub-directory before pushing. Maybe something like : test/javax/xml/ws/clientJarTest/ regards, Sean. > > -Chris. > >> >> regards, >> Sean. >> >> On 26/09/2013 17:14, Miroslav Kos wrote: >>> Hi Sean, >>> anything new about this? >>> >>> I fixed the copyright/indentation problems (the only change), so the >>> updated jaxws-webrev is located here: >>> http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/ >>> >>> Since the timestamp (version number) changed too, I updated also the >>> JIRA issue: >>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>> >>> It would be good to push it soon. >>> >>> Thanks >>> Miran >>> >>> >>> On 9/23/13 5:38 PM, Alan Bateman wrote: >>>> On 23/09/2013 02:19, Miroslav Kos wrote: >>>>> Hi everybody, >>>>> >>>>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to >>>>> most recent development version. >>>>> >>>>> As usually, it is quite big changeset (6k+ LOC changed) and includes >>>>> several bug fixes, for details see the issue description: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>>>> >>>>> Please, see weberevs here: >>>>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00 >>>>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/ >>>> Just a passing comment (not a code review) on the copyright headers >>>> of the new source files. I assume they must have been copied from >>>> another file as they say 1997. You might want to also check for tabs >>>> too (although jcheck will catch those) because it looks like some of >>>> the javadoc comments and annotations have inconsistent indentation. >>>> >>>> -Alan >>> >> From miroslav.kos at oracle.com Tue Oct 1 09:44:06 2013 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 01 Oct 2013 11:44:06 +0200 Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054 In-Reply-To: <524A914A.1070304@oracle.com> References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com> <52445D7E.2050703@oracle.com> <524A914A.1070304@oracle.com> Message-ID: <524A9966.5010202@oracle.com> Hi Sean, yes, all the changes are going throuhg a review on our side before they are pushed into upstream projects. When we integrated in the past into jdk, reviewers were Sean Mullan, Sami Koivu, Alan Bateman and Alexander Fomin. Could anybody from them look into it? If you had any hint who could we ask, let me know. Thanks Miran On 10/1/13 11:09 AM, Se?n Coffey wrote: > Miran, > > I'm assuming that all these changes were reviewed when integrated to > the upstream JAX-WS project. I confirm that my changes from 8016271 > are present and look fine. I'm not an OpenJDK reviewer though so > you'll need someone else as reviewer. > > regards, > Sean. > > On 26/09/2013 17:14, Miroslav Kos wrote: >> Hi Sean, >> anything new about this? >> >> I fixed the copyright/indentation problems (the only change), so the >> updated jaxws-webrev is located here: >> http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/ >> >> Since the timestamp (version number) changed too, I updated also the >> JIRA issue: >> https://bugs.openjdk.java.net/browse/JDK-8025054 >> >> It would be good to push it soon. >> >> Thanks >> Miran >> >> >> On 9/23/13 5:38 PM, Alan Bateman wrote: >>> On 23/09/2013 02:19, Miroslav Kos wrote: >>>> Hi everybody, >>>> >>>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to >>>> most recent development version. >>>> >>>> As usually, it is quite big changeset (6k+ LOC changed) and >>>> includes several bug fixes, for details see the issue description: >>>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>>> >>>> Please, see weberevs here: >>>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00 >>>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/ >>> Just a passing comment (not a code review) on the copyright headers >>> of the new source files. I assume they must have been copied from >>> another file as they say 1997. You might want to also check for >>> tabs too (although jcheck will catch those) because it looks like >>> some of the javadoc comments and annotations have inconsistent >>> indentation. >>> >>> -Alan >> > From paul.sandoz at oracle.com Tue Oct 1 10:36:47 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 01 Oct 2013 10:36:47 +0000 Subject: hg: jdk8/tl/jdk: 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Message-ID: <20131001103710.3BE6762C36@hg.openjdk.java.net> Changeset: f8b3ab514564 Author: psandoz Date: 2013-10-01 12:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b3ab514564 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Reviewed-by: alanb ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java From paul.sandoz at oracle.com Tue Oct 1 11:18:39 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 13:18:39 +0200 Subject: SplittableRandom update In-Reply-To: References: <523C57A6.2000508@cs.oswego.edu> Message-ID: On Sep 20, 2013, at 5:30 PM, Martin Buchholz wrote: > Looks good. > > Random nitpicks: > > I prefer the old variable name DOUBLE_UNIT to DOUBLE_ULP; else you are > inventing a slightly different meaning for ULP. > > I think using hex floating point literals is preferred: > > - private static final double DOUBLE_ULP = 1.0 / (1L << 53); > + private static final double DOUBLE_ULP = 0x1.0p-53; > I don't have any strong preference on the above comments, Doug? > comment tidy: > > - * Appleby's MurmurHash3 algorithm See > - * http://code.google.com/p/smhasher/wiki/MurmurHash3 . The mix32 > + * Appleby's MurmurHash3 algorithm (see > + * http://code.google.com/p/smhasher/wiki/MurmurHash3). The mix32 > Fine by me. Paul. From miroslav.kos at oracle.com Tue Oct 1 11:22:37 2013 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 01 Oct 2013 13:22:37 +0200 Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054 In-Reply-To: <524A98D1.9050901@oracle.com> References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com> <52445D7E.2050703@oracle.com> <524A914A.1070304@oracle.com> <524A95E7.9000004@oracle.com> <524A98D1.9050901@oracle.com> Message-ID: <524AB07D.9010103@oracle.com> No problem, I just moved it: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.01/ Let me know if I can do anything else to speed up pushing the changeset. Thanks Miran On 10/1/13 11:41 AM, Se?n Coffey wrote: > > On 01/10/2013 10:29, Chris Hegarty wrote: >> On 10/01/2013 10:09 AM, Se?n Coffey wrote: >>> Miran, >>> >>> I'm assuming that all these changes were reviewed when integrated to >>> the >>> upstream JAX-WS project. I confirm that my changes from 8016271 are >>> present and look fine. I'm not an OpenJDK reviewer though so you'll >>> need >>> someone else as reviewer. >> >> From a quick skim, I don't see anything objectionable. >> >> I see a new test has been added to the jdk repo. Since it defines a >> TestService, is it a bit of a land grab on javax/xml/ws? Or can other >> jaxws test be put in javax/xml/ws without interference? > Good point. Hopefully Miran can move them to a sub-directory before > pushing. Maybe something like : test/javax/xml/ws/clientJarTest/ > > regards, > Sean. >> >> -Chris. >> >>> >>> regards, >>> Sean. >>> >>> On 26/09/2013 17:14, Miroslav Kos wrote: >>>> Hi Sean, >>>> anything new about this? >>>> >>>> I fixed the copyright/indentation problems (the only change), so the >>>> updated jaxws-webrev is located here: >>>> http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/ >>>> >>>> Since the timestamp (version number) changed too, I updated also the >>>> JIRA issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>>> >>>> It would be good to push it soon. >>>> >>>> Thanks >>>> Miran >>>> >>>> >>>> On 9/23/13 5:38 PM, Alan Bateman wrote: >>>>> On 23/09/2013 02:19, Miroslav Kos wrote: >>>>>> Hi everybody, >>>>>> >>>>>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to >>>>>> most recent development version. >>>>>> >>>>>> As usually, it is quite big changeset (6k+ LOC changed) and includes >>>>>> several bug fixes, for details see the issue description: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025054 >>>>>> >>>>>> Please, see weberevs here: >>>>>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00 >>>>>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/ >>>>> Just a passing comment (not a code review) on the copyright headers >>>>> of the new source files. I assume they must have been copied from >>>>> another file as they say 1997. You might want to also check for tabs >>>>> too (although jcheck will catch those) because it looks like some of >>>>> the javadoc comments and annotations have inconsistent indentation. >>>>> >>>>> -Alan >>>> >>> > From lance.andersen at oracle.com Tue Oct 1 12:00:38 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 1 Oct 2013 08:00:38 -0400 Subject: RFR: JDK-8025686 : (s) Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support In-Reply-To: <524A96A0.7050800@oracle.com> References: <43DF08F8-4558-43AD-BADD-9085563C1AD9@oracle.com> <524A96A0.7050800@oracle.com> Message-ID: <5303CFE1-6A57-4358-8C71-7067EC9D7F28@oracle.com> Looks ok to me as well 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 Oct 1, 2013, at 5:32 AM, Chris Hegarty wrote: > The changes look ok to me Mike. Thanks, > > -Chris, > > On 09/30/2013 09:48 PM, Mike Duigou wrote: >> Hello all; >> >> When JDK-8006709 (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cff8d7768d72) was pushed it changed the default source level for the jdk project NetBeans projects to 1.8. This was a reasonable change since at this point there was already a small amount of Java 8 "-source 1.8" code in the jdk repo. Since that time the amount of source has increased. This change meant, unfortunately, that it was no longer possible to use a release version of netbeans as 7.3 did not support Java 8 source. Users wanting to use the jdk projects had to use either special lambda builds of NetBeans or the nightly dev builds. >> >> NetBeans 7.4 will support Java 8 source. This changeset adjusts the projects so that they are recognized by NetBeans. The same change also works with NetBeans dev and lambda builds. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8025686/0/webrev/ >> >> In addition to updating the projects this change also adjusts the location where classes would be written (assuming that compilation from within NetBeans wasn't broken--it is currently broken). This change is incomplete in that it doesn't properly understand the SPEC variable from the new makefiles but at least it prevents writing output to the repo directory. This will be further cleaned up in JDK-8016210 (https://bugs.openjdk.java.net/browse/JDK-8016210) >> >> Cheers, >> >> Mike >> From paul.sandoz at oracle.com Tue Oct 1 12:10:33 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 14:10:33 +0200 Subject: RFR 8025567 Mark relevant public stream tests as serialization hostile Message-ID: <8749BE22-D1BE-4529-B24F-A362A05E36BF@oracle.com> Hi, This patch marks certain stream tests as serialization hostile. Such tests will ignored by by lambda serialization testing framework: http://cr.openjdk.java.net/~psandoz/tl/JDK-8025567-test-serialization-hostile/webrev/ Paul. From sundararajan.athijegannathan at oracle.com Tue Oct 1 12:14:30 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 01 Oct 2013 12:14:30 +0000 Subject: hg: jdk8/tl/nashorn: 8 new changesets Message-ID: <20131001121439.29E8762C3A@hg.openjdk.java.net> Changeset: 2016a6b9e1f3 Author: hannesw Date: 2013-09-27 16:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2016a6b9e1f3 8025515: Performance issues with Source.getLine() Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/Source.java + test/script/basic/JDK-8025515.js Changeset: 1809c9e97c71 Author: hannesw Date: 2013-09-27 17:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1809c9e97c71 8025520: Array.prototype.slice should only copy defined elements Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025520.js Changeset: efc40aacaee4 Author: hannesw Date: 2013-09-30 15:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/efc40aacaee4 8025589: Array.prototype.shift should only copy defined elements in generic mode Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025589.js Changeset: ad5f9ce2a95b Author: jlaskey Date: 2013-09-30 10:24 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ad5f9ce2a95b Merge Changeset: 787e36fdf69a Author: jlaskey Date: 2013-09-30 12:06 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/787e36fdf69a Merge Changeset: 7272ec90f2c6 Author: sundar Date: 2013-09-30 21:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7272ec90f2c6 8025629: load function should support a way to load scripts from classpath Reviewed-by: lagergren, hannesw, attila ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java + test/script/trusted/JDK-8025629.js + test/src/jdk/nashorn/internal/runtime/resources/load_test.js Changeset: f5aefbe76cec Author: jlaskey Date: 2013-09-30 18:09 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f5aefbe76cec 8025689: fx:base.js classes not loading Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/base.js Changeset: cd7fb58043cb Author: sundar Date: 2013-10-01 14:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cd7fb58043cb 8025488: Error.captureStackTrace should not format error stack Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8025488.js + test/script/basic/JDK-8025488.js.EXPECTED From alexander.zuev at oracle.com Tue Oct 1 13:04:14 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 01 Oct 2013 13:04:14 +0000 Subject: hg: jdk8/tl/langtools: 7118749: NPE in CreateSymbols caused by bad diagnostic Message-ID: <20131001130418.B759762C3C@hg.openjdk.java.net> Changeset: 1a3e8347f3dd Author: kizune Date: 2013-10-01 17:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1a3e8347f3dd 7118749: NPE in CreateSymbols caused by bad diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java From Alan.Bateman at oracle.com Tue Oct 1 13:40:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Oct 2013 06:40:22 -0700 Subject: 9 days left for getCallerClass solution In-Reply-To: References: Message-ID: <524AD0C6.9030309@oracle.com> On 01/10/2013 01:50, J?rn Huxhorn wrote: > ?just saying? We know. It seems unlikely that there will be agreement on a standard API or that there is time for a new API to bake. So the safest thing might be just restore the totally unsupported getCallerClass and submit a JEP with a proposal to add a standard API. -Alan. From dmitry.degrave at oracle.com Tue Oct 1 13:46:40 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Tue, 01 Oct 2013 13:46:40 +0000 Subject: hg: jdk8/tl/jaxp: 8024707: TransformerException : item() return null with node list of length != 1 Message-ID: <20131001134642.F253262C3E@hg.openjdk.java.net> Changeset: 84a2b2ee6fc6 Author: aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84a2b2ee6fc6 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java From dmitry.degrave at oracle.com Tue Oct 1 13:47:11 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Tue, 01 Oct 2013 13:47:11 +0000 Subject: hg: jdk8/tl/jdk: 8024707: TransformerException : item() return null with node list of length != 1 Message-ID: <20131001134724.E31CE62C3F@hg.openjdk.java.net> Changeset: bf52ea6bd9eb Author: aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf52ea6bd9eb 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl From joe.darcy at oracle.com Tue Oct 1 16:03:17 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Oct 2013 09:03:17 -0700 Subject: SplittableRandom update In-Reply-To: References: <523C57A6.2000508@cs.oswego.edu> Message-ID: <524AF245.9040203@oracle.com> On 10/1/2013 4:18 AM, Paul Sandoz wrote: > On Sep 20, 2013, at 5:30 PM, Martin Buchholz wrote: >> Looks good. >> >> Random nitpicks: >> >> I prefer the old variable name DOUBLE_UNIT to DOUBLE_ULP; else you are >> inventing a slightly different meaning for ULP. >> >> I think using hex floating point literals is preferred: >> >> - private static final double DOUBLE_ULP = 1.0 / (1L << 53); >> + private static final double DOUBLE_ULP = 0x1.0p-53; >> > I don't have any strong preference on the above comments, Doug? Please use the hex literals in a case like this; it is exactly the situation they were designed for. -Joe From cowwoc at bbs.darktech.org Tue Oct 1 16:12:09 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 01 Oct 2013 12:12:09 -0400 Subject: 9 days left for getCallerClass solution In-Reply-To: <524AD0C6.9030309@oracle.com> References: <524AD0C6.9030309@oracle.com> Message-ID: <524AF459.7090306@bbs.darktech.org> On 01/10/2013 9:40 AM, Alan Bateman wrote: > On 01/10/2013 01:50, J?rn Huxhorn wrote: >> ?just saying? > We know. It seems unlikely that there will be agreement on a standard > API or that there is time for a new API to bake. So the safest thing > might be just restore the totally unsupported getCallerClass and > submit a JEP with a proposal to add a standard API. > > -Alan. Hi Alan, Two questions: 1. "restore the totally unsupported getCallerClass": Does that mean it'll become supported again? 2. "submit a JEP with a proposal to add a standard API": Will this push the API to JDK 9? Thanks, Gili From mark.reinhold at oracle.com Tue Oct 1 16:40:22 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Oct 2013 09:40:22 -0700 Subject: 9 days left for getCallerClass solution In-Reply-To: <524AF459.7090306@bbs.darktech.org> References: , <524AD0C6.9030309@oracle.com>, <524AF459.7090306@bbs.darktech.org> Message-ID: <20131001094022.470095@eggemoggin.niobe.net> 2013/10/1 2:12 -0700, cowwoc at bbs.darktech.org: > Two questions: > > 1. "restore the totally unsupported getCallerClass": Does that mean > it'll become supported again? No. It never was supported. Use at your own risk. > 2. "submit a JEP with a proposal to add a standard API": Will this push > the API to JDK 9? Yes. It will push the supported, standard, public API to JDK 9. - Mark From mike.duigou at oracle.com Tue Oct 1 17:29:25 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 01 Oct 2013 17:29:25 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131001173020.8476462C5E@hg.openjdk.java.net> Changeset: 8cfb2bddd95e Author: mduigou Date: 2013-09-30 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cfb2bddd95e 7057785: Add note about optional support of recursive methods for self-referential Collection/Map Reviewed-by: scolebourne, darcy, mduigou Contributed-by: Stephen Colebourne ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java Changeset: f2e2326f787b Author: mduigou Date: 2013-10-01 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2e2326f787b 8025067: Unconditionally throw NPE if null op provided to Arrays.parallelPrefix Reviewed-by: henryjen, chegar, psandoz ! src/share/classes/java/util/Arrays.java ! test/java/util/Arrays/ParallelPrefix.java From mike.duigou at oracle.com Tue Oct 1 17:37:55 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 01 Oct 2013 17:37:55 +0000 Subject: hg: jdk8/tl/jdk: 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Message-ID: <20131001173807.4DC8762C60@hg.openjdk.java.net> Changeset: c32ab940a183 Author: mduigou Date: 2013-10-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c32ab940a183 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Reviewed-by: lancea, chegar ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent From eric.mccorkle at oracle.com Tue Oct 1 18:18:24 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 01 Oct 2013 14:18:24 -0400 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> Message-ID: <524B11F0.2070702@oracle.com> I forgot to hg add the test. I've addressed your and others' comments, and refreshed the webrev. Please review. On 10/01/13 04:06, Joel Borggren-Franck wrote: > Hi Eric, > > Thanks for fixing this. > > On 2013-10-01, Eric McCorkle wrote: >> Hello, please review this simple patch which fixes a problem in the type >> annotations handling API. This manifests as a problem with both >> j.l.r.Parameter.getAnnotatedType().getType() as well as >> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8021398/ >> >> The bug report is here: >> https://bugs.openjdk.java.net/browse/JDK-8021398 >> > > Fix looks mostly fine, but please use the shared array on line 47 > instead of allocating a new one. > > Also you lack a test, adopt the test from the bug and add it to > jdk/test/java/lang/annotations/typeAnnotations/ > > cheers > /Joel > From dmitry.nadezhin at gmail.com Tue Oct 1 18:19:06 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Tue, 1 Oct 2013 22:19:06 +0400 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> Message-ID: Dear BigInteger experts, Do you have comments to my previous message ? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html On Sat, Sep 21, 2013 at 8:13 AM, Dmitry Nadezhin wrote: > It is important that BigInteger objects be full-fledged instances on which > all methods may be correctly invoked. > > This bitLength bug started this discussion: > P4 JDK-6910473 : java.math.BigInteger.bitLength() may return negative > "int" on large numbers > https://bugs.openjdk.java.net/browse/JDK-6910473 > > I reviewed the behavior of very large BigInteger objects and found a few > other bugs: > > P3 JDK-8021204 : Constructor BigInteger(String val, int radix) doesn't > detect overflow > https://bugs.openjdk.java.net/browse/JDK-8021204 > > P3 JDK-8021203 : BigInteger.doubleValue/floatValue returns 0.0 instead of > Infinity > https://bugs.openjdk.java.net/browse/JDK-8021203 > > P3 JDK-8022780 : Incorrect BigInteger division because of > MutableBigInteger.bitLength() overflow > https://bugs.openjdk.java.net/browse/JDK-8022780 > > In these bugs (and also in the original bitLength bug) a BigInteger method > silently returns an incorrect result. > Silently incorrect behavior may lead to unexpected failures and difficult > to debug scenarios in applications. > > Some applications try to adapt to these bugs with performance overhead. As > clients of java.math.BigInteger can't trust bitLength() , they have to > perform inefficient checks for bitLength overflow. See for example the > methods isValidFloat, isValidDouble, bitLengthOverflow in lines 135-167 of > this file from the Scala library: > > https://github.com/scala/scala/blob/master/src/library/scala/math/BigInt.scala > > As Brian said: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018403.html > there are two ways to fix bitLength bug: > a) simply by throwing an ArithmeticException if the bit length as an int > would be negative; > b) to define BigInteger to support a limited range and to clamp to that > range in the constructor, > > throwing an ArithmeticException if the supplied parameter(s) would > cause the BigInteger to overflow. > This can be applied to other bugs too. > > We found a few bugs appearing on large BigInteger objects, but I'm not > sure that we find all of them. > So I prefer to limit the supported range because this not only fixes known > bugs > but also prevents the occurrence of bugs that haven't been discovered yet. > > Joe Darcy suggested that the limiting of the supported range would not be > a specification change but instead an implementation note > "in JDK 8, BigInteger operates on values in the range ....": > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018644.html > > So I prepared a patch that fixes the bitLength bug together with another > bugs mentioned above. > > The WebRev is here: > http://cr.openjdk.java.net/~bpb/BigIntRange/ > > This patch limits the supported range of BigInteger in JDK 8. The APIdoc > of the class contains an implementation note that BigInteger constructors > and operations throw an ArithmeticException when the result is out of the > supported range. > The supported range in JDK 8 is -2^Integer.MAX_VALUE to > 2^Integer.MAX_VALUE, exclusive. This range is symmetric to make patch > simpler. > > All constructors contains call checkRange() guarded by cheap test > "mag.length >= MAX_MAG_LENGTH". The checkRange() method throws an > ArithmeticException if the BigInteger instance would be out of the > supported range. APIdocs of public constructors and methods contain an > appropriate @throws ArithmeticException clause . > > The patch contains a fix of various other problems related to overflow: > 1) Calculation of prime searchLen suffered from int overflow when > bitLength was large; > 2) int overflow in pow() method; > 3) Overflow of intermediate results in modPow() method; > 4) Removed the implementation restriction on Integer.MIN_VALUE > in shiftLeft() and shiftRight() methods introduced during the fix of: > JDK-6371401 : java.math.BigInteger.shift(Integer.MIN_VALUE) throws > StackOverflowError > https://bugs.openjdk.java.net/browse/JDK-6371401 > > Please, review this patch. > > > > On Wed, Jul 3, 2013 at 6:06 AM, Joseph Darcy wrote: > >> Hello, >> >> A quick note on this issue, before the recent work to use better >> algorithms for BigInteger arithmetic operation, working with huge numbers >> was impractical and thus BigInteger.bitLength misbehavior was mostly an >> academic concern. With the better algorithms, exposure to these large >> values is likely to increase so BigInteger.bitLength should do something >> reasonable. >> >> There are at least two implementation limits of note in the current code: >> >> * Total bit length given a single backing array >> * Max size of serializable BigInteger given old byte-array based format. >> >> My preference for addressing this issue includes adding an implementation >> note along the lines of "in JDK 8, BigInteger operates on values in the >> range ...." without requiring that range to be part of the specification. >> >> Cheers, >> >> -Joe >> >> >> On 6/25/2013 6:18 PM, Brian Burkhalter wrote: >> >>> This request for comment regards this issue >>> >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6910473 >>> BigInteger.bigLength() may return negative value for large numbers >>> >>> but more importantly Dmitry's thread >>> >>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>> June/018345.html >>> What is the range of BigInteger values? >>> >>> The issue may be fixed superficially simply by throwing an >>> ArithmeticException if the bit length as an int would be negative. A better >>> fix suggested both in the issue description and in the aforementioned >>> thread (option 1 of 3), is to define BigInteger to support a limited range >>> and to clamp to that range in the constructor, throwing an >>> ArithmeticException if the supplied parameter(s) would cause the BigInteger >>> to overflow. This check would be relatively inexpensive. The suggested >>> constraint range is >>> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) >>> This constraint would guarantee that all BigInteger instances are >>> capable of accurately returning their properties such as bit length, bit >>> count, etc. >>> >>> This naturally would require a minor specification change to BigInteger. >>> The question is whether this change would limit any future developments of >>> this and related classes. For example, one could envision BigInteger >>> supporting bit lengths representable by a long instead of an int. In this >>> case the second option would be preferable. >>> >>> It has been suggested that an alternative to extending the ranges >>> supported by BigInteger would be to define a different class altogether to >>> handle the larger ranges, keeping BigInteger as a well-specified API for >>> the ranges it supports. Other related classes for arbitrary precision >>> binary floating point and rational numbers might also be considered. >>> >>> In summary the specific questions being posed here are: >>> >>> 1) what is the general opinion on clamping the range of BigInteger and >>> the various options suggested at the end of >>> >>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>> June/018345.html? >>> >>> 2) what are the forward looking thoughts on handling integers outside >>> the current BigInteger range? >>> >>> From a practical point of view, any changes need to be considered with >>> respect to what may be done in the short term (JDK 8) versus the long (JDK >>> 9), so to speak. >>> >>> Thanks, >>> >>> Brian >>> >> >> > From roger.riggs at oracle.com Tue Oct 1 18:26:41 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Oct 2013 14:26:41 -0400 Subject: Review Request for project Threeten updates Message-ID: <524B13E1.4090202@oracle.com> Please review these changes from the Threeten project for integration into jdk-tl. http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/ 8023762: Add ChronoPeriod interface and bind period to Chronology Summary: Make Period ISO-only, adding a Chronology-specific period concept Contributed-by: scolebourne at joda.org 8023763: Rename ChronoDateImpl Summary: Rename ChronoDateImpl to ChronoLocalDateImpl Contributed-by: scolebourne at joda.org 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Contributed-by: scolebourne at joda.org 8024835: Change until() to accept any compatible temporal Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary Contributed-by: scolebourne at joda.org 8024807: Add getChronlogy() to CLDT/CZDT Summary: Alternative to method is clunky and hard to find Contributed-by: scolebourne at joda.org 8024834: Better return type for TemporalField resolve Summary: Allow resolve method to return more than just ChronoLocalDate Contributed-by: scolebourne at joda.org 8024999: Instant.Parse typo in example Summary: javadoc only fix to correct example to use "." and "Z" Thanks, Roger From brian.burkhalter at oracle.com Tue Oct 1 18:31:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Oct 2013 11:31:31 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Message-ID: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.openjdk.java.net/browse/JDK-8010371 Webrev http://cr.openjdk.java.net/~bpb/8010371 If this fix appears acceptable I will file a CCC request. Thanks, Brian From joe.darcy at oracle.com Tue Oct 1 18:33:52 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Oct 2013 11:33:52 -0700 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524B11F0.2070702@oracle.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> <524B11F0.2070702@oracle.com> Message-ID: <524B1590.90702@oracle.com> Looks fine; cheers, -Joe On 10/1/2013 11:18 AM, Eric McCorkle wrote: > I forgot to hg add the test. I've addressed your and others' comments, > and refreshed the webrev. Please review. > > On 10/01/13 04:06, Joel Borggren-Franck wrote: >> Hi Eric, >> >> Thanks for fixing this. >> >> On 2013-10-01, Eric McCorkle wrote: >>> Hello, please review this simple patch which fixes a problem in the type >>> annotations handling API. This manifests as a problem with both >>> j.l.r.Parameter.getAnnotatedType().getType() as well as >>> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8021398/ >>> >>> The bug report is here: >>> https://bugs.openjdk.java.net/browse/JDK-8021398 >>> >> Fix looks mostly fine, but please use the shared array on line 47 >> instead of allocating a new one. >> >> Also you lack a test, adopt the test from the bug and add it to >> jdk/test/java/lang/annotations/typeAnnotations/ >> >> cheers >> /Joel >> From kumar.x.srinivasan at oracle.com Tue Oct 1 18:46:37 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 01 Oct 2013 11:46:37 -0700 Subject: RFR: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Message-ID: <524B188D.3080407@oracle.com> Hi Naoto, Michael, Please review the webrev below. Apparently using variables to hold the common message strings between pack200(1) and unpack200(1) utilities don't bode well, with the new globalization tools. Thus the request is to remove these common variable and inline these in the messages array. While doing so, I noticed that the format and whitespace was incorrect, as this file was never touched since the TeamWare days (8+ years ago). So I took the liberty of fixing the format as per java coding conventions, and fixed up a couple of typos. http://cr.openjdk.java.net/~ksrini/8025342/webrev.0/ https://bugs.openjdk.java.net/browse/JDK-8025342 http://bugs.sun.com/view_bug.do?bug_id=8025342 Thanks Kumar From joel.franck at oracle.com Tue Oct 1 18:47:55 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 1 Oct 2013 20:47:55 +0200 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524B11F0.2070702@oracle.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> <524B11F0.2070702@oracle.com> Message-ID: <4D0A93BA-9C8E-42B1-91E6-B4F46071E42B@oracle.com> Looks good. cheers /Joel On Oct 1, 2013, at 8:18 PM, Eric McCorkle wrote: > I forgot to hg add the test. I've addressed your and others' comments, > and refreshed the webrev. Please review. > > On 10/01/13 04:06, Joel Borggren-Franck wrote: >> Hi Eric, >> >> Thanks for fixing this. >> >> On 2013-10-01, Eric McCorkle wrote: >>> Hello, please review this simple patch which fixes a problem in the type >>> annotations handling API. This manifests as a problem with both >>> j.l.r.Parameter.getAnnotatedType().getType() as well as >>> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8021398/ >>> >>> The bug report is here: >>> https://bugs.openjdk.java.net/browse/JDK-8021398 >>> >> >> Fix looks mostly fine, but please use the shared array on line 47 >> instead of allocating a new one. >> >> Also you lack a test, adopt the test from the bug and add it to >> jdk/test/java/lang/annotations/typeAnnotations/ >> >> cheers >> /Joel >> > From Alan.Bateman at oracle.com Tue Oct 1 18:50:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Oct 2013 11:50:33 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> Message-ID: <524B1979.3020106@oracle.com> On 01/10/2013 11:31, Brian Burkhalter wrote: > Hello net-dev members, > > Please review this proposed fix at your convenience. > > Summary > When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. > > Issue > https://bugs.openjdk.java.net/browse/JDK-8010371 > > Webrev > http://cr.openjdk.java.net/~bpb/8010371 > > So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno set to EAGAIN? I also wonder if the EAGAIN means the underlying syscall has been interrupted, in which case the normal thing to do is to retry. -Alan From roger.riggs at oracle.com Tue Oct 1 18:51:08 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Oct 2013 14:51:08 -0400 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: References: <523DF05E.5020009@oracle.com> Message-ID: <524B199C.9000309@oracle.com> Hi Stephen, The proposed approach makes sense to me, shall I take the patch as is or wait to integrate until for the mentioned update of effective chrono? Thanks, Roger On 9/22/2013 10:27 AM, Stephen Colebourne wrote: > The patch only changes the text of one of the two appendValueReduced > methods. The patch does not handle week based years or provide for > users to add their own year fields. It also does not handle > formatting. > > After much thinking, I think the right solution is to add a new > appendValueReduced method where "int baseValue" is replaced by > "ChronoLocalDate baseDate". The new method would be used if you want > year-like fields in multiple chronologies to work. The appendPattern > method would be changed to use the new date variant for y/u/W > > The first of the two existing appendValueReduced methods can be > removed as a simplification. > > Patch here: > https://gist.github.com/jodastephen/6660394 > > Note that this patch still has a bug, as the effective chrono is not > determined fully until the end of the parsing phase. However, that bug > fix requires a bit of an internal redesign and since it does not > affect the API it can be delayed, > > Stephen > > > > > On 21 September 2013 20:15, roger riggs wrote: >> Hi, >> >> The java.time reduced value parser does work as expected (issue 8024076) >> for chronologies other than ISO. >> The base value is assumed to be chronology independent but is not >> converted to the requested Chronology before it is used. >> >> Please review: >> >> http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8024076 >> From roger.riggs at oracle.com Tue Oct 1 18:53:47 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Oct 2013 14:53:47 -0400 Subject: Review java.time test refactoring In-Reply-To: References: <523A1BCF.3030001@oracle.com> Message-ID: <524B1A3B.8000203@oracle.com> Ping, needs a Reviewer. http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/ Updated the webrev with the renamed test classes to distinguish them from the non-serialization tests in a different package. Thanks, Roger On 9/23/2013 11:04 AM, Stephen Colebourne wrote: > The change looks fine AFAICT. I would prefer to see the new serial > package test classes have names that end in "Serialization", eg > "TCKLocalDateSerialization", but if that does not happen it is not the > end of the world. > Stephen > > > On 18 September 2013 22:31, roger riggs wrote: >> A review of the TCK tests for java.time resulted in a number of changes >> including refactoring the serialization tests into subpackages to follow JCK >> conventions, >> discovery that a number of tests were missing for serialization, and cleanup >> of the test code to utilize common test functions for testing serialization. >> Thanks to the JCK folks for identifying the issues and doing some of the >> refactoring. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/ >> >> * JDK-8024896 >> Refactor java.time serialization tests into separate subpackage >> >> * JDK-8024427 >> Missing java.time.chrono serialization tests >> >> Thanks, Roger >> From eric.mccorkle at oracle.com Tue Oct 1 18:58:32 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 01 Oct 2013 14:58:32 -0400 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524B1590.90702@oracle.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> <524B11F0.2070702@oracle.com> <524B1590.90702@oracle.com> Message-ID: <524B1B58.4080305@oracle.com> Thanks all, committing after successful tests. On 10/01/13 14:33, Joe Darcy wrote: > Looks fine; cheers, > > -Joe > > On 10/1/2013 11:18 AM, Eric McCorkle wrote: >> I forgot to hg add the test. I've addressed your and others' comments, >> and refreshed the webrev. Please review. >> >> On 10/01/13 04:06, Joel Borggren-Franck wrote: >>> Hi Eric, >>> >>> Thanks for fixing this. >>> >>> On 2013-10-01, Eric McCorkle wrote: >>>> Hello, please review this simple patch which fixes a problem in the >>>> type >>>> annotations handling API. This manifests as a problem with both >>>> j.l.r.Parameter.getAnnotatedType().getType() as well as >>>> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8021398/ >>>> >>>> The bug report is here: >>>> https://bugs.openjdk.java.net/browse/JDK-8021398 >>>> >>> Fix looks mostly fine, but please use the shared array on line 47 >>> instead of allocating a new one. >>> >>> Also you lack a test, adopt the test from the bug and add it to >>> jdk/test/java/lang/annotations/typeAnnotations/ >>> >>> cheers >>> /Joel >>> > From brian.burkhalter at oracle.com Tue Oct 1 18:59:55 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Oct 2013 11:59:55 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524B1979.3020106@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> Message-ID: <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote: > On 01/10/2013 11:31, Brian Burkhalter wrote: >> Hello net-dev members, >> >> Please review this proposed fix at your convenience. >> >> Summary >> When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8010371 >> >> Webrev >> http://cr.openjdk.java.net/~bpb/8010371 >> >> > So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno set to EAGAIN? It seems a bit unclear to me and to depend on which system one is on. There is also the possibility apparently of it returning EAI_AGAIN. It might be best to test both the return value and if that is EAI_SYSTEM to test errno. > I also wonder if the EAGAIN means the underlying syscall has been interrupted, in which case the normal thing to do is to retry. The approach I initially was going to take was to retry once after a short wait and then fail with the proposed exception if the retry failed. This webrev was intended to provoke discussion such as this is the first time I have looked at this part of the code base and it is not clear how to actually test this situation. Brian From naoto.sato at oracle.com Tue Oct 1 19:09:36 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 01 Oct 2013 12:09:36 -0700 Subject: RFR: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java In-Reply-To: <524B188D.3080407@oracle.com> References: <524B188D.3080407@oracle.com> Message-ID: <524B1DF0.5080607@oracle.com> Hi Kumar, Just a cosmetic comment. Looks like the description columns at line 103 (and before) and line 104 (and after) do not align to each other. Otherwise it looks good to me. Naoto On 10/1/13 11:46 AM, Kumar Srinivasan wrote: > Hi Naoto, Michael, > > Please review the webrev below. Apparently using variables to hold the > common > message strings between pack200(1) and unpack200(1) utilities don't bode > well, > with the new globalization tools. Thus the request is to remove these > common > variable and inline these in the messages array. > > While doing so, I noticed that the format and whitespace was incorrect, as > this file was never touched since the TeamWare days (8+ years ago). > > So I took the liberty of fixing the format as per java coding > conventions, and fixed > up a couple of typos. > > http://cr.openjdk.java.net/~ksrini/8025342/webrev.0/ > > https://bugs.openjdk.java.net/browse/JDK-8025342 > http://bugs.sun.com/view_bug.do?bug_id=8025342 > > Thanks > > Kumar > From paul.sandoz at oracle.com Tue Oct 1 19:30:29 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 21:30:29 +0200 Subject: RFR 8025535: Unsafe typecast in java.util.stream.SortedOps Message-ID: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> Hi, Please review the following patch that checks size limits for the sorted operation and fails quickly rather than failing with an obscure ISE or an OOME later on: http://cr.openjdk.java.net/~psandoz/tl/JDK-8025535-sorted-unsafe-type-cast/webrev/ Tests have been added that assert for both SIZED and non-SIZED (at pipeline construction) inputs to sorted(). Paul. From paul.sandoz at oracle.com Tue Oct 1 19:36:48 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Oct 2013 21:36:48 +0200 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <524B11F0.2070702@oracle.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> <524B11F0.2070702@oracle.com> Message-ID: <9BE4BB28-7C6D-47CA-8FAC-E775CACE1311@oracle.com> Hi Eric, If it is not too late you could also change other references to "new TypeAnnotation[0]" in the same source file. 78 TypeAnnotation[] typeAnnotations = l.toArray(new TypeAnnotation[0]); 79 return AnnotatedTypeFactory.buildAnnotatedType(type, 80 LocationInfo.BASE_LOCATION, 81 typeAnnotations, 82 typeAnnotations, 83 decl); and 279 res[i] = AnnotatedTypeFactory.buildAnnotatedType(bounds[i], 280 loc, 281 l.toArray(new TypeAnnotation[0]), 282 candidates.toArray(new TypeAnnotation[0]), 283 (AnnotatedElement)decl); 284 } Paul. On Oct 1, 2013, at 8:18 PM, Eric McCorkle wrote: > I forgot to hg add the test. I've addressed your and others' comments, > and refreshed the webrev. Please review. > > On 10/01/13 04:06, Joel Borggren-Franck wrote: >> Hi Eric, >> >> Thanks for fixing this. >> >> On 2013-10-01, Eric McCorkle wrote: >>> Hello, please review this simple patch which fixes a problem in the type >>> annotations handling API. This manifests as a problem with both >>> j.l.r.Parameter.getAnnotatedType().getType() as well as >>> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8021398/ >>> >>> The bug report is here: >>> https://bugs.openjdk.java.net/browse/JDK-8021398 >>> >> >> Fix looks mostly fine, but please use the shared array on line 47 >> instead of allocating a new one. >> >> Also you lack a test, adopt the test from the bug and add it to >> jdk/test/java/lang/annotations/typeAnnotations/ >> >> cheers >> /Joel >> From cowwoc at bbs.darktech.org Tue Oct 1 19:45:52 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 01 Oct 2013 15:45:52 -0400 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> Message-ID: <524B2670.9050700@bbs.darktech.org> I prefer throwing exceptions on unusual conditions (e.g. overflow) and letting the user clamp the value if they so wish. Clamping will lead to unexpected behavior once values fall outside this range. Yes, it will be documented, but I daresay most applications won't ever check for it and produce incorrect results as a consequence. Gili On 01/10/2013 2:19 PM, Dmitry Nadezhin wrote: > Dear BigInteger experts, > Do you have comments to my previous message ? > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html > > > On Sat, Sep 21, 2013 at 8:13 AM, Dmitry Nadezhin > wrote: > >> It is important that BigInteger objects be full-fledged instances on which >> all methods may be correctly invoked. >> >> This bitLength bug started this discussion: >> P4 JDK-6910473 : java.math.BigInteger.bitLength() may return negative >> "int" on large numbers >> https://bugs.openjdk.java.net/browse/JDK-6910473 >> >> I reviewed the behavior of very large BigInteger objects and found a few >> other bugs: >> >> P3 JDK-8021204 : Constructor BigInteger(String val, int radix) doesn't >> detect overflow >> https://bugs.openjdk.java.net/browse/JDK-8021204 >> >> P3 JDK-8021203 : BigInteger.doubleValue/floatValue returns 0.0 instead of >> Infinity >> https://bugs.openjdk.java.net/browse/JDK-8021203 >> >> P3 JDK-8022780 : Incorrect BigInteger division because of >> MutableBigInteger.bitLength() overflow >> https://bugs.openjdk.java.net/browse/JDK-8022780 >> >> In these bugs (and also in the original bitLength bug) a BigInteger method >> silently returns an incorrect result. >> Silently incorrect behavior may lead to unexpected failures and difficult >> to debug scenarios in applications. >> >> Some applications try to adapt to these bugs with performance overhead. As >> clients of java.math.BigInteger can't trust bitLength() , they have to >> perform inefficient checks for bitLength overflow. See for example the >> methods isValidFloat, isValidDouble, bitLengthOverflow in lines 135-167 of >> this file from the Scala library: >> >> https://github.com/scala/scala/blob/master/src/library/scala/math/BigInt.scala >> >> As Brian said: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018403.html >> there are two ways to fix bitLength bug: >> a) simply by throwing an ArithmeticException if the bit length as an int >> would be negative; >> b) to define BigInteger to support a limited range and to clamp to that >> range in the constructor, >> >> throwing an ArithmeticException if the supplied parameter(s) would >> cause the BigInteger to overflow. >> This can be applied to other bugs too. >> >> We found a few bugs appearing on large BigInteger objects, but I'm not >> sure that we find all of them. >> So I prefer to limit the supported range because this not only fixes known >> bugs >> but also prevents the occurrence of bugs that haven't been discovered yet. >> >> Joe Darcy suggested that the limiting of the supported range would not be >> a specification change but instead an implementation note >> "in JDK 8, BigInteger operates on values in the range ....": >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018644.html >> >> So I prepared a patch that fixes the bitLength bug together with another >> bugs mentioned above. >> >> The WebRev is here: >> http://cr.openjdk.java.net/~bpb/BigIntRange/ >> >> This patch limits the supported range of BigInteger in JDK 8. The APIdoc >> of the class contains an implementation note that BigInteger constructors >> and operations throw an ArithmeticException when the result is out of the >> supported range. >> The supported range in JDK 8 is -2^Integer.MAX_VALUE to >> 2^Integer.MAX_VALUE, exclusive. This range is symmetric to make patch >> simpler. >> >> All constructors contains call checkRange() guarded by cheap test >> "mag.length >= MAX_MAG_LENGTH". The checkRange() method throws an >> ArithmeticException if the BigInteger instance would be out of the >> supported range. APIdocs of public constructors and methods contain an >> appropriate @throws ArithmeticException clause . >> >> The patch contains a fix of various other problems related to overflow: >> 1) Calculation of prime searchLen suffered from int overflow when >> bitLength was large; >> 2) int overflow in pow() method; >> 3) Overflow of intermediate results in modPow() method; >> 4) Removed the implementation restriction on Integer.MIN_VALUE >> in shiftLeft() and shiftRight() methods introduced during the fix of: >> JDK-6371401 : java.math.BigInteger.shift(Integer.MIN_VALUE) throws >> StackOverflowError >> https://bugs.openjdk.java.net/browse/JDK-6371401 >> >> Please, review this patch. >> >> >> >> On Wed, Jul 3, 2013 at 6:06 AM, Joseph Darcy wrote: >> >>> Hello, >>> >>> A quick note on this issue, before the recent work to use better >>> algorithms for BigInteger arithmetic operation, working with huge numbers >>> was impractical and thus BigInteger.bitLength misbehavior was mostly an >>> academic concern. With the better algorithms, exposure to these large >>> values is likely to increase so BigInteger.bitLength should do something >>> reasonable. >>> >>> There are at least two implementation limits of note in the current code: >>> >>> * Total bit length given a single backing array >>> * Max size of serializable BigInteger given old byte-array based format. >>> >>> My preference for addressing this issue includes adding an implementation >>> note along the lines of "in JDK 8, BigInteger operates on values in the >>> range ...." without requiring that range to be part of the specification. >>> >>> Cheers, >>> >>> -Joe >>> >>> >>> On 6/25/2013 6:18 PM, Brian Burkhalter wrote: >>> >>>> This request for comment regards this issue >>>> >>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6910473 >>>> BigInteger.bigLength() may return negative value for large numbers >>>> >>>> but more importantly Dmitry's thread >>>> >>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>> June/018345.html >>>> What is the range of BigInteger values? >>>> >>>> The issue may be fixed superficially simply by throwing an >>>> ArithmeticException if the bit length as an int would be negative. A better >>>> fix suggested both in the issue description and in the aforementioned >>>> thread (option 1 of 3), is to define BigInteger to support a limited range >>>> and to clamp to that range in the constructor, throwing an >>>> ArithmeticException if the supplied parameter(s) would cause the BigInteger >>>> to overflow. This check would be relatively inexpensive. The suggested >>>> constraint range is >>>> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) >>>> This constraint would guarantee that all BigInteger instances are >>>> capable of accurately returning their properties such as bit length, bit >>>> count, etc. >>>> >>>> This naturally would require a minor specification change to BigInteger. >>>> The question is whether this change would limit any future developments of >>>> this and related classes. For example, one could envision BigInteger >>>> supporting bit lengths representable by a long instead of an int. In this >>>> case the second option would be preferable. >>>> >>>> It has been suggested that an alternative to extending the ranges >>>> supported by BigInteger would be to define a different class altogether to >>>> handle the larger ranges, keeping BigInteger as a well-specified API for >>>> the ranges it supports. Other related classes for arbitrary precision >>>> binary floating point and rational numbers might also be considered. >>>> >>>> In summary the specific questions being posed here are: >>>> >>>> 1) what is the general opinion on clamping the range of BigInteger and >>>> the various options suggested at the end of >>>> >>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>> June/018345.html? >>>> >>>> 2) what are the forward looking thoughts on handling integers outside >>>> the current BigInteger range? >>>> >>>> From a practical point of view, any changes need to be considered with >>>> respect to what may be done in the short term (JDK 8) versus the long (JDK >>>> 9), so to speak. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>> From brian.burkhalter at oracle.com Tue Oct 1 19:46:35 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Oct 2013 12:46:35 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> Message-ID: <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> On Oct 1, 2013, at 11:59 AM, Brian Burkhalter wrote: > It seems a bit unclear to me and to depend on which system one is on. There is also the possibility apparently of it returning EAI_AGAIN. It might be best to test both the return value and if that is EAI_SYSTEM to test errno. I updated the webrev http://cr.openjdk.java.net/~bpb/8010371/ with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. Brian From kumar.x.srinivasan at oracle.com Tue Oct 1 19:53:26 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 01 Oct 2013 12:53:26 -0700 Subject: RFR: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java In-Reply-To: <524B1DF0.5080607@oracle.com> References: <524B188D.3080407@oracle.com> <524B1DF0.5080607@oracle.com> Message-ID: <524B2836.2090002@oracle.com> > Hi Kumar, > > Just a cosmetic comment. Looks like the description columns at line > 103 (and before) and line 104 (and after) do not align to each other. yes indeed, I will fix that. Thanks Naoto! Kumar > > Otherwise it looks good to me. > > Naoto > > On 10/1/13 11:46 AM, Kumar Srinivasan wrote: >> Hi Naoto, Michael, >> >> Please review the webrev below. Apparently using variables to hold the >> common >> message strings between pack200(1) and unpack200(1) utilities don't bode >> well, >> with the new globalization tools. Thus the request is to remove these >> common >> variable and inline these in the messages array. >> >> While doing so, I noticed that the format and whitespace was >> incorrect, as >> this file was never touched since the TeamWare days (8+ years ago). >> >> So I took the liberty of fixing the format as per java coding >> conventions, and fixed >> up a couple of typos. >> >> http://cr.openjdk.java.net/~ksrini/8025342/webrev.0/ >> >> https://bugs.openjdk.java.net/browse/JDK-8025342 >> http://bugs.sun.com/view_bug.do?bug_id=8025342 >> >> Thanks >> >> Kumar >> > From michael.fang at oracle.com Tue Oct 1 20:08:28 2013 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 01 Oct 2013 13:08:28 -0700 Subject: RFR: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java In-Reply-To: <524B188D.3080407@oracle.com> References: <524B188D.3080407@oracle.com> Message-ID: <524B2BBC.5080003@oracle.com> Hi Kumar, Looks good. Thanks for addressing translatability conformance of this file. thanks, -michael On 13?10?01? 11:46 ??, Kumar Srinivasan wrote: > Hi Naoto, Michael, > > Please review the webrev below. Apparently using variables to hold > the common > message strings between pack200(1) and unpack200(1) utilities don't > bode well, > with the new globalization tools. Thus the request is to remove these > common > variable and inline these in the messages array. > > While doing so, I noticed that the format and whitespace was > incorrect, as > this file was never touched since the TeamWare days (8+ years ago). > > So I took the liberty of fixing the format as per java coding > conventions, and fixed > up a couple of typos. > > http://cr.openjdk.java.net/~ksrini/8025342/webrev.0/ > > https://bugs.openjdk.java.net/browse/JDK-8025342 > http://bugs.sun.com/view_bug.do?bug_id=8025342 > > Thanks > > Kumar > From mike.duigou at oracle.com Tue Oct 1 20:16:28 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 1 Oct 2013 13:16:28 -0700 Subject: RFR 8025535: Unsafe typecast in java.util.stream.SortedOps In-Reply-To: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> References: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> Message-ID: <9A029FDC-6DB2-45B9-95B2-14F637ED5009@oracle.com> Looks good to me! Mike On Oct 1 2013, at 12:30 , Paul Sandoz wrote: > Hi, > > Please review the following patch that checks size limits for the sorted operation and fails quickly rather than failing with an obscure ISE or an OOME later on: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8025535-sorted-unsafe-type-cast/webrev/ > > Tests have been added that assert for both SIZED and non-SIZED (at pipeline construction) inputs to sorted(). > > Paul. From dmitry.samersoff at oracle.com Tue Oct 1 20:17:19 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 02 Oct 2013 00:17:19 +0400 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524B1979.3020106@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> Message-ID: <524B2DCF.3070707@oracle.com> Alan, getaddrinfo is actually a shell around couple of different calls, so for getaddrinfo EAGAIN usually means that it can't rich nameserver, not the interrupted syscall. EAI_SYSTEM means that one of underlaying calls (e.g. gethostbyname) returns an error. Under Windows, getaddrinfo never returns EAI_SYSTEM, but can set WSA code other that one returned by getaddrinfo - i.e. it's recomended to use WSAGetLastError. So I'm OK with this fix. -Dmitry On 2013-10-01 22:50, Alan Bateman wrote: > On 01/10/2013 11:31, Brian Burkhalter wrote: >> Hello net-dev members, >> >> Please review this proposed fix at your convenience. >> >> Summary >> When looking up a host and an EAGAIN error is encountered, throw an >> instance of the new HostLookupException subclass of UnknownHostException. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8010371 >> >> Webrev >> http://cr.openjdk.java.net/~bpb/8010371 >> >> > So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and > errno set to EAGAIN? I also wonder if the EAGAIN means the underlying > syscall has been interrupted, in which case the normal thing to do is to > retry. > > -Alan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From michael.x.mcmahon at oracle.com Tue Oct 1 20:25:18 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 01 Oct 2013 21:25:18 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> Message-ID: <524B2FAE.4060309@oracle.com> On 01/10/13 19:59, Brian Burkhalter wrote: > On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote: > >> On 01/10/2013 11:31, Brian Burkhalter wrote: >>> Hello net-dev members, >>> >>> Please review this proposed fix at your convenience. >>> >>> Summary >>> When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. >>> >>> Issue >>> https://bugs.openjdk.java.net/browse/JDK-8010371 >>> >>> Webrev >>> http://cr.openjdk.java.net/~bpb/8010371 >>> >>> >> So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno set to EAGAIN? > It seems a bit unclear to me and to depend on which system one is on. There is also the possibility apparently of it returning EAI_AGAIN. It might be best to test both the return value and if that is EAI_SYSTEM to test errno. > >> I also wonder if the EAGAIN means the underlying syscall has been interrupted, in which case the normal thing to do is to retry. > The approach I initially was going to take was to retry once after a short wait and then fail with the proposed exception if the retry failed. I'm not sure about the short wait. I know the submitter claims that it worked after 50ms, but I don't think we could generalise that behavior in the library. Maybe, there is value in repeating immediately, though it is less likely the temporary condition will have resolved. Michael > This webrev was intended to provoke discussion such as this is the first time I have looked at this part of the code base and it is not clear how to actually test this situation. > > Brian From brian.burkhalter at oracle.com Tue Oct 1 20:27:23 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Oct 2013 13:27:23 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524B2FAE.4060309@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <524B2FAE.4060309@oracle.com> Message-ID: On Oct 1, 2013, at 1:25 PM, Michael McMahon wrote: >> The approach I initially was going to take was to retry once after a short wait and then fail with the proposed exception if the retry failed. > > I'm not sure about the short wait. I know the submitter claims that it worked after 50ms, but I don't > think we could generalise that behavior in the library. Maybe, there is value in repeating immediately, though > it is less likely the temporary condition will have resolved. It does seem better to let the calling code retry if it wants based on the class of the exception. Brian From eric.mccorkle at oracle.com Tue Oct 1 20:27:58 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 01 Oct 2013 16:27:58 -0400 Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions In-Reply-To: <524A6E83.5000802@oracle.com> References: <5233260C.3010607@oracle.com> <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com> <52334CED.1030900@oracle.com> <52335156.3050308@gmail.com> <52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com> <523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com> <523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com> <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com> <5241E4CB.5030807@oracle.com> <524A6E83.5000802@oracle.com> Message-ID: <524B304E.1090601@oracle.com> On 10/01/13 02:41, Joe Darcy wrote: (Suggested changes have been applied) > > I think the test is acceptable as-is, but an RFE could be filed for some > refactoring (having each bad class be represented as a diff from a base > byte[], avoiding sending the bytes through the file system). > Better yet: I've filed an RFE for a framework for generating bad class files. Webrev has been updated, please review: http://cr.openjdk.java.net/~emc/8020981/ > Cheers, > > -Joe > > On 9/24/2013 12:15 PM, Eric McCorkle wrote: >> Webrev updated to address these issues. >> >> On 09/24/13 07:51, Joel Borggren-Franck wrote: >> >>> 364 try { >>> 365 tmp = getParameters0(); >>> 366 } catch(IllegalArgumentException e) { >>> 367 // Rethrow ClassFormatErrors >>> 368 throw new MalformedParametersException("Invalid >>> constant pool index"); >>> 369 } >>> >>> What is causing the IAE? Have you considered having >>> MalformedParametersExcepton taking a Throwable cause and having the IAE >>> as cause? >>> >> The IAE comes from hotspot itself. There is a standard constant pool >> index verifying function that throws IAE if given a bad index. >> >>> On 2013-09-19, Eric McCorkle wrote: >>>> The webrev has been updated with Joe's comments addressed. >>>> >>>> On 09/19/13 00:11, David Holmes wrote: >>>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote: >>>>>> This still needs to be reviewed. >>>>> You seem to have ignored Joe's comments regarding the change to >>>>> Modifier >>>>> being incorrect. >>>>> >>>>> David >>>>> >>>>>> On 09/16/13 14:50, Eric McCorkle wrote: >>>>>>> I pulled the class files into byte array constants, as a temporary >>>>>>> measure until a viable method for testing bad class files is >>>>>>> developed. >>>>>>> >>>>>>> The webrev has been refreshed. The class files will be taken out >>>>>>> before >>>>>>> I push. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>> >>>>>>> On 09/13/13 20:48, Joe Darcy wrote: >>>>>>>> To avoid storing binaries in Hg, you could try something like: >>>>>>>> >>>>>>>> * uuencode / ascii armor the class file >>>>>>>> * convert to byte array in the test >>>>>>>> * load classes from byte array >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote: >>>>>>>>> I did it by hand with emacs. >>>>>>>>> >>>>>>>>> I would really rather tackle the bad class files for testing issue >>>>>>>>> once >>>>>>>>> and for all, the Right Way (tm). But with ZBB looming, now is >>>>>>>>> not the >>>>>>>>> time to do it. >>>>>>>>> >>>>>>>>> Hence, I have created this task >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674 >>>>>>>>> >>>>>>>>> I also just created this one: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812 >>>>>>>>> >>>>>>>>> On 09/13/13 13:54, Peter Levart wrote: >>>>>>>>>> Hi Eric, >>>>>>>>>> >>>>>>>>>> How did you create those class files? By hand using a HEX >>>>>>>>>> editor? Did >>>>>>>>>> you create a program that patched the original class file? If the >>>>>>>>>> later >>>>>>>>>> is the case, you could pack that patching logic inside a custom >>>>>>>>>> ClassLoader... >>>>>>>>>> >>>>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad >>>>>>>>>> name" >>>>>>>>>> patching could be performed trivially and reliably, I think: >>>>>>>>>> search and >>>>>>>>>> replace with same-length string. >>>>>>>>>> >>>>>>>>>> Regards, Peter >>>>>>>>>> >>>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote: >>>>>>>>>>> Ugh. Byte arrays of class file data is really a horrible >>>>>>>>>>> solution. >>>>>>>>>>> >>>>>>>>>>> I have already filed a task for test development post ZBB to >>>>>>>>>>> develop a >>>>>>>>>>> solution for generating bad class files. I'd prefer to file a >>>>>>>>>>> follow-up >>>>>>>>>>> to this to add the bad class file tests when that's done. >>>>>>>>>>> >>>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>> I think the right thing to do is to include the original >>>>>>>>>>>> compiling >>>>>>>>>>>> source in a comment, together with a comment on how you modify >>>>>>>>>>>> them, and then the result as a byte array. >>>>>>>>>>>> >>>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our >>>>>>>>>>>> repo. >>>>>>>>>>>> >>>>>>>>>>>> cheers >>>>>>>>>>>> /Joel >>>>>>>>>>>> >>>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> There is no simple means of generating bad class files for >>>>>>>>>>>>> testing. >>>>>>>>>>>>> This is a huge deficiency in our testing abilities. >>>>>>>>>>>>> >>>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no >>>>>>>>>>>>> choice >>>>>>>>>>>>> but >>>>>>>>>>>>> to check in no test for this patch. >>>>>>>>>>>>> >>>>>>>>>>>>> However, anyone can run the test I've provided with the class >>>>>>>>>>>>> files and >>>>>>>>>>>>> see that it works. >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>> >>>>>>>>>>>>>> IIRC we don't check in classfiles into the repo. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files >>>>>>>>>>>>>> in jdk, >>>>>>>>>>>>>> but ASM might be an option, or storing the class file as an >>>>>>>>>>>>>> embedded byte array in the test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> cheers >>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which >>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>> validates >>>>>>>>>>>>>>> parameter names correctly. Apologies for the last one. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review this patch, which implements correct >>>>>>>>>>>>>>>> behavior for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class >>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The bug report is here: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The webrev is here: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This review is also on crucible. The ID is CR-JDK8TL-182. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>>> >>>>>>>>>>>>> > From eric.mccorkle at oracle.com Tue Oct 1 20:31:42 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 01 Oct 2013 16:31:42 -0400 Subject: Review request for JDK-8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null In-Reply-To: <9BE4BB28-7C6D-47CA-8FAC-E775CACE1311@oracle.com> References: <524A75E8.30206@oracle.com> <20131001080604.GD1969@jfranck-desktop.jrpg.bea.com> <524B11F0.2070702@oracle.com> <9BE4BB28-7C6D-47CA-8FAC-E775CACE1311@oracle.com> Message-ID: <524B312E.2020309@oracle.com> I am already running pre-commit tests, but I have another upcoming reflection API patch, and I could do this as part of that one. On 10/01/13 15:36, Paul Sandoz wrote: > Hi Eric, > > If it is not too late you could also change other references to "new TypeAnnotation[0]" in the same source file. > > 78 TypeAnnotation[] typeAnnotations = l.toArray(new TypeAnnotation[0]); > 79 return AnnotatedTypeFactory.buildAnnotatedType(type, > 80 LocationInfo.BASE_LOCATION, > 81 typeAnnotations, > 82 typeAnnotations, > 83 decl); > > and > > 279 res[i] = AnnotatedTypeFactory.buildAnnotatedType(bounds[i], > 280 loc, > 281 l.toArray(new TypeAnnotation[0]), > 282 candidates.toArray(new TypeAnnotation[0]), > 283 (AnnotatedElement)decl); > 284 } > > Paul. > > On Oct 1, 2013, at 8:18 PM, Eric McCorkle wrote: > >> I forgot to hg add the test. I've addressed your and others' comments, >> and refreshed the webrev. Please review. >> >> On 10/01/13 04:06, Joel Borggren-Franck wrote: >>> Hi Eric, >>> >>> Thanks for fixing this. >>> >>> On 2013-10-01, Eric McCorkle wrote: >>>> Hello, please review this simple patch which fixes a problem in the type >>>> annotations handling API. This manifests as a problem with both >>>> j.l.r.Parameter.getAnnotatedType().getType() as well as >>>> j.l.r.Executable.getAnnotatedParameterTypes().getType(). >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8021398/ >>>> >>>> The bug report is here: >>>> https://bugs.openjdk.java.net/browse/JDK-8021398 >>>> >>> >>> Fix looks mostly fine, but please use the shared array on line 47 >>> instead of allocating a new one. >>> >>> Also you lack a test, adopt the test from the bug and add it to >>> jdk/test/java/lang/annotations/typeAnnotations/ >>> >>> cheers >>> /Joel >>> > From eric.mccorkle at oracle.com Tue Oct 1 21:27:00 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:27:00 +0000 Subject: hg: jdk8/tl/jdk: 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Message-ID: <20131001212712.1AB2F62C75@hg.openjdk.java.net> Changeset: 1ed675532589 Author: vlivanov Date: 2013-09-18 20:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ed675532589 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Reviewed-by: jrose ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java From eric.mccorkle at oracle.com Tue Oct 1 21:36:18 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:36:18 +0000 Subject: hg: jdk8/tl/jdk: 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Message-ID: <20131001213630.DA85162C78@hg.openjdk.java.net> Changeset: bf1118ab775b Author: emc Date: 2013-10-01 17:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf1118ab775b 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Summary: Fixed issue with type annotation reflection framework that would cause getType of AnnotatedTypes to be null if no annotations were present. Reviewed-by: darcy, jfranck ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java From eric.mccorkle at oracle.com Tue Oct 1 21:43:01 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:43:01 +0000 Subject: hg: jdk8/tl/langtools: 8021339: Compile-time error during casting array to intersection Message-ID: <20131001214305.099F362C79@hg.openjdk.java.net> Changeset: de1c5dbe6c28 Author: emc Date: 2013-10-01 17:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/de1c5dbe6c28 8021339: Compile-time error during casting array to intersection Summary: Add ability to have arrays in intersection types. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/ArraysInIntersections.java + test/tools/javac/InferArraysInIntersections.java ! test/tools/javac/generics/typevars/6680106/T6680106.out From eric.mccorkle at oracle.com Tue Oct 1 21:24:14 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:24:14 +0000 Subject: hg: jdk8/tl/jdk: 8001107: @Stable annotation for constant folding of lazily evaluated variables Message-ID: <20131001212426.B496562C73@hg.openjdk.java.net> Changeset: 5a7bd9825c01 Author: vlivanov Date: 2013-09-23 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a7bd9825c01 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: twisti, kvn, rbackman Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/Stable.java From kumar.x.srinivasan at oracle.com Tue Oct 1 22:42:31 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 01 Oct 2013 22:42:31 +0000 Subject: hg: jdk8/tl/jdk: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Message-ID: <20131001224245.5328862C7B@hg.openjdk.java.net> Changeset: 84e7f6685319 Author: ksrini Date: 2013-10-01 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84e7f6685319 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Reviewed-by: naoto, mfang ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource.java From henry.jen at oracle.com Tue Oct 1 23:04:04 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 01 Oct 2013 16:04:04 -0700 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> Message-ID: <524B54E4.9010506@oracle.com> Hi, Please review the updated webrev at http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ This update addressed comments from Mandy with following, - call doPrivileged with specific file permission, "<>", "write". - Use nio package to write deal with FS, also create directory hierarchy with package name instead of flat files. - If not specify a value or empty string, the directory is default to current working directory as "." is specified. We continue to use local encoding rule as other suggestions doesn't fit. The reason we cannot use something like URLEncoder is that ":" won't get encoded and it's not valid character for filename on Windows. All the suggestions so far seems to have that same issue. Cheers, Henry From forax at univ-mlv.fr Tue Oct 1 23:54:31 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 02 Oct 2013 01:54:31 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524B54E4.9010506@oracle.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> Message-ID: <524B60B7.1060905@univ-mlv.fr> On 10/02/2013 01:04 AM, Henry Jen wrote: > Hi, > > Please review the updated webrev at > http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ > > This update addressed comments from Mandy with following, > > - call doPrivileged with specific file permission, "<>", "write". > - Use nio package to write deal with FS, also create directory hierarchy > with package name instead of flat files. > - If not specify a value or empty string, the directory is default to > current working directory as "." is specified. > > We continue to use local encoding rule as other suggestions doesn't fit. > The reason we cannot use something like URLEncoder is that ":" won't get > encoded and it's not valid character for filename on Windows. All the > suggestions so far seems to have that same issue. > > Cheers, > Henry > Hi Henry, most of the code that use atomic values is not needed if you do all these checks in the static block (because the static block is protected by a lock) and also instead of injecting the dump_dir, I think it's better to ask for it in ProxyClassesDumper. so first, nitpicking!, DUMP_PATH_PROPERTY doesn't need to be a static field, the code below is equivalent to yours but avoid to create yet another static field. // For dumping generated classes to disk, for debugging purposes /* package */ static final String LAMBDA_PROXY_DUMP_DIR; static { String DUMP_PATH_PROPERTY = "jdk.internal.lambda.dumpProxyClasses"; LAMBDA_PROXY_DUMP_DIR= AccessController.doPrivileged(new GetPropertyAction(DUMP_PATH_PROPERTY)); } // If requested, dump out to a file for debugging purposes if (LAMBDA_PROXY_DUMP_DIR != null) { AccessController.doPrivileged(new PrivilegedAction() { @Override public Void run() { ProxyClassesDumper dumper = ProxyClassesDumper.getInstance(); // dont send DUMP_DIR here ... then as I said the code in ProxyClassesDumper can be simplified if instead of sending the dump directory, the ProxyClassesDumper ask for it. final class ProxyClassesDumper { ... private final static ProxyClassesDumper INSTANCE; static { // ProxyClassesDumper.getInstance() should never be called // in the static block of InnerClassLambdaMetafactory // because it will create a circular dependency (a NPE) String pathname = InnerClassLambdaMetafactory.LAMBDA_PROXY_DUMP_DIR.trim(); Path dumpDir = Paths.get(pathname.isEmpty() ? "." : pathname); dumpDir = validateDumpDir(dumpDir)? dumpDir: null; INSTANCE = new ProxyClassesDumper(dumpDir); } private final Path dumpDir; // null if invalid // implement dump singleton instance, that's all we need right now public static ProxyClassesDumper getInstance() { return INSTANCE; } private ProxyClassesDumper(String path) { this.path = path; } private static boolean validateDumpDir(Path path) { String errMsg; // no need to initialize errMsg here if (!Files.exists(path)) { ... public void dumpClass(String className, final byte[] classBytes) { if (dumpDir == null) { // invalid dump directory, silently ignore it return; } ... cheers, R?mi From john.r.rose at oracle.com Wed Oct 2 00:24:52 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 17:24:52 -0700 Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 References: Message-ID: <63797DB1-F637-4A0F-9AE1-7E600747F05B@oracle.com> (Cross-posting RFR.) From: John Rose Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 Date: October 1, 2013 3:19:30 PM PDT To: Da Vinci Machine Project Cc: "hotspot-compiler-dev at openjdk.java.net compiler" http://cr.openjdk.java.net/~jrose/8024438/webrev.00 These are miscellaneous edits to javadoc and unit tests, clarifying various minor corner cases and improving presentation. There is also a single API change (already under review by CCC): Adding a missing wildcard to Constructor. Please review. Thanks, ? John From john.r.rose at oracle.com Wed Oct 2 00:25:46 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 17:25:46 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> Message-ID: <36ABF7A3-C844-4AD2-9EE6-4599A4CD2E5C@oracle.com> (Cross-post.) From: John Rose Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity Date: October 1, 2013 3:15:24 PM PDT To: Da Vinci Machine Project Cc: "hotspot-compiler-dev at openjdk.java.net compiler" This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. It also adjusts some unit tests. The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. http://cr.openjdk.java.net/~jrose/8025112/webrev.00 For more background, see my JavaOne presentation: http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf Thanks, ? John From dmitry.nadezhin at gmail.com Wed Oct 2 01:25:55 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Wed, 2 Oct 2013 05:25:55 +0400 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <524B2670.9050700@bbs.darktech.org> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> Message-ID: I see that I misused the word "to clamp" in this discussion. I guess that addition with "clumping" means: return x + y < MIN_VALUE ? MIN_VALUE : x + y > MAX_VALUE ? MAX_VALUE : x + y; The patch actually throws ArithmeticException on overflow: if (x + y < MIN_VALUE || x + y > MAX_VALUE) throw new ArithmetiException(); else return x + y; The word "clamp" appeared in the discussion only. Comments in the patch don't contain it. They say: BigInteger constructors and operations throw {@code ArithmeticException} whenthe result is out of the supported range. On Tue, Oct 1, 2013 at 11:45 PM, cowwoc wrote: > > I prefer throwing exceptions on unusual conditions (e.g. overflow) and > letting the user clamp the value if they so wish. Clamping will lead to > unexpected behavior once values fall outside this range. Yes, it will be > documented, but I daresay most applications won't ever check for it and > produce incorrect results as a consequence. > > Gili > > > On 01/10/2013 2:19 PM, Dmitry Nadezhin wrote: > >> Dear BigInteger experts, >> Do you have comments to my previous message ? >> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >> September/021264.html >> >> >> On Sat, Sep 21, 2013 at 8:13 AM, Dmitry Nadezhin >> **wrote: >> >> It is important that BigInteger objects be full-fledged instances on >>> which >>> all methods may be correctly invoked. >>> >>> This bitLength bug started this discussion: >>> P4 JDK-6910473 : java.math.BigInteger.**bitLength() may return negative >>> "int" on large numbers >>> https://bugs.openjdk.java.net/**browse/JDK-6910473 >>> >>> I reviewed the behavior of very large BigInteger objects and found a few >>> other bugs: >>> >>> P3 JDK-8021204 : Constructor BigInteger(String val, int radix) doesn't >>> detect overflow >>> https://bugs.openjdk.java.net/**browse/JDK-8021204 >>> >>> P3 JDK-8021203 : BigInteger.doubleValue/**floatValue returns 0.0 >>> instead of >>> Infinity >>> https://bugs.openjdk.java.net/**browse/JDK-8021203 >>> >>> P3 JDK-8022780 : Incorrect BigInteger division because of >>> MutableBigInteger.bitLength() overflow >>> https://bugs.openjdk.java.net/**browse/JDK-8022780 >>> >>> In these bugs (and also in the original bitLength bug) a BigInteger >>> method >>> silently returns an incorrect result. >>> Silently incorrect behavior may lead to unexpected failures and difficult >>> to debug scenarios in applications. >>> >>> Some applications try to adapt to these bugs with performance overhead. >>> As >>> clients of java.math.BigInteger can't trust bitLength() , they have to >>> perform inefficient checks for bitLength overflow. See for example the >>> methods isValidFloat, isValidDouble, bitLengthOverflow in lines 135-167 >>> of >>> this file from the Scala library: >>> >>> https://github.com/scala/**scala/blob/master/src/library/** >>> scala/math/BigInt.scala >>> >>> As Brian said: >>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>> June/018403.html >>> there are two ways to fix bitLength bug: >>> a) simply by throwing an ArithmeticException if the bit length as an int >>> would be negative; >>> b) to define BigInteger to support a limited range and to clamp to that >>> range in the constructor, >>> >>> throwing an ArithmeticException if the supplied parameter(s) would >>> cause the BigInteger to overflow. >>> This can be applied to other bugs too. >>> >>> We found a few bugs appearing on large BigInteger objects, but I'm not >>> sure that we find all of them. >>> So I prefer to limit the supported range because this not only fixes >>> known >>> bugs >>> but also prevents the occurrence of bugs that haven't been discovered >>> yet. >>> >>> Joe Darcy suggested that the limiting of the supported range would not be >>> a specification change but instead an implementation note >>> "in JDK 8, BigInteger operates on values in the range ....": >>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>> July/018644.html >>> >>> So I prepared a patch that fixes the bitLength bug together with another >>> bugs mentioned above. >>> >>> The WebRev is here: >>> http://cr.openjdk.java.net/~**bpb/BigIntRange/ >>> >>> This patch limits the supported range of BigInteger in JDK 8. The APIdoc >>> of the class contains an implementation note that BigInteger constructors >>> and operations throw an ArithmeticException when the result is out of the >>> supported range. >>> The supported range in JDK 8 is -2^Integer.MAX_VALUE to >>> 2^Integer.MAX_VALUE, exclusive. This range is symmetric to make patch >>> simpler. >>> >>> All constructors contains call checkRange() guarded by cheap test >>> "mag.length >= MAX_MAG_LENGTH". The checkRange() method throws an >>> ArithmeticException if the BigInteger instance would be out of the >>> supported range. APIdocs of public constructors and methods contain an >>> appropriate @throws ArithmeticException clause . >>> >>> The patch contains a fix of various other problems related to overflow: >>> 1) Calculation of prime searchLen suffered from int overflow when >>> bitLength was large; >>> 2) int overflow in pow() method; >>> 3) Overflow of intermediate results in modPow() method; >>> 4) Removed the implementation restriction on Integer.MIN_VALUE >>> in shiftLeft() and shiftRight() methods introduced during the fix of: >>> JDK-6371401 : java.math.BigInteger.shift(**Integer.MIN_VALUE) throws >>> StackOverflowError >>> https://bugs.openjdk.java.net/**browse/JDK-6371401 >>> >>> Please, review this patch. >>> >>> >>> >>> On Wed, Jul 3, 2013 at 6:06 AM, Joseph Darcy >>> wrote: >>> >>> Hello, >>>> >>>> A quick note on this issue, before the recent work to use better >>>> algorithms for BigInteger arithmetic operation, working with huge >>>> numbers >>>> was impractical and thus BigInteger.bitLength misbehavior was mostly an >>>> academic concern. With the better algorithms, exposure to these large >>>> values is likely to increase so BigInteger.bitLength should do something >>>> reasonable. >>>> >>>> There are at least two implementation limits of note in the current >>>> code: >>>> >>>> * Total bit length given a single backing array >>>> * Max size of serializable BigInteger given old byte-array based format. >>>> >>>> My preference for addressing this issue includes adding an >>>> implementation >>>> note along the lines of "in JDK 8, BigInteger operates on values in the >>>> range ...." without requiring that range to be part of the >>>> specification. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> >>>> On 6/25/2013 6:18 PM, Brian Burkhalter wrote: >>>> >>>> This request for comment regards this issue >>>>> >>>>> http://bugs.sun.com/****bugdatabase/view_bug.do?bug_****id=6910473 >>>>> >>>>> > >>>>> >>>>> BigInteger.bigLength() may return negative value for large numbers >>>>> >>>>> but more importantly Dmitry's thread >>>>> >>>>> http://mail.openjdk.java.net/****pipermail/core-libs-dev/2013-**** >>>>> June/018345.html>>>> core-libs-dev/2013-June/**018345.html >>>>> > >>>>> >>>>> What is the range of BigInteger values? >>>>> >>>>> The issue may be fixed superficially simply by throwing an >>>>> ArithmeticException if the bit length as an int would be negative. A >>>>> better >>>>> fix suggested both in the issue description and in the aforementioned >>>>> thread (option 1 of 3), is to define BigInteger to support a limited >>>>> range >>>>> and to clamp to that range in the constructor, throwing an >>>>> ArithmeticException if the supplied parameter(s) would cause the >>>>> BigInteger >>>>> to overflow. This check would be relatively inexpensive. The suggested >>>>> constraint range is >>>>> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) >>>>> This constraint would guarantee that all BigInteger instances are >>>>> capable of accurately returning their properties such as bit length, >>>>> bit >>>>> count, etc. >>>>> >>>>> This naturally would require a minor specification change to >>>>> BigInteger. >>>>> The question is whether this change would limit any future >>>>> developments of >>>>> this and related classes. For example, one could envision BigInteger >>>>> supporting bit lengths representable by a long instead of an int. In >>>>> this >>>>> case the second option would be preferable. >>>>> >>>>> It has been suggested that an alternative to extending the ranges >>>>> supported by BigInteger would be to define a different class >>>>> altogether to >>>>> handle the larger ranges, keeping BigInteger as a well-specified API >>>>> for >>>>> the ranges it supports. Other related classes for arbitrary precision >>>>> binary floating point and rational numbers might also be considered. >>>>> >>>>> In summary the specific questions being posed here are: >>>>> >>>>> 1) what is the general opinion on clamping the range of BigInteger and >>>>> the various options suggested at the end of >>>>> >>>>> http://mail.openjdk.java.net/****pipermail/core-libs-dev/2013-**** >>>>> June/018345.html>>>> core-libs-dev/2013-June/**018345.html >>>>> >? >>>>> >>>>> >>>>> 2) what are the forward looking thoughts on handling integers outside >>>>> the current BigInteger range? >>>>> >>>>> From a practical point of view, any changes need to be considered >>>>> with >>>>> respect to what may be done in the short term (JDK 8) versus the long >>>>> (JDK >>>>> 9), so to speak. >>>>> >>>>> Thanks, >>>>> >>>>> Brian >>>>> >>>>> >>>> > From john.r.rose at oracle.com Wed Oct 2 02:23:45 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 02 Oct 2013 02:23:45 +0000 Subject: hg: jdk8/tl/jdk: 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Message-ID: <20131002022421.327E062C86@hg.openjdk.java.net> Changeset: d90928a89af5 Author: drchase Date: 2013-09-27 13:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d90928a89af5 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Summary: Inserted code to convert specific exceptions, case-by-case, plus a test. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/8022701/BogoLoader.java + test/java/lang/invoke/8022701/InvokeSeveralWays.java + test/java/lang/invoke/8022701/Invoker.java + test/java/lang/invoke/8022701/MHIllegalAccess.java + test/java/lang/invoke/8022701/MethodSupplier.java From cowwoc at bbs.darktech.org Wed Oct 2 02:50:25 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 01 Oct 2013 22:50:25 -0400 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> Message-ID: <524B89F1.7090602@bbs.darktech.org> Sounds good. Thanks for the clarification. Gili On 01/10/2013 9:25 PM, Dmitry Nadezhin wrote: > I see that I misused the word "to clamp" in this discussion. > I guess that addition with "clumping" means: > return x + y < MIN_VALUE ? MIN_VALUE : x + y > MAX_VALUE ? MAX_VALUE : x + > y; > > The patch actually throws ArithmeticException on overflow: > if (x + y < MIN_VALUE || x + y > MAX_VALUE) throw new ArithmetiException(); > else return x + y; > > The word "clamp" appeared in the discussion only. > Comments in the patch don't contain it. They say: > > BigInteger constructors and operations throw {@code > ArithmeticException} whenthe result is out of the supported range. > > > > > On Tue, Oct 1, 2013 at 11:45 PM, cowwoc wrote: > >> I prefer throwing exceptions on unusual conditions (e.g. overflow) and >> letting the user clamp the value if they so wish. Clamping will lead to >> unexpected behavior once values fall outside this range. Yes, it will be >> documented, but I daresay most applications won't ever check for it and >> produce incorrect results as a consequence. >> >> Gili >> >> >> On 01/10/2013 2:19 PM, Dmitry Nadezhin wrote: >> >>> Dear BigInteger experts, >>> Do you have comments to my previous message ? >>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>> September/021264.html >>> >>> >>> On Sat, Sep 21, 2013 at 8:13 AM, Dmitry Nadezhin >>> **wrote: >>> >>> It is important that BigInteger objects be full-fledged instances on >>>> which >>>> all methods may be correctly invoked. >>>> >>>> This bitLength bug started this discussion: >>>> P4 JDK-6910473 : java.math.BigInteger.**bitLength() may return negative >>>> "int" on large numbers >>>> https://bugs.openjdk.java.net/**browse/JDK-6910473 >>>> >>>> I reviewed the behavior of very large BigInteger objects and found a few >>>> other bugs: >>>> >>>> P3 JDK-8021204 : Constructor BigInteger(String val, int radix) doesn't >>>> detect overflow >>>> https://bugs.openjdk.java.net/**browse/JDK-8021204 >>>> >>>> P3 JDK-8021203 : BigInteger.doubleValue/**floatValue returns 0.0 >>>> instead of >>>> Infinity >>>> https://bugs.openjdk.java.net/**browse/JDK-8021203 >>>> >>>> P3 JDK-8022780 : Incorrect BigInteger division because of >>>> MutableBigInteger.bitLength() overflow >>>> https://bugs.openjdk.java.net/**browse/JDK-8022780 >>>> >>>> In these bugs (and also in the original bitLength bug) a BigInteger >>>> method >>>> silently returns an incorrect result. >>>> Silently incorrect behavior may lead to unexpected failures and difficult >>>> to debug scenarios in applications. >>>> >>>> Some applications try to adapt to these bugs with performance overhead. >>>> As >>>> clients of java.math.BigInteger can't trust bitLength() , they have to >>>> perform inefficient checks for bitLength overflow. See for example the >>>> methods isValidFloat, isValidDouble, bitLengthOverflow in lines 135-167 >>>> of >>>> this file from the Scala library: >>>> >>>> https://github.com/scala/**scala/blob/master/src/library/** >>>> scala/math/BigInt.scala >>>> >>>> As Brian said: >>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>> June/018403.html >>>> there are two ways to fix bitLength bug: >>>> a) simply by throwing an ArithmeticException if the bit length as an int >>>> would be negative; >>>> b) to define BigInteger to support a limited range and to clamp to that >>>> range in the constructor, >>>> >>>> throwing an ArithmeticException if the supplied parameter(s) would >>>> cause the BigInteger to overflow. >>>> This can be applied to other bugs too. >>>> >>>> We found a few bugs appearing on large BigInteger objects, but I'm not >>>> sure that we find all of them. >>>> So I prefer to limit the supported range because this not only fixes >>>> known >>>> bugs >>>> but also prevents the occurrence of bugs that haven't been discovered >>>> yet. >>>> >>>> Joe Darcy suggested that the limiting of the supported range would not be >>>> a specification change but instead an implementation note >>>> "in JDK 8, BigInteger operates on values in the range ....": >>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>> July/018644.html >>>> >>>> So I prepared a patch that fixes the bitLength bug together with another >>>> bugs mentioned above. >>>> >>>> The WebRev is here: >>>> http://cr.openjdk.java.net/~**bpb/BigIntRange/ >>>> >>>> This patch limits the supported range of BigInteger in JDK 8. The APIdoc >>>> of the class contains an implementation note that BigInteger constructors >>>> and operations throw an ArithmeticException when the result is out of the >>>> supported range. >>>> The supported range in JDK 8 is -2^Integer.MAX_VALUE to >>>> 2^Integer.MAX_VALUE, exclusive. This range is symmetric to make patch >>>> simpler. >>>> >>>> All constructors contains call checkRange() guarded by cheap test >>>> "mag.length >= MAX_MAG_LENGTH". The checkRange() method throws an >>>> ArithmeticException if the BigInteger instance would be out of the >>>> supported range. APIdocs of public constructors and methods contain an >>>> appropriate @throws ArithmeticException clause . >>>> >>>> The patch contains a fix of various other problems related to overflow: >>>> 1) Calculation of prime searchLen suffered from int overflow when >>>> bitLength was large; >>>> 2) int overflow in pow() method; >>>> 3) Overflow of intermediate results in modPow() method; >>>> 4) Removed the implementation restriction on Integer.MIN_VALUE >>>> in shiftLeft() and shiftRight() methods introduced during the fix of: >>>> JDK-6371401 : java.math.BigInteger.shift(**Integer.MIN_VALUE) throws >>>> StackOverflowError >>>> https://bugs.openjdk.java.net/**browse/JDK-6371401 >>>> >>>> Please, review this patch. >>>> >>>> >>>> >>>> On Wed, Jul 3, 2013 at 6:06 AM, Joseph Darcy >>>> wrote: >>>> >>>> Hello, >>>>> A quick note on this issue, before the recent work to use better >>>>> algorithms for BigInteger arithmetic operation, working with huge >>>>> numbers >>>>> was impractical and thus BigInteger.bitLength misbehavior was mostly an >>>>> academic concern. With the better algorithms, exposure to these large >>>>> values is likely to increase so BigInteger.bitLength should do something >>>>> reasonable. >>>>> >>>>> There are at least two implementation limits of note in the current >>>>> code: >>>>> >>>>> * Total bit length given a single backing array >>>>> * Max size of serializable BigInteger given old byte-array based format. >>>>> >>>>> My preference for addressing this issue includes adding an >>>>> implementation >>>>> note along the lines of "in JDK 8, BigInteger operates on values in the >>>>> range ...." without requiring that range to be part of the >>>>> specification. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> On 6/25/2013 6:18 PM, Brian Burkhalter wrote: >>>>> >>>>> This request for comment regards this issue >>>>>> http://bugs.sun.com/****bugdatabase/view_bug.do?bug_****id=6910473 >>>>>> >>>>>> BigInteger.bigLength() may return negative value for large numbers >>>>>> >>>>>> but more importantly Dmitry's thread >>>>>> >>>>>> http://mail.openjdk.java.net/****pipermail/core-libs-dev/2013-**** >>>>>> June/018345.html>>>>> core-libs-dev/2013-June/**018345.html >>>>>> What is the range of BigInteger values? >>>>>> >>>>>> The issue may be fixed superficially simply by throwing an >>>>>> ArithmeticException if the bit length as an int would be negative. A >>>>>> better >>>>>> fix suggested both in the issue description and in the aforementioned >>>>>> thread (option 1 of 3), is to define BigInteger to support a limited >>>>>> range >>>>>> and to clamp to that range in the constructor, throwing an >>>>>> ArithmeticException if the supplied parameter(s) would cause the >>>>>> BigInteger >>>>>> to overflow. This check would be relatively inexpensive. The suggested >>>>>> constraint range is >>>>>> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) >>>>>> This constraint would guarantee that all BigInteger instances are >>>>>> capable of accurately returning their properties such as bit length, >>>>>> bit >>>>>> count, etc. >>>>>> >>>>>> This naturally would require a minor specification change to >>>>>> BigInteger. >>>>>> The question is whether this change would limit any future >>>>>> developments of >>>>>> this and related classes. For example, one could envision BigInteger >>>>>> supporting bit lengths representable by a long instead of an int. In >>>>>> this >>>>>> case the second option would be preferable. >>>>>> >>>>>> It has been suggested that an alternative to extending the ranges >>>>>> supported by BigInteger would be to define a different class >>>>>> altogether to >>>>>> handle the larger ranges, keeping BigInteger as a well-specified API >>>>>> for >>>>>> the ranges it supports. Other related classes for arbitrary precision >>>>>> binary floating point and rational numbers might also be considered. >>>>>> >>>>>> In summary the specific questions being posed here are: >>>>>> >>>>>> 1) what is the general opinion on clamping the range of BigInteger and >>>>>> the various options suggested at the end of >>>>>> >>>>>> http://mail.openjdk.java.net/****pipermail/core-libs-dev/2013-**** >>>>>> June/018345.html>>>>> core-libs-dev/2013-June/**018345.html >>>>>>> ? >>>>>> >>>>>> 2) what are the forward looking thoughts on handling integers outside >>>>>> the current BigInteger range? >>>>>> >>>>>> From a practical point of view, any changes need to be considered >>>>>> with >>>>>> respect to what may be done in the short term (JDK 8) versus the long >>>>>> (JDK >>>>>> 9), so to speak. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Brian >>>>>> >>>>>> From alan.bateman at oracle.com Wed Oct 2 03:27:06 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Oct 2013 03:27:06 +0000 Subject: hg: jdk8/tl: 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Message-ID: <20131002032706.AFBCC62C89@hg.openjdk.java.net> Changeset: 187a759c08ba Author: alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/187a759c08ba 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Reviewed-by: mduigou, tbell ! common/makefiles/javadoc/CORE_PKGS.gmk From xuelei.fan at oracle.com Wed Oct 2 03:26:43 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 02 Oct 2013 03:26:43 +0000 Subject: hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites Message-ID: <20131002032658.A714B62C88@hg.openjdk.java.net> Changeset: 3fca37c636be Author: xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java From Alan.Bateman at oracle.com Wed Oct 2 03:44:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 01 Oct 2013 20:44:59 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> Message-ID: <524B96BB.4020301@oracle.com> On 01/10/2013 12:46, Brian Burkhalter wrote: > : > > I updated the webrev > > http://cr.openjdk.java.net/~bpb/8010371/ > > with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. > > Brian This looks better, although I think I would reverse re-write the expressions to "if (error = ...)". One thing to consider is whether this condition is really worth introducing HostLookupException, particularly when it doesn't include additional information (except to distinguish it from its supertype). If a new exception is really needed then maybe it could add the error message obtained from gai_strerror, alternatively maybe you could considered setting the cause of the UHE to something like an IOException with the translation of the error. -Alan. From john.r.rose at oracle.com Wed Oct 2 05:19:56 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 22:19:56 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity In-Reply-To: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> Message-ID: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable. Here is the respin: http://cr.openjdk.java.net/~jrose/8025112/webrev.01 ? John On Oct 1, 2013, at 3:15 PM, John Rose wrote: > This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. > > It also adjusts some unit tests. > > The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. > > The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. > > http://cr.openjdk.java.net/~jrose/8025112/webrev.00 > > For more background, see my JavaOne presentation: > http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf > > Thanks, > ? John From henry.jen at oracle.com Wed Oct 2 05:42:53 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 1 Oct 2013 22:42:53 -0700 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524B60B7.1060905@univ-mlv.fr> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> Message-ID: <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> Remi, Thanks for the review and comments, you have some good points. I am thinking perhaps the dumper class could be used somewhere else given a different path, which is why the directory is used as key to get an instance and injected from caller. As you observed, it's not necessary. But the injection does makes a cleaner separation instead of having nasty circle dependency as you put in the comment. I do intentionally leave the check on dumpDir each time instead of only in static block so that if the directory specified is not setup correctly(i.e, not exist), it can be fixed easily. I am thinking about debugging long-live process, but that's probably a moo point. As the static string for property name, we can simply hard-code it than we won't need static block nor a local field. This is just following a general convention in case somewhere else such as command line help need to have access to that constant. Sometimes I have difficulty to trade-off simplicity and extensibility, although I know the principal should be probably "Don't over engineer until you need it", but it's hard to resist the low-hanging fruit. :) Not sure how strong you feel about this, I'll let it sit for others to comment on current code/approach before I start another revision if necessary. Cheers, Henry On Oct 1, 2013, at 4:54 PM, Remi Forax wrote: > On 10/02/2013 01:04 AM, Henry Jen wrote: >> Hi, >> >> Please review the updated webrev at >> http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ >> >> This update addressed comments from Mandy with following, >> >> - call doPrivileged with specific file permission, "<>", "write". >> - Use nio package to write deal with FS, also create directory hierarchy >> with package name instead of flat files. >> - If not specify a value or empty string, the directory is default to >> current working directory as "." is specified. >> >> We continue to use local encoding rule as other suggestions doesn't fit. >> The reason we cannot use something like URLEncoder is that ":" won't get >> encoded and it's not valid character for filename on Windows. All the >> suggestions so far seems to have that same issue. >> >> Cheers, >> Henry >> > > Hi Henry, > most of the code that use atomic values is not needed if you do all these checks > in the static block (because the static block is protected by a lock) and > also instead of injecting the dump_dir, I think it's better to ask for it > in ProxyClassesDumper. > > so first, nitpicking!, DUMP_PATH_PROPERTY doesn't need to be a static field, > the code below is equivalent to yours but avoid to create yet another static field. > > // For dumping generated classes to disk, for debugging purposes > /* package */ static final String LAMBDA_PROXY_DUMP_DIR; > static { > String DUMP_PATH_PROPERTY = "jdk.internal.lambda.dumpProxyClasses"; > LAMBDA_PROXY_DUMP_DIR= AccessController.doPrivileged(new GetPropertyAction(DUMP_PATH_PROPERTY)); > } > > > // If requested, dump out to a file for debugging purposes > if (LAMBDA_PROXY_DUMP_DIR != null) { > AccessController.doPrivileged(new PrivilegedAction() { > @Override > public Void run() { > ProxyClassesDumper dumper = ProxyClassesDumper.getInstance(); // dont send DUMP_DIR here > ... > > then as I said the code in ProxyClassesDumper can be simplified if instead > of sending the dump directory, the ProxyClassesDumper ask for it. > > final class ProxyClassesDumper { > ... > > private final static ProxyClassesDumper INSTANCE; > static { > // ProxyClassesDumper.getInstance() should never be called > // in the static block of InnerClassLambdaMetafactory > // because it will create a circular dependency (a NPE) > String pathname = InnerClassLambdaMetafactory.LAMBDA_PROXY_DUMP_DIR.trim(); > Path dumpDir = Paths.get(pathname.isEmpty() ? "." : pathname); > dumpDir = validateDumpDir(dumpDir)? dumpDir: null; > INSTANCE = new ProxyClassesDumper(dumpDir); > } > private final Path dumpDir; // null if invalid > > // implement dump singleton instance, that's all we need right now > public static ProxyClassesDumper getInstance() { > return INSTANCE; > } > > private ProxyClassesDumper(String path) { > this.path = path; > } > > private static boolean validateDumpDir(Path path) { > String errMsg; // no need to initialize errMsg here > if (!Files.exists(path)) { > ... > public void dumpClass(String className, final byte[] classBytes) { > if (dumpDir == null) { > // invalid dump directory, silently ignore it > return; > } > ... > > cheers, > R?mi > From masayoshi.okutsu at oracle.com Wed Oct 2 06:32:25 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 02 Oct 2013 06:32:25 +0000 Subject: hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Message-ID: <20131002063239.AC93662C8C@hg.openjdk.java.net> Changeset: 914c29c10bce Author: okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java + test/java/util/Calendar/Bug6902861.java From peter.levart at gmail.com Wed Oct 2 07:19:04 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 09:19:04 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524B54E4.9010506@oracle.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> Message-ID: <524BC8E8.9090501@gmail.com> Hi Henry, Just a hint: Instead of parameterized singleton ProxyClassDumper with static method getInstance(path) which suggests that different ProxyClassDumper instances are returned for different path parameters (which are not), you could create for example: class DumpProxyClassAction implements PrivilegedAction { DumpProxyClassAction(String dumpDir, String className, byte[] classBytes) { ... ...and use it in InnerClassLambdaMetafactory instead of an anonymous inner class. Same number of objects per generated class are created that way... Regards, Peter On 10/02/2013 01:04 AM, Henry Jen wrote: > Hi, > > Please review the updated webrev at > http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ > > This update addressed comments from Mandy with following, > > - call doPrivileged with specific file permission, "<>", "write". > - Use nio package to write deal with FS, also create directory hierarchy > with package name instead of flat files. > - If not specify a value or empty string, the directory is default to > current working directory as "." is specified. > > We continue to use local encoding rule as other suggestions doesn't fit. > The reason we cannot use something like URLEncoder is that ":" won't get > encoded and it's not valid character for filename on Windows. All the > suggestions so far seems to have that same issue. > > Cheers, > Henry > > From peter.levart at gmail.com Wed Oct 2 07:42:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 09:42:35 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524BC8E8.9090501@gmail.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524BC8E8.9090501@gmail.com> Message-ID: <524BCE6B.2080403@gmail.com> Ah, I see, you want it that way to track that a warning about invalid directory is logged only once. That could be solved with an: private static final ConcurrentMap invalidDirs = new ConcurrentHashMap<>(); ...and then in validateDumpDir: if (invalidDirs.putIfAbsent(path, path) == null) { logger.warning(... If you wanted to support a per-path instance of ProxyClassDumper, you would need a registry of ProxyClassDumper instances anyway, implemented with such a ConcurrentHashMap... Regards, Peter On 10/02/2013 09:19 AM, Peter Levart wrote: > Hi Henry, > > Just a hint: Instead of parameterized singleton ProxyClassDumper with > static method getInstance(path) which suggests that different > ProxyClassDumper instances are returned for different path parameters > (which are not), you could create for example: > > class DumpProxyClassAction implements PrivilegedAction { > DumpProxyClassAction(String dumpDir, String className, byte[] > classBytes) { > ... > > ...and use it in InnerClassLambdaMetafactory instead of an anonymous > inner class. Same number of objects per generated class are created > that way... > > Regards, Peter > > On 10/02/2013 01:04 AM, Henry Jen wrote: >> Hi, >> >> Please review the updated webrev at >> http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ >> >> This update addressed comments from Mandy with following, >> >> - call doPrivileged with specific file permission, "<>", >> "write". >> - Use nio package to write deal with FS, also create directory hierarchy >> with package name instead of flat files. >> - If not specify a value or empty string, the directory is default to >> current working directory as "." is specified. >> >> We continue to use local encoding rule as other suggestions doesn't fit. >> The reason we cannot use something like URLEncoder is that ":" won't get >> encoded and it's not valid character for filename on Windows. All the >> suggestions so far seems to have that same issue. >> >> Cheers, >> Henry >> >> > From scolebourne at joda.org Wed Oct 2 08:01:22 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Oct 2013 09:01:22 +0100 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524B199C.9000309@oracle.com> References: <523DF05E.5020009@oracle.com> <524B199C.9000309@oracle.com> Message-ID: I suggest taking the patch as is and raising a new lower priority bug for the effective chrono aspect. Stephen On 1 October 2013 19:51, roger riggs wrote: > Hi Stephen, > > The proposed approach makes sense to me, shall I take the patch as is or > wait to integrate until for the mentioned update of effective chrono? > > Thanks, Roger > > > On 9/22/2013 10:27 AM, Stephen Colebourne wrote: >> >> The patch only changes the text of one of the two appendValueReduced >> methods. The patch does not handle week based years or provide for >> users to add their own year fields. It also does not handle >> formatting. >> >> After much thinking, I think the right solution is to add a new >> appendValueReduced method where "int baseValue" is replaced by >> "ChronoLocalDate baseDate". The new method would be used if you want >> year-like fields in multiple chronologies to work. The appendPattern >> method would be changed to use the new date variant for y/u/W >> >> The first of the two existing appendValueReduced methods can be >> removed as a simplification. >> >> Patch here: >> https://gist.github.com/jodastephen/6660394 >> >> Note that this patch still has a bug, as the effective chrono is not >> determined fully until the end of the parsing phase. However, that bug >> fix requires a bit of an internal redesign and since it does not >> affect the API it can be delayed, >> >> Stephen >> >> >> >> >> On 21 September 2013 20:15, roger riggs wrote: >>> >>> Hi, >>> >>> The java.time reduced value parser does work as expected (issue 8024076) >>> for chronologies other than ISO. >>> The base value is assumed to be chronology independent but is not >>> converted to the requested Chronology before it is used. >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ >>> >>> Thanks, Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8024076 >>> > From sean.coffey at oracle.com Wed Oct 2 08:22:34 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 02 Oct 2013 08:22:34 +0000 Subject: hg: jdk8/tl/jdk: 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Message-ID: <20131002082305.2A14B62C96@hg.openjdk.java.net> Changeset: 368172cb6dc5 Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java From masayoshi.okutsu at oracle.com Wed Oct 2 08:58:02 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 02 Oct 2013 08:58:02 +0000 Subject: hg: jdk8/tl/jdk: 8022666: java.util.Calendar.set(int, int, int, int, int, int) documentation typo Message-ID: <20131002085900.D4ADF62C97@hg.openjdk.java.net> Changeset: 82e3150778e0 Author: okutsu Date: 2013-10-02 17:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e3150778e0 8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java From forax at univ-mlv.fr Wed Oct 2 10:19:12 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 02 Oct 2013 12:19:12 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> Message-ID: <524BF320.8070807@univ-mlv.fr> On 10/02/2013 07:42 AM, Henry Jen wrote: > Remi, > > Thanks for the review and comments, you have some good points. > > I am thinking perhaps the dumper class could be used somewhere else given a different path, which is why the directory is used as key to get an instance and injected from caller. As you observed, it's not necessary. But the injection does makes a cleaner separation instead of having nasty circle dependency as you put in the comment. > > I do intentionally leave the check on dumpDir each time instead of only in static block so that if the directory specified is not setup correctly(i.e, not exist), it can be fixed easily. I am thinking about debugging long-live process, but that's probably a moo point. > > As the static string for property name, we can simply hard-code it than we won't need static block nor a local field. This is just following a general convention in case somewhere else such as command line help need to have access to that constant. > > Sometimes I have difficulty to trade-off simplicity and extensibility, although I know the principal should be probably "Don't over engineer until you need it", but it's hard to resist the low-hanging fruit. :) > > Not sure how strong you feel about this, I'll let it sit for others to comment on current code/approach before I start another revision if necessary. > > Cheers, > Henry I think there is no trade off here, the code is not public, so no headache. We should only value the simplicity and refactor 'if somewhere else ...'. There is a nice way to solve the circular issue, the idea is that you can declare a ProxyClassesDumper in InnerClassLambdaMetafactory and initialize it with null if the property is not defined. In that case, you don't need ProxyClassesDumper to be a singleton anymore and because the static field is initialized with null, the class is not loaded if you don't want to dump the class file. private static final ProxyClassesDumper PROXY_CLASSES_DUMPER; static { String DUMP_PATH_PROPERTY = "jdk.internal.lambda.dumpProxyClasses"; String dumpDir = AccessController.doPrivileged(new GetPropertyAction(DUMP_PATH_PROPERTY)); PROXY_CLASSES_DUMPER = (dumpDir == null)? null: ProxyClassesDumper.create(dumpDir); } // If requested, dump out to a file for debugging purposes if (PROXY_CLASSES_DUMPER != null) { AccessController.doPrivileged(new PrivilegedAction() { @Override public Void run() { PROXY_CLASSES_DUMPER. ... ... final class ProxyClassesDumper { ... private final Path dumpDir; // null if invalid public static ProxyClassesDumper create(String dir) { dir = dir.trim(); Path path = Paths.get(dir.isEmpty() ? "." : dir); path = validateDumpDir(path)? path: null; return new ProxyClassesDumper(path); } private ProxyClassesDumper(Path path) { this.path = path; } private static boolean validateDumpDir(Path path) { String errMsg; // no need to initialize errMsg here if (!Files.exists(path)) { ... public void dumpClass(String className, final byte[] classBytes) { if (dumpDir == null) { // invalid dump directory, silently ignore it return; } ... cheers, R?mi > > On Oct 1, 2013, at 4:54 PM, Remi Forax wrote: > >> On 10/02/2013 01:04 AM, Henry Jen wrote: >>> Hi, >>> >>> Please review the updated webrev at >>> http://cr.openjdk.java.net/~henryjen/ccc/8023524/3/webrev/ >>> >>> This update addressed comments from Mandy with following, >>> >>> - call doPrivileged with specific file permission, "<>", "write". >>> - Use nio package to write deal with FS, also create directory hierarchy >>> with package name instead of flat files. >>> - If not specify a value or empty string, the directory is default to >>> current working directory as "." is specified. >>> >>> We continue to use local encoding rule as other suggestions doesn't fit. >>> The reason we cannot use something like URLEncoder is that ":" won't get >>> encoded and it's not valid character for filename on Windows. All the >>> suggestions so far seems to have that same issue. >>> >>> Cheers, >>> Henry >>> >> Hi Henry, >> most of the code that use atomic values is not needed if you do all these checks >> in the static block (because the static block is protected by a lock) and >> also instead of injecting the dump_dir, I think it's better to ask for it >> in ProxyClassesDumper. >> >> so first, nitpicking!, DUMP_PATH_PROPERTY doesn't need to be a static field, >> the code below is equivalent to yours but avoid to create yet another static field. >> >> // For dumping generated classes to disk, for debugging purposes >> /* package */ static final String LAMBDA_PROXY_DUMP_DIR; >> static { >> String DUMP_PATH_PROPERTY = "jdk.internal.lambda.dumpProxyClasses"; >> LAMBDA_PROXY_DUMP_DIR= AccessController.doPrivileged(new GetPropertyAction(DUMP_PATH_PROPERTY)); >> } >> >> >> // If requested, dump out to a file for debugging purposes >> if (LAMBDA_PROXY_DUMP_DIR != null) { >> AccessController.doPrivileged(new PrivilegedAction() { >> @Override >> public Void run() { >> ProxyClassesDumper dumper = ProxyClassesDumper.getInstance(); // dont send DUMP_DIR here >> ... >> >> then as I said the code in ProxyClassesDumper can be simplified if instead >> of sending the dump directory, the ProxyClassesDumper ask for it. >> >> final class ProxyClassesDumper { >> ... >> >> private final static ProxyClassesDumper INSTANCE; >> static { >> // ProxyClassesDumper.getInstance() should never be called >> // in the static block of InnerClassLambdaMetafactory >> // because it will create a circular dependency (a NPE) >> String pathname = InnerClassLambdaMetafactory.LAMBDA_PROXY_DUMP_DIR.trim(); >> Path dumpDir = Paths.get(pathname.isEmpty() ? "." : pathname); >> dumpDir = validateDumpDir(dumpDir)? dumpDir: null; >> INSTANCE = new ProxyClassesDumper(dumpDir); >> } >> private final Path dumpDir; // null if invalid >> >> // implement dump singleton instance, that's all we need right now >> public static ProxyClassesDumper getInstance() { >> return INSTANCE; >> } >> >> private ProxyClassesDumper(String path) { >> this.path = path; >> } >> >> private static boolean validateDumpDir(Path path) { >> String errMsg; // no need to initialize errMsg here >> if (!Files.exists(path)) { >> ... >> public void dumpClass(String className, final byte[] classBytes) { >> if (dumpDir == null) { >> // invalid dump directory, silently ignore it >> return; >> } >> ... >> >> cheers, >> R?mi >> From chris.hegarty at oracle.com Wed Oct 2 11:34:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 12:34:39 +0100 Subject: RFR 8025535: Unsafe typecast in java.util.stream.SortedOps In-Reply-To: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> References: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> Message-ID: <524C04CF.7020801@oracle.com> The change looks fine to me. Just curious why we don't allow sizes equal to Nodes.MAX_ARRAY_SIZE? Rather less than. -Chris. On 01/10/2013 20:30, Paul Sandoz wrote: > Hi, > > Please review the following patch that checks size limits for the sorted operation and fails quickly rather than failing with an obscure ISE or an OOME later on: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8025535-sorted-unsafe-type-cast/webrev/ > > Tests have been added that assert for both SIZED and non-SIZED (at pipeline construction) inputs to sorted(). > > Paul. From paul.sandoz at oracle.com Wed Oct 2 12:03:24 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Oct 2013 14:03:24 +0200 Subject: RFR 8025535: Unsafe typecast in java.util.stream.SortedOps In-Reply-To: <524C04CF.7020801@oracle.com> References: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> <524C04CF.7020801@oracle.com> Message-ID: <26FBE215-116F-47F3-98CA-F512A7B9BFA4@oracle.com> On Oct 2, 2013, at 1:34 PM, Chris Hegarty wrote: > The change looks fine to me. > Thanks. > Just curious why we don't allow sizes equal to Nodes.MAX_ARRAY_SIZE? Rather less than. > Hmm... well observed, it's most likely a one off error due to it being confused with the exclusive upper bound for an index. It is consistently used like that throughout the code base. Don't wanna change that just now, i can do it later. Paul. From paul.sandoz at oracle.com Wed Oct 2 12:25:58 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 02 Oct 2013 12:25:58 +0000 Subject: hg: jdk8/tl/jdk: 8025535: Unsafe typecast in java.util.stream.SortedOps Message-ID: <20131002122644.6D9B862C9D@hg.openjdk.java.net> Changeset: e1b04fd49204 Author: psandoz Date: 2013-10-01 18:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b04fd49204 8025535: Unsafe typecast in java.util.stream.SortedOps Reviewed-by: mduigou, chegar ! src/share/classes/java/util/stream/SortedOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java From chris.hegarty at oracle.com Wed Oct 2 13:06:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 14:06:13 +0100 Subject: RFR 8025535: Unsafe typecast in java.util.stream.SortedOps In-Reply-To: <26FBE215-116F-47F3-98CA-F512A7B9BFA4@oracle.com> References: <44C50F57-6DF1-45D5-B61C-80E7F16DCB4A@oracle.com> <524C04CF.7020801@oracle.com> <26FBE215-116F-47F3-98CA-F512A7B9BFA4@oracle.com> Message-ID: <524C1A45.8070203@oracle.com> On 02/10/2013 13:03, Paul Sandoz wrote: > > On Oct 2, 2013, at 1:34 PM, Chris Hegarty wrote: > >> The change looks fine to me. >> > > Thanks. > > >> Just curious why we don't allow sizes equal to Nodes.MAX_ARRAY_SIZE? Rather less than. >> > > Hmm... well observed, it's most likely a one off error due to it being confused with the exclusive upper bound for an index. It is consistently used like that throughout the code base. Don't wanna change that just now, i can do it later. Yes, that is what I thought. And I agree it is a separate, less important, issue. -Chris. > > Paul. From jhuxhorn at googlemail.com Wed Oct 2 14:03:32 2013 From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=) Date: Wed, 2 Oct 2013 16:03:32 +0200 Subject: =?UTF-8?Q?Re=3A_9_days_left_for_getCallerClass_solution?= In-Reply-To: <524AD0C6.9030309@oracle.com> References: <524AD0C6.9030309@oracle.com> Message-ID: On 1. Oktober 2013 at 15:44:30, Alan Bateman (alan.bateman at oracle.com) wrote: On 01/10/2013 01:50, J?rn Huxhorn wrote:? > ?just saying?? We know. It seems unlikely that there will be agreement on a standard? API or that there is time for a new API to bake. So the safest thing? might be just restore the totally unsupported getCallerClass and submit? a JEP with a proposal to add a standard API.? -Alan. Is this still possible? I had the impression that reverting the removal of that method wouldn't be a viable option. I like Nicks patch but more time for discussion wouldn't hurt anyway - if only to properly disperse remaining objections and concerns. From peter.levart at gmail.com Wed Oct 2 14:12:59 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 16:12:59 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524BF320.8070807@univ-mlv.fr> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> Message-ID: <524C29EB.8010108@gmail.com> On 10/02/2013 12:19 PM, Remi Forax wrote: > final class ProxyClassesDumper { > ... > private final Path dumpDir; // null if invalid > > public static ProxyClassesDumper create(String dir) { > dir = dir.trim(); > Path path = *Paths.get*(dir.isEmpty() ? "." : dir); > path = validateDumpDir(path)? path: null; > return new ProxyClassesDumper(path); > } Hi Remi, Henry, I think Henry is trying to re-validate the directory on each dump attempt even if it was invalid on 1st dump attempt. Perhaps in order to be able to start a VM with dump directory specified and only later create or mount that directory. Having a static field in the InnerClassLambdaMetafactory holding an initialized ProxyClassesDumper is a good idea. One thing to watch though is that Paths.get(String) can throw InvalidPathException. This will render InnerClassLambdaMetafactory non-functional since its static initialization will throw exception. Each lambda capture will than throw Error. I think the exception should be caught, logged and null returned from ProxyClassesDumper.create() in that case... Regards, Peter From forax at univ-mlv.fr Wed Oct 2 14:21:24 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 02 Oct 2013 16:21:24 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524C29EB.8010108@gmail.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> Message-ID: <524C2BE4.30602@univ-mlv.fr> On 10/02/2013 04:12 PM, Peter Levart wrote: > On 10/02/2013 12:19 PM, Remi Forax wrote: >> final class ProxyClassesDumper { >> ... >> private final Path dumpDir; // null if invalid >> >> public static ProxyClassesDumper create(String dir) { >> dir = dir.trim(); >> Path path = *Paths.get*(dir.isEmpty() ? "." : dir); >> path = validateDumpDir(path)? path: null; >> return new ProxyClassesDumper(path); >> } > > Hi Remi, Henry, > > I think Henry is trying to re-validate the directory on each dump > attempt even if it was invalid on 1st dump attempt. Perhaps in order > to be able to start a VM with dump directory specified and only later > create or mount that directory. > > Having a static field in the InnerClassLambdaMetafactory holding an > initialized ProxyClassesDumper is a good idea. > > One thing to watch though is that Paths.get(String) can throw > InvalidPathException. This will render InnerClassLambdaMetafactory > non-functional since its static initialization will throw exception. > Each lambda capture will than throw Error. I think the exception > should be caught, logged and null returned from > ProxyClassesDumper.create() in that case... yes, nice catch. > > > Regards, Peter > cheers, R?mi From chris.hegarty at oracle.com Wed Oct 2 14:40:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 15:40:44 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524B96BB.4020301@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: <524C306C.5070502@oracle.com> On 02/10/2013 04:44, Alan Bateman wrote: > On 01/10/2013 12:46, Brian Burkhalter wrote: >> : >> >> I updated the webrev >> >> http://cr.openjdk.java.net/~bpb/8010371/ >> >> with changes in the test of the return value of getaddrinfo for Unix >> Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. >> >> Brian > This looks better, although I think I would reverse re-write the > expressions to "if (error = ...)". > > One thing to consider is whether this condition is really worth > introducing HostLookupException, particularly when it doesn't include I am also not convinced of the merits of adding a new public checked Exception type for this situation. Do we expect all callers of API's that can throw UKE to now have to catch this Exception and provide their own try logic? Otherwise, what do we expect them to do with it. I cannot see the original webrev, so cannot comment on the retry logic that was there. Do you still have it around? Can upload as a .05 version? The reason I ask is that, IMHO, I would prefer this type of approach over the new Exception type, but that could be just me. Thanks, -Chris. > additional information (except to distinguish it from its supertype). If > a new exception is really needed then maybe it could add the error > message obtained from gai_strerror, alternatively maybe you could > considered setting the cause of the UHE to something like an IOException > with the translation of the error. > > -Alan. From aleksey.shipilev at oracle.com Wed Oct 2 14:43:06 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 02 Oct 2013 18:43:06 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation Message-ID: <524C30FA.1010209@oracle.com> Hi, There is the issue that annoys me all the time: https://bugs.openjdk.java.net/browse/JDK-6857566 Please review the rework of DirectByteBuffer cleanup mechanics fixing that issue. Since DBB uses sun.misc.Cleaner as the infrastructure to clean up things, we focus there: http://cr.openjdk.java.net/~shade/6857566/webrev.00/ Brief explanation is there in Cleaner comments. Testing: - jtreg: jdk/nio tests on Linux x86_64/fastdebug - original sample test from 6857566, reproduces in a few seconds nicely with -XX:MaxDirectMemorySize=16M; more than 90 minutes run with patched build yield no OOMEs! - microbenchmarking, see below The microbenchmark tests allocates ByteBuffer.allocateDirect(N), with N=1,10,100,1000 bytes: http://cr.openjdk.java.net/~shade/6857566/directbb/ On my 2x2 i5 Linux x86_64 laptop: Before patch (1 thread): direct_1 834 +- 159 ns/op direct_10 888 +- 262 ns/op direct_100 969 +- 307 ns/op direct_1000 1618 +- 46 ns/op Before patch (4 threads): direct_1 direct_10 direct_100 direct_1000 Single threaded allocators are working fine, but this means nothing, because more threads just plainly OOME. After patch (1 thread): direct_1 1645 +- 68 ns/op direct_10 1623 +- 53 ns/op direct_100 1704 +- 44 ns/op direct_1000 3327 +- 43 ns/op After patch (4 threads): direct_1 4673 +- 80 ns/op direct_10 4673 +- 114 ns/op direct_100 4771 +- 89 ns/op direct_1000 22310 +- 14390 ns/op Thanks, -Aleksey. From staffan.larsen at oracle.com Wed Oct 2 12:37:32 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 02 Oct 2013 12:37:32 +0000 Subject: hg: jdk8/tl/jdk: 6696975: JTop plugin fails if connected readonly to target JVM Message-ID: <20131002123745.087CF62C9E@hg.openjdk.java.net> Changeset: 3bb89c509d59 Author: egahlin Date: 2013-10-01 17:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3bb89c509d59 6696975: JTop plugin fails if connected readonly to target JVM Reviewed-by: mchung, jbachorik, sla, sjiang ! src/share/demo/management/JTop/JTop.java From michael.x.mcmahon at oracle.com Wed Oct 2 14:58:45 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 02 Oct 2013 15:58:45 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524C306C.5070502@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C306C.5070502@oracle.com> Message-ID: <524C34A5.9060402@oracle.com> On 02/10/13 15:40, Chris Hegarty wrote: > On 02/10/2013 04:44, Alan Bateman wrote: >> On 01/10/2013 12:46, Brian Burkhalter wrote: >>> : >>> >>> I updated the webrev >>> >>> http://cr.openjdk.java.net/~bpb/8010371/ >>> >>> with changes in the test of the return value of getaddrinfo for Unix >>> Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. >>> >>> Brian >> This looks better, although I think I would reverse re-write the >> expressions to "if (error = ...)". >> >> One thing to consider is whether this condition is really worth >> introducing HostLookupException, particularly when it doesn't include > > I am also not convinced of the merits of adding a new public checked > Exception type for this situation. Do we expect all callers of API's > that can throw UKE to now have to catch this Exception and provide > their own try logic? Otherwise, what do we expect them to do with it. > It's proposed as a subclass of UnknownHostException. So, nobody would have to catch it. I suppose another approach, which is a variant of the first one suggested, would be retry logic built in, which is switched off by default and configurable somehow. Michael From paul.sandoz at oracle.com Wed Oct 2 15:05:44 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Oct 2013 17:05:44 +0200 Subject: RFR 8025534: Unsafe typecast in java.util.stream.Streams.Nodes Message-ID: Hi, Please review the following patch that fixes/clarifies areas that cast long to int when creating and processing arrays of elements: http://cr.openjdk.java.net/~psandoz/tl/JDK-8025534-unsafe-int-casts/webrev/ I have retained the one off error (>= Nodes.MAX_ARRAY_SIZE) that Chris previously observed. No unit tests have been updated/added since this area requires rather large memory configurations for verification. Paul. From chris.hegarty at oracle.com Wed Oct 2 15:12:47 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 16:12:47 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524C34A5.9060402@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C306C.5070502@oracle.com> <524C34A5.9060402@oracle.com> Message-ID: <524C37EF.7000904@oracle.com> On 02/10/2013 15:58, Michael McMahon wrote: > On 02/10/13 15:40, Chris Hegarty wrote: >> On 02/10/2013 04:44, Alan Bateman wrote: >>> On 01/10/2013 12:46, Brian Burkhalter wrote: >>>> : >>>> >>>> I updated the webrev >>>> >>>> http://cr.openjdk.java.net/~bpb/8010371/ >>>> >>>> with changes in the test of the return value of getaddrinfo for Unix >>>> Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. >>>> >>>> Brian >>> This looks better, although I think I would reverse re-write the >>> expressions to "if (error = ...)". >>> >>> One thing to consider is whether this condition is really worth >>> introducing HostLookupException, particularly when it doesn't include >> >> I am also not convinced of the merits of adding a new public checked >> Exception type for this situation. Do we expect all callers of API's >> that can throw UKE to now have to catch this Exception and provide >> their own try logic? Otherwise, what do we expect them to do with it. >> > > It's proposed as a subclass of UnknownHostException. So, nobody would > have to catch it. Right, understood. But unless someone adds explicit handling code when there is no change in existing behavior. > I suppose another approach, which is a variant of the first one > suggested, would be > retry logic built in, which is switched off by default and configurable > somehow. I did not see the retry webrev so cannot comment on the specifics, but I don't see any issue with a single untimed retry, if that fails throw an UHE with a specific cause. -Chris. > > Michael > From chris.hegarty at oracle.com Wed Oct 2 15:18:27 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 16:18:27 +0100 Subject: RFR 8025534: Unsafe typecast in java.util.stream.Streams.Nodes In-Reply-To: References: Message-ID: <524C3943.20604@oracle.com> Looks good to me Paul. -Chris. On 02/10/2013 16:05, Paul Sandoz wrote: > Hi, > > Please review the following patch that fixes/clarifies areas that cast long to int when creating and processing arrays of elements: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8025534-unsafe-int-casts/webrev/ > > I have retained the one off error (>= Nodes.MAX_ARRAY_SIZE) that Chris previously observed. > > No unit tests have been updated/added since this area requires rather large memory configurations for verification. > > Paul. From henry.jen at oracle.com Wed Oct 2 15:17:44 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 2 Oct 2013 08:17:44 -0700 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524C2BE4.30602@univ-mlv.fr> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> <524C2BE4.30602@univ-mlv.fr> Message-ID: On Oct 2, 2013, at 7:21 AM, Remi Forax wrote: > On 10/02/2013 04:12 PM, Peter Levart wrote: >> On 10/02/2013 12:19 PM, Remi Forax wrote: >>> final class ProxyClassesDumper { >>> ... >>> private final Path dumpDir; // null if invalid >>> >>> public static ProxyClassesDumper create(String dir) { >>> dir = dir.trim(); >>> Path path = *Paths.get*(dir.isEmpty() ? "." : dir); >>> path = validateDumpDir(path)? path: null; >>> return new ProxyClassesDumper(path); >>> } >> >> Hi Remi, Henry, >> >> I think Henry is trying to re-validate the directory on each dump attempt even if it was invalid on 1st dump attempt. Perhaps in order to be able to start a VM with dump directory specified and only later create or mount that directory. >> >> Having a static field in the InnerClassLambdaMetafactory holding an initialized ProxyClassesDumper is a good idea. >> >> One thing to watch though is that Paths.get(String) can throw InvalidPathException. This will render InnerClassLambdaMetafactory non-functional since its static initialization will throw exception. Each lambda capture will than throw Error. I think the exception should be caught, logged and null returned from ProxyClassesDumper.create() in that case... > > yes, nice catch. I had it in there earlier, but need that in exception message. Since it is called only by InnerClassMetaFactory, which I think won't cause that exception so I just let it be. That's not a good idea if consider dumper to be a reusable component. Cheers, Henry From roger.riggs at oracle.com Wed Oct 2 15:19:26 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Oct 2013 11:19:26 -0400 Subject: Please Review fix for reduced value parser 8024076 Message-ID: <524C397E.2000303@oracle.com> Please review this fix for parsing two digit years in an Chronology. The webrev includes Stephen's proposed alternate method that provides a ChronoLocalDate as the base date. http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ Thanks, Roger p.s. the design issue raised in the comments has been filed as [2] : 8025828 [1]https://bugs.openjdk.java.net/browse/JDK-8024076 [2]https://bugs.openjdk.java.net/browse/JDK-8025828 From scolebourne at joda.org Wed Oct 2 15:46:33 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Oct 2013 16:46:33 +0100 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524C397E.2000303@oracle.com> References: <524C397E.2000303@oracle.com> Message-ID: My patch still looks fine to me :-) Stephen On 2 October 2013 16:19, roger riggs wrote: > Please review this fix for parsing two digit years in an Chronology. > > The webrev includes Stephen's proposed alternate method that provides > a ChronoLocalDate as the base date. > > http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ > > Thanks, Roger > > p.s. the design issue raised in the comments has been filed as [2] : 8025828 > > [1]https://bugs.openjdk.java.net/browse/JDK-8024076 > [2]https://bugs.openjdk.java.net/browse/JDK-8025828 > > From peter.levart at gmail.com Wed Oct 2 15:58:54 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 17:58:54 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C30FA.1010209@oracle.com> References: <524C30FA.1010209@oracle.com> Message-ID: <524C42BE.3080609@gmail.com> Hi Aleksey, I briefly skimmed over the changes. If I understand them correctly, they change they way Cleaners are processed. Without any assistance from other threads, Cleaners (WeakReferences now) are 1st enqueued by the ReferenceHandler thread, and CleaningThread then picks them out of the queue and processes them. Because they are not processed by ReferenceHandler thread any more, cleaning does not interfere with en-queueing of other References. This is good. Assisting cleaning from other threads means that cleaning can be performed in any thread. Cleaners should be prepared for that - previously they were only invoked from ReferenceHandler thread. assistCleanupSlow could really become slow, if lots of Cleaners get allocated (for example, lots of small DirectByteBuffers get allocated) and not GC-ed for some time. This brings me to java.nio.Bits. It uses System.gc(). I understand that allocation of native memory does not represent a memory pressure for heap GC so you're trying to trigger it when it gets tight. But lots of environments (app servers) are using -XX:+DisableExplicitGC to prevent ill behaved libraries to trigger GCs to frequently. Have you tried your test using -XX:+DisableExplicitGC ? Regards, Peter P.S. I wish there was some Java-side API with which you could register (with enough privilege) a filter that would decide whether to honour System.gc() or not (making System.gc() @CallerSensitive and invoking a registered Predicate>-s with the caller class, for example. If any of registered Predicates returned true, the gc would be honoured). App servers could use this API instead of -XX:+DisableExplicitGC then. On 10/02/2013 04:43 PM, Aleksey Shipilev wrote: > Hi, > > There is the issue that annoys me all the time: > https://bugs.openjdk.java.net/browse/JDK-6857566 > > Please review the rework of DirectByteBuffer cleanup mechanics fixing > that issue. Since DBB uses sun.misc.Cleaner as the infrastructure to > clean up things, we focus there: > http://cr.openjdk.java.net/~shade/6857566/webrev.00/ > > Brief explanation is there in Cleaner comments. > > Testing: > - jtreg: jdk/nio tests on Linux x86_64/fastdebug > - original sample test from 6857566, reproduces in a few seconds > nicely with -XX:MaxDirectMemorySize=16M; more than 90 minutes run with > patched build yield no OOMEs! > - microbenchmarking, see below > > The microbenchmark tests allocates ByteBuffer.allocateDirect(N), with > N=1,10,100,1000 bytes: > http://cr.openjdk.java.net/~shade/6857566/directbb/ > > On my 2x2 i5 Linux x86_64 laptop: > > Before patch (1 thread): > direct_1 834 +- 159 ns/op > direct_10 888 +- 262 ns/op > direct_100 969 +- 307 ns/op > direct_1000 1618 +- 46 ns/op > > Before patch (4 threads): > direct_1 > direct_10 > direct_100 > direct_1000 > > Single threaded allocators are working fine, but this means nothing, > because more threads just plainly OOME. > > After patch (1 thread): > direct_1 1645 +- 68 ns/op > direct_10 1623 +- 53 ns/op > direct_100 1704 +- 44 ns/op > direct_1000 3327 +- 43 ns/op > > After patch (4 threads): > direct_1 4673 +- 80 ns/op > direct_10 4673 +- 114 ns/op > direct_100 4771 +- 89 ns/op > direct_1000 22310 +- 14390 ns/op > > Thanks, > -Aleksey. From roger.riggs at oracle.com Wed Oct 2 16:01:22 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Oct 2013 12:01:22 -0400 Subject: Please Review java.time static interface methods move to supporting class Message-ID: <524C4352.1030807@oracle.com> As noted in the issue[1], the static methods in the TemporalAdjuster and TemporalQuery interfaces that provide implementations of Adjusters and Queries seem out of place and are better located in a related supporting class so the purpose and function of the interfaces are not diluted. Adding more methods in the future will be a better fit in the class. The static methods of TemporalAdjuster are moved to TemporalAdjusters and the static method of TemporalQuery are moved to TemporalQueries. Those classes were previously package private and are now public. Please review and comment: javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ webrev: http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8025722 From vicente.romero at oracle.com Wed Oct 2 16:06:03 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 02 Oct 2013 16:06:03 +0000 Subject: hg: jdk8/tl/langtools: 8023679: Improve error message for '_' used as a lambda parameter name Message-ID: <20131002160614.8D2F162CA7@hg.openjdk.java.net> Changeset: 1e6088da1740 Author: vromero Date: 2013-10-02 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e6088da1740 8023679: Improve error message for '_' used as a lambda parameter name Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/UnderscoreInLambdaExpression.java From peter.levart at gmail.com Wed Oct 2 16:10:53 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 18:10:53 +0200 Subject: RFR (4th): 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> <524C2BE4.30602@univ-mlv.fr> Message-ID: <524C458D.8070907@gmail.com> On 10/02/2013 05:17 PM, Henry Jen wrote: >>> >>One thing to watch though is that Paths.get(String) can throw InvalidPathException. This will render InnerClassLambdaMetafactory non-functional since its static initialization will throw exception. Each lambda capture will than throw Error. I think the exception should be caught, logged and null returned from ProxyClassesDumper.create() in that case... >> > >> >yes, nice catch. > I had it in there earlier, but need that in exception message. Since it is called only by InnerClassMetaFactory, which I think won't cause that exception so I just let it be. It's called by InnerClassMetaFactory, yes, but the path string comes from system property (the user!). > > That's not a good idea if consider dumper to be a reusable component. I agree, but you should handle the exception in static initializer of InnerClassMetaFactory then. Regards, Peter > > Cheers, > Henry From martinrb at google.com Wed Oct 2 16:29:32 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2013 09:29:32 -0700 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged Message-ID: FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) currently running the task. This should succeed even if modifyThread permission is denied by the security manager. Here's a proposed fix for jdk8+: --- src/main/java/util/concurrent/FutureTask.java 15 May 2013 02:39:59 -0000 1.103 +++ src/main/java/util/concurrent/FutureTask.java 2 Oct 2013 16:25:23 -0000 @@ -132,6 +132,12 @@ return state != NEW; } + private static void privilegedInterrupt(Thread t) { + java.security.PrivilegedAction doInterrupt = + () -> { t.interrupt(); return null; }; + java.security.AccessController.doPrivileged(doInterrupt); + } + public boolean cancel(boolean mayInterruptIfRunning) { if (!(state == NEW && UNSAFE.compareAndSwapInt(this, stateOffset, NEW, @@ -142,7 +148,11 @@ try { Thread t = runner; if (t != null) - t.interrupt(); + try { + t.interrupt(); + } catch (SecurityException e) { + privilegedInterrupt(t); + } } finally { // final state UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED); } From Alan.Bateman at oracle.com Wed Oct 2 16:31:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Oct 2013 09:31:38 -0700 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C30FA.1010209@oracle.com> References: <524C30FA.1010209@oracle.com> Message-ID: <524C4A6A.4030105@oracle.com> On 02/10/2013 07:43, Aleksey Shipilev wrote: > Hi, > > There is the issue that annoys me all the time: > https://bugs.openjdk.java.net/browse/JDK-6857566 > > Please review the rework of DirectByteBuffer cleanup mechanics fixing > that issue. Since DBB uses sun.misc.Cleaner as the infrastructure to > clean up things, we focus there: > http://cr.openjdk.java.net/~shade/6857566/webrev.00/ > I'd like to review, I just don't have time at the moment. One thing that I'd like to understand is the implication of moving from phantom to weak references. Also the impact on mapped buffers (map implementation in sun.nio.ch.FileChannelImpl) which will need to be changed too. Also I think we will need to include a short-running stress test as part of this change. -Alan From aleksey.shipilev at oracle.com Wed Oct 2 16:38:59 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 02 Oct 2013 20:38:59 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C42BE.3080609@gmail.com> References: <524C30FA.1010209@oracle.com> <524C42BE.3080609@gmail.com> Message-ID: <524C4C23.3020506@oracle.com> Hi Peter, On 10/02/2013 07:58 PM, Peter Levart wrote: > I briefly skimmed over the changes. If I understand them correctly, > they change they way Cleaners are processed. Without any assistance > from other threads, Cleaners (WeakReferences now) are 1st enqueued by > the ReferenceHandler thread, and CleaningThread then picks them out > of the queue and processes them. Because they are not processed by > ReferenceHandler thread any more, cleaning does not interfere with > en-queueing of other References. This is good. Yes, that's the part of the story. However, no matter how many distinct collectors you have, you can have more allocators to overwhelm them with work. So, the major difference is that we have the feedback from the allocators, which can assist us in claiming some of the garbage. > Assisting cleaning from other threads means that cleaning can be > performed in any thread. Cleaners should be prepared for that - > previously they were only invoked from ReferenceHandler thread. Yes. Do you see they are not? The ReferenceQueue is thread-safe, and the Set from CHM is thread-safe as well. > assistCleanupSlow could really become slow, if lots of Cleaners get > allocated (for example, lots of small DirectByteBuffers get > allocated) and not GC-ed for some time. Yes, they can. The thing to keep in mind while looking at this code is "graceful degradation". If ReferenceHandler is fast enough to enqueue garbage, we have the cleanup for free by the virtue of CleanupHandler doing the work for us. If CleanupHandler is not capable of getting the garbage out while ReferenceHandler is still able to enqueue it, allocators begin to assist. If the ReferenceHandler is out of capacity to churn the garbage down, we take matters to the extreme, and begin to scan. > This brings me to java.nio.Bits. It uses System.gc(). I understand > that allocation of native memory does not represent a memory > pressure for heap GC so you're trying to trigger it when it gets > tight. That's not really about the heap GC. That's about forcing the reference processing. I would instead like to ask runtime for another round of reference processing, but at this point that is the intimate part of GC cycle. > But lots of environments (app servers) are using > -XX:+DisableExplicitGC to prevent ill behaved libraries to trigger > GCs to frequently. Have you tried your test using > -XX:+DisableExplicitGC ? I have not. I think in that case, the fallback strategy is screwed, and we are heading for the (legal) OOME. -Aleksey. From bradford.wetmore at oracle.com Wed Oct 2 16:41:47 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 02 Oct 2013 16:41:47 +0000 Subject: hg: jdk8/tl/jdk: 8025694: Rename getStrongSecureRandom based on feedback; ... Message-ID: <20131002164200.1A7E462CAB@hg.openjdk.java.net> Changeset: a6ac824b463d Author: wetmore Date: 2013-10-02 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ac824b463d 8025694: Rename getStrongSecureRandom based on feedback 8014838: getStrongSecureRandom() should require at least one implementation Reviewed-by: mullan, darcy ! src/share/classes/java/security/SecureRandom.java ! src/share/lib/security/java.security-windows ! test/sun/security/provider/SecureRandom/StrongSecureRandom.java From xueming.shen at oracle.com Wed Oct 2 16:54:59 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 02 Oct 2013 09:54:59 -0700 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524C397E.2000303@oracle.com> References: <524C397E.2000303@oracle.com> Message-ID: <524C4FE3.1010007@oracle.com> Should move the static field BASE_DATE into ReducePrinterParser? Logically (and for performance, if it matters at all) RPP appears to be a better place for this constant. The rest looks fine. -Sherman On 10/02/2013 08:19 AM, roger riggs wrote: > Please review this fix for parsing two digit years in an Chronology. > > The webrev includes Stephen's proposed alternate method that provides > a ChronoLocalDate as the base date. > > http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ > > Thanks, Roger > > p.s. the design issue raised in the comments has been filed as [2] : 8025828 > > [1]https://bugs.openjdk.java.net/browse/JDK-8024076 > [2]https://bugs.openjdk.java.net/browse/JDK-8025828 > > From aleksey.shipilev at oracle.com Wed Oct 2 16:49:20 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 02 Oct 2013 20:49:20 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C4A6A.4030105@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> Message-ID: <524C4E90.9030205@oracle.com> On 10/02/2013 08:31 PM, Alan Bateman wrote: > On 02/10/2013 07:43, Aleksey Shipilev wrote: >> http://cr.openjdk.java.net/~shade/6857566/webrev.00/ >> > I'd like to review, I just don't have time at the moment. Thanks Alan, we can wait. > One thing that I'd like to understand is the implication of moving > from phantom to weak references. I suspected the major trouble would stem from the fact that referents are retained longer (until the weakrefs are not polled from the RQ). However, in the case of DirectByteBuffers it does not really matter since DBB themselves are not referencing much! The native memory chunk will be kept around regardless whether we used weak or phantom references. > Also the impact on mapped buffers (map implementation in > sun.nio.ch.FileChannelImpl) which will need to be changed too. ...AFAIU, the same goes for FileChannelImpl. NativeBuffer also uses Cleaner, the same reasoning applies. > Also I think we will need to include a short-running stress test as > part of this change. The original issue had the test: http://cr.openjdk.java.net/~shade/6857566/DirectBufferTest.java It fails nicely and quickly without the patch. We can convert it to jtreg. -Aleksey. From peter.levart at gmail.com Wed Oct 2 16:49:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 18:49:31 +0200 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: Message-ID: <524C4E9B.5080602@gmail.com> Hi Martin, If you want to optimize for without-security-manager case, then it would be better this way: private static void privilegedInterrupt(Thread t) { if (System.getSecurityManager() == null) { t.interrupt(); } else { PrivilegedAction doInterrupt = () -> { t.interrupt(); return null; }; AccessController.doPrivileged(doInterrupt); } } ...and no security exception catching. This way you don't trigger double security checks for case with-security-manager and not enough permission... Regards, Peter On 10/02/2013 06:29 PM, Martin Buchholz wrote: > FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) > currently running the task. > This should succeed even if modifyThread permission is denied by the > security manager. > > Here's a proposed fix for jdk8+: > > --- src/main/java/util/concurrent/FutureTask.java 15 May 2013 02:39:59 -0000 > 1.103 > +++ src/main/java/util/concurrent/FutureTask.java 2 Oct 2013 16:25:23 -0000 > @@ -132,6 +132,12 @@ > return state != NEW; > } > > + private static void privilegedInterrupt(Thread t) { > + java.security.PrivilegedAction doInterrupt = > + () -> { t.interrupt(); return null; }; > + java.security.AccessController.doPrivileged(doInterrupt); > + } > + > public boolean cancel(boolean mayInterruptIfRunning) { > if (!(state == NEW && > UNSAFE.compareAndSwapInt(this, stateOffset, NEW, > @@ -142,7 +148,11 @@ > try { > Thread t = runner; > if (t != null) > - t.interrupt(); > + try { > + t.interrupt(); > + } catch (SecurityException e) { > + privilegedInterrupt(t); > + } > } finally { // final state > UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED); > } From martinrb at google.com Wed Oct 2 16:54:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2013 09:54:30 -0700 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524C4E9B.5080602@gmail.com> References: <524C4E9B.5080602@gmail.com> Message-ID: On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart wrote: > Hi Martin, > > If you want to optimize for without-security-manager case I want to optimize for the case that Thread.interrupt does not throw SecurityException From dl at cs.oswego.edu Wed Oct 2 17:02:45 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 02 Oct 2013 13:02:45 -0400 Subject: [concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: Message-ID: <524C51B5.3040905@cs.oswego.edu> On 10/02/2013 12:29 PM, Martin Buchholz wrote: > FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) > currently running the task. > This should succeed even if modifyThread permission is denied by the security > manager. > We haven't interpreted "should" in this way in the past here or in related contexts, but I don't see are reason not to, pending any objections by security folks. -Doug > Here's a proposed fix for jdk8+: > > --- src/main/java/util/concurrent/FutureTask.java15 May 2013 02:39:59 -00001.103 > +++ src/main/java/util/concurrent/FutureTask.java2 Oct 2013 16:25:23 -0000 > @@ -132,6 +132,12 @@ > return state != NEW; > } > + private static void privilegedInterrupt(Thread t) { > + java.security.PrivilegedAction doInterrupt = > + () -> { t.interrupt(); return null; }; > + java.security.AccessController.doPrivileged(doInterrupt); > + } > + > public boolean cancel(boolean mayInterruptIfRunning) { > if (!(state == NEW && > UNSAFE.compareAndSwapInt(this, stateOffset, NEW, > @@ -142,7 +148,11 @@ > try { > Thread t = runner; > if (t != null) > - t.interrupt(); > + try { > + t.interrupt(); > + } catch (SecurityException e) { > + privilegedInterrupt(t); > + } > } finally { // final state > UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED); > } > > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > From peter.levart at gmail.com Wed Oct 2 17:15:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 19:15:41 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C4A6A.4030105@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> Message-ID: <524C54BD.8020205@gmail.com> On 10/02/2013 06:31 PM, Alan Bateman wrote: > One thing that I'd like to understand is the implication of moving > from phantom to weak references. I think Cleaners as WeakReferences are not correct. Imagine the following code: Reference refBb; { ByteBuffer dbb = ByteBuffer.allocateDirect(1000); refBb = new SoftReference<>(dbb); } System.gc(); // can clear Cleaners, might already process them ByteBuffer dbb = refBb.get(); // whoops! ...you could get a reference to direct ByteBuffer after the cleaner has already deallocated it's native memory block... Back to PhantomReference, I think. Peter From roger.riggs at oracle.com Wed Oct 2 17:20:18 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Oct 2013 13:20:18 -0400 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524C4FE3.1010007@oracle.com> References: <524C397E.2000303@oracle.com> <524C4FE3.1010007@oracle.com> Message-ID: <524C55D2.4000107@oracle.com> Hi Sherman, The BASE_DATE is the default ChronoLocalDate and is used outside of RPP. RPP itself uses any ChronoLocalDate, not the specific one. Scoping BASE_DATE to RPP would not delay the initialization since it would need to be initialized at line 1715. Roger On 10/2/2013 12:54 PM, Xueming Shen wrote: > Should move the static field BASE_DATE into ReducePrinterParser? > Logically (and for performance, if it matters at all) RPP appears to > be a better place for this constant. > > The rest looks fine. > > -Sherman > > On 10/02/2013 08:19 AM, roger riggs wrote: >> Please review this fix for parsing two digit years in an Chronology. >> >> The webrev includes Stephen's proposed alternate method that provides >> a ChronoLocalDate as the base date. >> >> http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ >> >> Thanks, Roger >> >> p.s. the design issue raised in the comments has been filed as [2] : >> 8025828 >> >> [1]https://bugs.openjdk.java.net/browse/JDK-8024076 >> [2]https://bugs.openjdk.java.net/browse/JDK-8025828 >> >> > From aleksey.shipilev at oracle.com Wed Oct 2 17:30:01 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 02 Oct 2013 21:30:01 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C54BD.8020205@gmail.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C54BD.8020205@gmail.com> Message-ID: <524C5819.1030807@oracle.com> On 10/02/2013 09:15 PM, Peter Levart wrote: > On 10/02/2013 06:31 PM, Alan Bateman wrote: >> One thing that I'd like to understand is the implication of moving >> from phantom to weak references. > > I think Cleaners as WeakReferences are not correct. > > Imagine the following code: > > Reference refBb; > { > ByteBuffer dbb = ByteBuffer.allocateDirect(1000); > refBb = new SoftReference<>(dbb); > } > System.gc(); // can clear Cleaners, might already process them > > > ByteBuffer dbb = refBb.get(); // whoops! > > > ...you could get a reference to direct ByteBuffer after the cleaner has > already deallocated it's native memory block... Ummm, aren't the Cleaners forbidden to run in this case? The strength is: strong > soft > weak > phantom, that is: We can not process strongly-reachable soft references. We can not process strongly/softly-reachable weak references. We can not process strongly/softly/weakly-reachable phantom references. If you keep the either strong or soft reference to dbb, then it's softly reachable, not yet weakly-reachable, and then Cleaners are still standing by. Note that Cleaners might run if your dbb is phantomly-reachable, but that is OK, since you will not be able to recover dbb through phantomref anyway. -Aleksey. From xueming.shen at oracle.com Wed Oct 2 17:50:52 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 02 Oct 2013 10:50:52 -0700 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524C55D2.4000107@oracle.com> References: <524C397E.2000303@oracle.com> <524C4FE3.1010007@oracle.com> <524C55D2.4000107@oracle.com> Message-ID: <524C5CFC.50307@oracle.com> On 10/02/2013 10:20 AM, roger riggs wrote: > Hi Sherman, > > The BASE_DATE is the default ChronoLocalDate and is used outside of RPP. > RPP itself uses any ChronoLocalDate, not the specific one. > Scoping BASE_DATE to RPP would not delay the initialization > since it would need to be initialized at line 1715. The BASE_DATE will not be initialized until the code runs into line#1715, if we hide the BASE_DATE into RPP, which might benefit applications that never uses the "reducedValue" functionality. The BASE_DATE is something only used for appendValueReduced() functionality and RPP is its implementation, so I don't see any probably logically to move it into RPP, maybe rename it to ISO_BASE_DATE... -Sherman > > Roger > > > > On 10/2/2013 12:54 PM, Xueming Shen wrote: >> Should move the static field BASE_DATE into ReducePrinterParser? >> Logically (and for performance, if it matters at all) RPP appears to >> be a better place for this constant. >> >> The rest looks fine. >> >> -Sherman >> >> On 10/02/2013 08:19 AM, roger riggs wrote: >>> Please review this fix for parsing two digit years in an Chronology. >>> >>> The webrev includes Stephen's proposed alternate method that provides >>> a ChronoLocalDate as the base date. >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ >>> >>> Thanks, Roger >>> >>> p.s. the design issue raised in the comments has been filed as [2] : 8025828 >>> >>> [1]https://bugs.openjdk.java.net/browse/JDK-8024076 >>> [2]https://bugs.openjdk.java.net/browse/JDK-8025828 >>> >>> >> > From christian.thalinger at oracle.com Wed Oct 2 18:23:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 11:23:59 -0700 Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members In-Reply-To: <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com> References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com> <239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com> <523C69EA.3030107@oracle.com> <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com> Message-ID: Since there is no new webrev I assume you incorporated all the stuff below. If that's the case then it looks good. On Sep 20, 2013, at 6:18 PM, John Rose wrote: > On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov wrote: > >> John, >> >> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it. > > OK. I think I had it in mainly to make sure the unit tests did something interesting. > >> Regarding the test: >> 31 * @run main/othervm/timeout=3600 >> - why do you have timeout set to 1h? > > Copy-and-paste from some other test. Removed. > >> I like the idea how you count events. >> >> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized. > > Good idea. But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types. I did the following, for each of the six test cases: > > @@ -150,9 +150,11 @@ > } > > private static int runFoo() throws Throwable { > + assertEquals(Init1Tick, 0); // Init1 not initialized yet > int t1 = tick("runFoo"); > int t2 = (int) INDY_foo().invokeExact(); > int t3 = tick("runFoo done"); > + assertEquals(Init1Tick, t2); // when Init1 was initialized > assertEquals(t1+2, t3); // exactly two ticks in between > assertEquals(t1+1, t2); // init happened inside > return t2; > > > ? John > >> Best regards, >> Vladimir Ivanov >> >> On 9/20/13 1:38 AM, John Rose wrote: >>> On Sep 12, 2013, at 7:24 PM, John Rose >> > wrote: >>> >>>> Please review this change for a change to the JSR 292 implementation: >>>> >>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/ >>>> >>>> Summary: Align MH semantic with bytecode behavior of constructor and >>>> static member accesses, regarding invocation. >>>> >>>> The change is to javadoc and unit tests, documenting and testing some >>>> corner cases of JSR 292 APIs. >>> >>> I have a reviewer (Alex Buckley) for the documentation changes, but I >>> would also like a quick code review for the unit test. >>> >>> Also, there is a code insertion (predicated on a "false" symbolic >>> constant) which serves to document the buggy JDK 7 behavior. I'm not >>> particularly attached to it, so I'm open to either a yea or nay on >>> keeping it. Leaning nay at the moment. >>> >>> ? John >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From xueming.shen at oracle.com Wed Oct 2 18:43:13 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 02 Oct 2013 11:43:13 -0700 Subject: Please Review java.time static interface methods move to supporting class In-Reply-To: <524C4352.1030807@oracle.com> References: <524C4352.1030807@oracle.com> Message-ID: <524C6941.9020808@oracle.com> Hi, While it might make sense to have method to return the adjuster for TemporalAdjusters, is there any real benefit to have those parentheses for TemporalQueries? Maybe it can just be an enum? Or we are considering adding more parametrized adjusters in the future? Aren't we? Now all interfaces and their corresponding utilities are TemporalXYZ, maybe it is worth considering just to drop the "Temporal"? I know I may ask too much:-) The rest looks fine. -Sherman On 10/02/2013 09:01 AM, roger riggs wrote: > As noted in the issue[1], the static methods in the TemporalAdjuster and TemporalQuery > interfaces that provide implementations of Adjusters and Queries seem out of > place and are better located in a related supporting class so the purpose and > function of the interfaces are not diluted. Adding more methods in the future > will be a better fit in the class. > > The static methods of TemporalAdjuster are moved to TemporalAdjusters > and the static method of TemporalQuery are moved to TemporalQueries. > Those classes were previously package private and are now public. > > Please review and comment: > > javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8025722 > > From roger.riggs at oracle.com Wed Oct 2 18:41:22 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Oct 2013 14:41:22 -0400 Subject: Please Review fix for reduced value parser 8024076 In-Reply-To: <524C5CFC.50307@oracle.com> References: <524C397E.2000303@oracle.com> <524C4FE3.1010007@oracle.com> <524C55D2.4000107@oracle.com> <524C5CFC.50307@oracle.com> Message-ID: <524C68D2.1010706@oracle.com> Hi Sherman, Thanks for the detailed review, the webrev has been updated with your recommendation. Roger On 10/2/2013 1:50 PM, Xueming Shen wrote: > On 10/02/2013 10:20 AM, roger riggs wrote: >> Hi Sherman, >> >> The BASE_DATE is the default ChronoLocalDate and is used outside of RPP. >> RPP itself uses any ChronoLocalDate, not the specific one. >> Scoping BASE_DATE to RPP would not delay the initialization >> since it would need to be initialized at line 1715. > > The BASE_DATE will not be initialized until the code runs into > line#1715, if > we hide the BASE_DATE into RPP, which might benefit applications that > never uses the "reducedValue" functionality. The BASE_DATE is something > only used for appendValueReduced() functionality and RPP is its > implementation, > so I don't see any probably logically to move it into RPP, maybe > rename it > to ISO_BASE_DATE... > > -Sherman > > >> >> Roger >> >> >> >> On 10/2/2013 12:54 PM, Xueming Shen wrote: >>> Should move the static field BASE_DATE into ReducePrinterParser? >>> Logically (and for performance, if it matters at all) RPP appears to >>> be a better place for this constant. >>> >>> The rest looks fine. >>> >>> -Sherman >>> >>> On 10/02/2013 08:19 AM, roger riggs wrote: >>>> Please review this fix for parsing two digit years in an Chronology. >>>> >>>> The webrev includes Stephen's proposed alternate method that provides >>>> a ChronoLocalDate as the base date. >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/ >>>> >>>> Thanks, Roger >>>> >>>> p.s. the design issue raised in the comments has been filed as [2] >>>> : 8025828 >>>> >>>> [1]https://bugs.openjdk.java.net/browse/JDK-8024076 >>>> [2]https://bugs.openjdk.java.net/browse/JDK-8025828 >>>> >>>> >>> >> > From peter.levart at gmail.com Wed Oct 2 18:46:11 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Oct 2013 20:46:11 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C5819.1030807@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C54BD.8020205@gmail.com> <524C5819.1030807@oracle.com> Message-ID: <524C69F3.7080908@gmail.com> On 10/02/2013 07:30 PM, Aleksey Shipilev wrote: > On 10/02/2013 09:15 PM, Peter Levart wrote: >> On 10/02/2013 06:31 PM, Alan Bateman wrote: >>> One thing that I'd like to understand is the implication of moving >>> from phantom to weak references. >> I think Cleaners as WeakReferences are not correct. >> >> Imagine the following code: >> >> Reference refBb; >> { >> ByteBuffer dbb = ByteBuffer.allocateDirect(1000); >> refBb = new SoftReference<>(dbb); >> } >> System.gc(); // can clear Cleaners, might already process them >> >> >> ByteBuffer dbb = refBb.get(); // whoops! >> >> >> ...you could get a reference to direct ByteBuffer after the cleaner has >> already deallocated it's native memory block... > Ummm, aren't the Cleaners forbidden to run in this case? > > The strength is: strong > soft > weak > phantom, that is: > We can not process strongly-reachable soft references. > We can not process strongly/softly-reachable weak references. > We can not process strongly/softly/weakly-reachable phantom references. > > If you keep the either strong or soft reference to dbb, then it's softly > reachable, not yet weakly-reachable, and then Cleaners are still > standing by. Note that Cleaners might run if your dbb is > phantomly-reachable, but that is OK, since you will not be able to > recover dbb through phantomref anyway. You're right. I jumped to conclusion to quickly. I was mislead by the agility of a particular reference type to be cleared. It only makes sense that the strength is inversely proportional to agility. Regards, Peter > -Aleksey. From eric.mccorkle at oracle.com Wed Oct 2 18:55:38 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 02 Oct 2013 14:55:38 -0400 Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions In-Reply-To: <524B304E.1090601@oracle.com> References: <5233260C.3010607@oracle.com> <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com> <52334CED.1030900@oracle.com> <52335156.3050308@gmail.com> <52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com> <523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com> <523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com> <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com> <5241E4CB.5030807@oracle.com> <524A6E83.5000802@oracle.com> <524B304E.1090601@oracle.com> Message-ID: <524C6C2A.4020408@oracle.com> I've updated the test, switched to an in-memory class loader, and added a test case. Please review. On 10/01/13 16:27, Eric McCorkle wrote: > On 10/01/13 02:41, Joe Darcy wrote: > > (Suggested changes have been applied) > >> >> I think the test is acceptable as-is, but an RFE could be filed for some >> refactoring (having each bad class be represented as a diff from a base >> byte[], avoiding sending the bytes through the file system). >> > > Better yet: I've filed an RFE for a framework for generating bad class > files. > > Webrev has been updated, please review: > http://cr.openjdk.java.net/~emc/8020981/ > >> Cheers, >> >> -Joe >> >> On 9/24/2013 12:15 PM, Eric McCorkle wrote: >>> Webrev updated to address these issues. >>> >>> On 09/24/13 07:51, Joel Borggren-Franck wrote: >>> >>>> 364 try { >>>> 365 tmp = getParameters0(); >>>> 366 } catch(IllegalArgumentException e) { >>>> 367 // Rethrow ClassFormatErrors >>>> 368 throw new MalformedParametersException("Invalid >>>> constant pool index"); >>>> 369 } >>>> >>>> What is causing the IAE? Have you considered having >>>> MalformedParametersExcepton taking a Throwable cause and having the IAE >>>> as cause? >>>> >>> The IAE comes from hotspot itself. There is a standard constant pool >>> index verifying function that throws IAE if given a bad index. >>> >>>> On 2013-09-19, Eric McCorkle wrote: >>>>> The webrev has been updated with Joe's comments addressed. >>>>> >>>>> On 09/19/13 00:11, David Holmes wrote: >>>>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote: >>>>>>> This still needs to be reviewed. >>>>>> You seem to have ignored Joe's comments regarding the change to >>>>>> Modifier >>>>>> being incorrect. >>>>>> >>>>>> David >>>>>> >>>>>>> On 09/16/13 14:50, Eric McCorkle wrote: >>>>>>>> I pulled the class files into byte array constants, as a temporary >>>>>>>> measure until a viable method for testing bad class files is >>>>>>>> developed. >>>>>>>> >>>>>>>> The webrev has been refreshed. The class files will be taken out >>>>>>>> before >>>>>>>> I push. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>> >>>>>>>> On 09/13/13 20:48, Joe Darcy wrote: >>>>>>>>> To avoid storing binaries in Hg, you could try something like: >>>>>>>>> >>>>>>>>> * uuencode / ascii armor the class file >>>>>>>>> * convert to byte array in the test >>>>>>>>> * load classes from byte array >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote: >>>>>>>>>> I did it by hand with emacs. >>>>>>>>>> >>>>>>>>>> I would really rather tackle the bad class files for testing issue >>>>>>>>>> once >>>>>>>>>> and for all, the Right Way (tm). But with ZBB looming, now is >>>>>>>>>> not the >>>>>>>>>> time to do it. >>>>>>>>>> >>>>>>>>>> Hence, I have created this task >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674 >>>>>>>>>> >>>>>>>>>> I also just created this one: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812 >>>>>>>>>> >>>>>>>>>> On 09/13/13 13:54, Peter Levart wrote: >>>>>>>>>>> Hi Eric, >>>>>>>>>>> >>>>>>>>>>> How did you create those class files? By hand using a HEX >>>>>>>>>>> editor? Did >>>>>>>>>>> you create a program that patched the original class file? If the >>>>>>>>>>> later >>>>>>>>>>> is the case, you could pack that patching logic inside a custom >>>>>>>>>>> ClassLoader... >>>>>>>>>>> >>>>>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad >>>>>>>>>>> name" >>>>>>>>>>> patching could be performed trivially and reliably, I think: >>>>>>>>>>> search and >>>>>>>>>>> replace with same-length string. >>>>>>>>>>> >>>>>>>>>>> Regards, Peter >>>>>>>>>>> >>>>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote: >>>>>>>>>>>> Ugh. Byte arrays of class file data is really a horrible >>>>>>>>>>>> solution. >>>>>>>>>>>> >>>>>>>>>>>> I have already filed a task for test development post ZBB to >>>>>>>>>>>> develop a >>>>>>>>>>>> solution for generating bad class files. I'd prefer to file a >>>>>>>>>>>> follow-up >>>>>>>>>>>> to this to add the bad class file tests when that's done. >>>>>>>>>>>> >>>>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>> I think the right thing to do is to include the original >>>>>>>>>>>>> compiling >>>>>>>>>>>>> source in a comment, together with a comment on how you modify >>>>>>>>>>>>> them, and then the result as a byte array. >>>>>>>>>>>>> >>>>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our >>>>>>>>>>>>> repo. >>>>>>>>>>>>> >>>>>>>>>>>>> cheers >>>>>>>>>>>>> /Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> There is no simple means of generating bad class files for >>>>>>>>>>>>>> testing. >>>>>>>>>>>>>> This is a huge deficiency in our testing abilities. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no >>>>>>>>>>>>>> choice >>>>>>>>>>>>>> but >>>>>>>>>>>>>> to check in no test for this patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, anyone can run the test I've provided with the class >>>>>>>>>>>>>> files and >>>>>>>>>>>>>> see that it works. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> IIRC we don't check in classfiles into the repo. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files >>>>>>>>>>>>>>> in jdk, >>>>>>>>>>>>>>> but ASM might be an option, or storing the class file as an >>>>>>>>>>>>>>> embedded byte array in the test. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which >>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>> validates >>>>>>>>>>>>>>>> parameter names correctly. Apologies for the last one. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review this patch, which implements correct >>>>>>>>>>>>>>>>> behavior for >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class >>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The bug report is here: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The webrev is here: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This review is also on crucible. The ID is CR-JDK8TL-182. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >> From tom.hawtin at oracle.com Wed Oct 2 19:18:25 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Wed, 02 Oct 2013 20:18:25 +0100 Subject: [concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524C51B5.3040905@cs.oswego.edu> References: <524C51B5.3040905@cs.oswego.edu> Message-ID: <524C7181.3060802@oracle.com> On 02/10/2013 18:02, Doug Lea wrote: > On 10/02/2013 12:29 PM, Martin Buchholz wrote: >> FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) >> currently running the task. >> This should succeed even if modifyThread permission is denied by the >> security >> manager. >> > > We haven't interpreted "should" in this way in the past here or in > related contexts, but I don't see are reason not to, pending any > objections by security folks. Objection. I can straightaway see a way of getting an instance of a JDK-8 FutureTask with a runner that is not current running the FutureTask.run, without so much as needing a race. That would allow an adversary to to interrupt a thread in contravention of the security policy. Tom From christian.thalinger at oracle.com Wed Oct 2 19:17:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 12:17:57 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity In-Reply-To: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> Message-ID: <5CD24332-806B-47A5-B3B6-150E98993BFD@oracle.com> Thank you for doing this; it is much clearer now. Looks good. On Oct 1, 2013, at 10:19 PM, John Rose wrote: > Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable. > > Here is the respin: > http://cr.openjdk.java.net/~jrose/8025112/webrev.01 > > ? John > > On Oct 1, 2013, at 3:15 PM, John Rose wrote: > >> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. >> >> It also adjusts some unit tests. >> >> The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. >> >> The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. >> >> http://cr.openjdk.java.net/~jrose/8025112/webrev.00 >> >> For more background, see my JavaOne presentation: >> http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf >> >> Thanks, >> ? John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From martinrb at google.com Wed Oct 2 19:31:51 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2013 12:31:51 -0700 Subject: [concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524C7181.3060802@oracle.com> References: <524C51B5.3040905@cs.oswego.edu> <524C7181.3060802@oracle.com> Message-ID: On Wed, Oct 2, 2013 at 12:18 PM, Tom Hawtin wrote: > On 02/10/2013 18:02, Doug Lea wrote: > >> On 10/02/2013 12:29 PM, Martin Buchholz wrote: >> >>> FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) >>> currently running the task. >>> This should succeed even if modifyThread permission is denied by the >>> security >>> manager. >>> >>> >> We haven't interpreted "should" in this way in the past here or in >> related contexts, but I don't see are reason not to, pending any >> objections by security folks. >> > > Objection. I can straightaway see a way of getting an instance of a JDK-8 > FutureTask with a runner that is not current running the FutureTask.run, > without so much as needing a race. That would allow an adversary to to > interrupt a thread in contravention of the security policy. Interesting - FutureTask is designed to not make that possible - runner is not exposed, and is supposed to be set only while executing the task. Do we have a bug? From john.r.rose at oracle.com Wed Oct 2 19:33:33 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 2 Oct 2013 12:33:33 -0700 Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members In-Reply-To: References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com> <239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com> <523C69EA.3030107@oracle.com> <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com> Message-ID: Push-button webrev generator to the rescue: http://cr.openjdk.java.net/~jrose/8024599/webrev.01 ? John On Oct 2, 2013, at 11:23 AM, Christian Thalinger wrote: > Since there is no new webrev I assume you incorporated all the stuff below. If that's the case then it looks good. > > On Sep 20, 2013, at 6:18 PM, John Rose wrote: > >> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov wrote: >> >>> John, >>> >>> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it. >> >> OK. I think I had it in mainly to make sure the unit tests did something interesting. > >> >>> Regarding the test: >>> 31 * @run main/othervm/timeout=3600 >>> - why do you have timeout set to 1h? >> >> Copy-and-paste from some other test. Removed. >> >>> I like the idea how you count events. >>> >>> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized. >> >> Good idea. But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types. I did the following, for each of the six test cases: >> >> @@ -150,9 +150,11 @@ >> } >> >> private static int runFoo() throws Throwable { >> + assertEquals(Init1Tick, 0); // Init1 not initialized yet >> int t1 = tick("runFoo"); >> int t2 = (int) INDY_foo().invokeExact(); >> int t3 = tick("runFoo done"); >> + assertEquals(Init1Tick, t2); // when Init1 was initialized >> assertEquals(t1+2, t3); // exactly two ticks in between >> assertEquals(t1+1, t2); // init happened inside >> return t2; > >> >> >> ? John >> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 9/20/13 1:38 AM, John Rose wrote: >>>> On Sep 12, 2013, at 7:24 PM, John Rose >>> > wrote: >>>> >>>>> Please review this change for a change to the JSR 292 implementation: >>>>> >>>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/ >>>>> >>>>> Summary: Align MH semantic with bytecode behavior of constructor and >>>>> static member accesses, regarding invocation. >>>>> >>>>> The change is to javadoc and unit tests, documenting and testing some >>>>> corner cases of JSR 292 APIs. >>>> >>>> I have a reviewer (Alex Buckley) for the documentation changes, but I >>>> would also like a quick code review for the unit test. >>>> >>>> Also, there is a code insertion (predicated on a "false" symbolic >>>> constant) which serves to document the buggy JDK 7 behavior. I'm not >>>> particularly attached to it, so I'm open to either a yea or nay on >>>> keeping it. Leaning nay at the moment. >>>> >>>> ? John >>>> >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Wed Oct 2 19:38:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 12:38:40 -0700 Subject: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector In-Reply-To: References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> <523CC710.5030806@oracle.com> Message-ID: <5CE51916-2D1B-4FA6-A8EF-52A71C832839@oracle.com> On Sep 20, 2013, at 5:09 PM, John Rose wrote: > On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov wrote: > >> I cleaned javadoc a little [1], so it is more readable in the browser now. > > Thanks; I applied those edits. I fixed the problem of a missing

in a few other places too. > >> The test code looks ok, though the logic is over-complicated. >> But the whole MethodHandlesTest is written in the same vein. > > Thanks. (Looks like it wasn't written by a real test engineer.) :-D I try to not touch MethodHandlesTest. We should think about splitting it into smaller test cases. > > ? John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From brian.burkhalter at oracle.com Wed Oct 2 19:40:14 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Oct 2013 12:40:14 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524B96BB.4020301@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: All, Please see comments inline. Thanks, Brian On Oct 1, 2013, at 8:44 PM, Alan Bateman wrote: > On 01/10/2013 12:46, Brian Burkhalter wrote: >> : >> >> I updated the webrev >> >> http://cr.openjdk.java.net/~bpb/8010371/ >> >> with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. >> >> Brian > This looks better, although I think I would reverse re-write the expressions to "if (error = ...)". I agree that is an ugly style but it guarantees that mistakes such as if (error = EAI_AGAIN) {} are caught at compilation time. > One thing to consider is whether this condition is really worth introducing HostLookupException, particularly when it doesn't include additional information (except to distinguish it from its supertype). If a new exception is really needed then maybe it could add the error message obtained from gai_strerror, alternatively maybe you could considered setting the cause of the UHE to something like an IOException with the translation of the error. On Oct 2, 2013, at 7:40 AM, Chris Hegarty wrote: > On 02/10/2013 04:44, Alan Bateman wrote: >> >> One thing to consider is whether this condition is really worth >> introducing HostLookupException, particularly when it doesn't include > > I am also not convinced of the merits of adding a new public checked Exception type for this situation. Do we expect all callers of API's that can throw UKE to now have to catch this Exception and provide their own try logic? Otherwise, what do we expect them to do with it. > > I cannot see the original webrev, so cannot comment on the retry logic that was there. Do you still have it around? Can upload as a .05 version? The reason I ask is that, IMHO, I would prefer this type of approach over the new Exception type, but that could be just me. No, I do not have it. On Oct 2, 2013, at 7:58 AM, Michael McMahon wrote: > On 02/10/13 15:40, Chris Hegarty wrote: >> >> I am also not convinced of the merits of adding a new public checked Exception type for this situation. Do we expect all callers of API's that can throw UKE to now have to catch this Exception and provide their own try logic? Otherwise, what do we expect them to do with it. >> > > It's proposed as a subclass of UnknownHostException. So, nobody would have to catch it. > > I suppose another approach, which is a variant of the first one suggested, would be > retry logic built in, which is switched off by default and configurable somehow. I personally do not like the idea of the configurable approach. On Oct 2, 2013, at 8:12 AM, Chris Hegarty wrote: > On 02/10/2013 15:58, Michael McMahon wrote: >> >> It's proposed as a subclass of UnknownHostException. So, nobody would >> have to catch it. > > Right, understood. But unless someone adds explicit handling code when there is no change in existing behavior. Well this is good in the sense that existing code would not be affected negatively but it would require that code be changed for the application explicitly to do a retry. >> I suppose another approach, which is a variant of the first one >> suggested, would be >> retry logic built in, which is switched off by default and configurable >> somehow. > > I did not see the retry webrev so cannot comment on the specifics, but I don't see any issue with a single untimed retry, if that fails throw an UHE with a specific cause. This is close to what I original thought to do modulo the exception class. So, how about this approach: 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. Questions: A) Would it be better to do the retry in the Java layer, perhaps with a very short wait? B) Should the message or cause in #2 be explicitly document in the javadoc? From chris.hegarty at oracle.com Wed Oct 2 19:53:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Oct 2013 20:53:14 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: <524C79AA.4090209@oracle.com> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: > .... > So, how about this approach: > > 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. > 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. Sounds good to me. > Questions: > > A) Would it be better to do the retry in the Java layer, perhaps with a very short wait? native, without any wait, should be sufficient. > B) Should the message or cause in #2 be explicitly document in the javadoc? I don't think it is necessary for this to be documented. It is more informational. -Chris. From joe.darcy at oracle.com Wed Oct 2 19:54:12 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 02 Oct 2013 12:54:12 -0700 Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions In-Reply-To: <524C6C2A.4020408@oracle.com> References: <5233260C.3010607@oracle.com> <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com> <52334CED.1030900@oracle.com> <52335156.3050308@gmail.com> <52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com> <523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com> <523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com> <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com> <5241E4CB.5030807@oracle.com> <524A6E83.5000802@oracle.com> <524B304E.1090601@oracle.com> <524C6C2A.4020408@oracle.com> Message-ID: <524C79E4.8040303@oracle.com> Hi Eric, Please revert the change to j.l.r.Modifer. The fix can be pushed with just that modification; however, I strongly recommend also removing the "here is everything that can go wrong" list from j.l.r.Executable. Core reflection generally doesn't delve into such details in the main-line API docs and calling the details out in the exception type should be sufficient. Cheers, -Joe On 10/2/2013 11:55 AM, Eric McCorkle wrote: > I've updated the test, switched to an in-memory class loader, and added > a test case. Please review. > > On 10/01/13 16:27, Eric McCorkle wrote: >> On 10/01/13 02:41, Joe Darcy wrote: >> >> (Suggested changes have been applied) >> >>> I think the test is acceptable as-is, but an RFE could be filed for some >>> refactoring (having each bad class be represented as a diff from a base >>> byte[], avoiding sending the bytes through the file system). >>> >> Better yet: I've filed an RFE for a framework for generating bad class >> files. >> >> Webrev has been updated, please review: >> http://cr.openjdk.java.net/~emc/8020981/ >> >>> Cheers, >>> >>> -Joe >>> >>> On 9/24/2013 12:15 PM, Eric McCorkle wrote: >>>> Webrev updated to address these issues. >>>> >>>> On 09/24/13 07:51, Joel Borggren-Franck wrote: >>>> >>>>> 364 try { >>>>> 365 tmp = getParameters0(); >>>>> 366 } catch(IllegalArgumentException e) { >>>>> 367 // Rethrow ClassFormatErrors >>>>> 368 throw new MalformedParametersException("Invalid >>>>> constant pool index"); >>>>> 369 } >>>>> >>>>> What is causing the IAE? Have you considered having >>>>> MalformedParametersExcepton taking a Throwable cause and having the IAE >>>>> as cause? >>>>> >>>> The IAE comes from hotspot itself. There is a standard constant pool >>>> index verifying function that throws IAE if given a bad index. >>>> >>>>> On 2013-09-19, Eric McCorkle wrote: >>>>>> The webrev has been updated with Joe's comments addressed. >>>>>> >>>>>> On 09/19/13 00:11, David Holmes wrote: >>>>>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote: >>>>>>>> This still needs to be reviewed. >>>>>>> You seem to have ignored Joe's comments regarding the change to >>>>>>> Modifier >>>>>>> being incorrect. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> On 09/16/13 14:50, Eric McCorkle wrote: >>>>>>>>> I pulled the class files into byte array constants, as a temporary >>>>>>>>> measure until a viable method for testing bad class files is >>>>>>>>> developed. >>>>>>>>> >>>>>>>>> The webrev has been refreshed. The class files will be taken out >>>>>>>>> before >>>>>>>>> I push. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>> >>>>>>>>> On 09/13/13 20:48, Joe Darcy wrote: >>>>>>>>>> To avoid storing binaries in Hg, you could try something like: >>>>>>>>>> >>>>>>>>>> * uuencode / ascii armor the class file >>>>>>>>>> * convert to byte array in the test >>>>>>>>>> * load classes from byte array >>>>>>>>>> >>>>>>>>>> -Joe >>>>>>>>>> >>>>>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote: >>>>>>>>>>> I did it by hand with emacs. >>>>>>>>>>> >>>>>>>>>>> I would really rather tackle the bad class files for testing issue >>>>>>>>>>> once >>>>>>>>>>> and for all, the Right Way (tm). But with ZBB looming, now is >>>>>>>>>>> not the >>>>>>>>>>> time to do it. >>>>>>>>>>> >>>>>>>>>>> Hence, I have created this task >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674 >>>>>>>>>>> >>>>>>>>>>> I also just created this one: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812 >>>>>>>>>>> >>>>>>>>>>> On 09/13/13 13:54, Peter Levart wrote: >>>>>>>>>>>> Hi Eric, >>>>>>>>>>>> >>>>>>>>>>>> How did you create those class files? By hand using a HEX >>>>>>>>>>>> editor? Did >>>>>>>>>>>> you create a program that patched the original class file? If the >>>>>>>>>>>> later >>>>>>>>>>>> is the case, you could pack that patching logic inside a custom >>>>>>>>>>>> ClassLoader... >>>>>>>>>>>> >>>>>>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad >>>>>>>>>>>> name" >>>>>>>>>>>> patching could be performed trivially and reliably, I think: >>>>>>>>>>>> search and >>>>>>>>>>>> replace with same-length string. >>>>>>>>>>>> >>>>>>>>>>>> Regards, Peter >>>>>>>>>>>> >>>>>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote: >>>>>>>>>>>>> Ugh. Byte arrays of class file data is really a horrible >>>>>>>>>>>>> solution. >>>>>>>>>>>>> >>>>>>>>>>>>> I have already filed a task for test development post ZBB to >>>>>>>>>>>>> develop a >>>>>>>>>>>>> solution for generating bad class files. I'd prefer to file a >>>>>>>>>>>>> follow-up >>>>>>>>>>>>> to this to add the bad class file tests when that's done. >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>> I think the right thing to do is to include the original >>>>>>>>>>>>>> compiling >>>>>>>>>>>>>> source in a comment, together with a comment on how you modify >>>>>>>>>>>>>> them, and then the result as a byte array. >>>>>>>>>>>>>> >>>>>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our >>>>>>>>>>>>>> repo. >>>>>>>>>>>>>> >>>>>>>>>>>>>> cheers >>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no simple means of generating bad class files for >>>>>>>>>>>>>>> testing. >>>>>>>>>>>>>>> This is a huge deficiency in our testing abilities. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no >>>>>>>>>>>>>>> choice >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> to check in no test for this patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, anyone can run the test I've provided with the class >>>>>>>>>>>>>>> files and >>>>>>>>>>>>>>> see that it works. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> IIRC we don't check in classfiles into the repo. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files >>>>>>>>>>>>>>>> in jdk, >>>>>>>>>>>>>>>> but ASM might be an option, or storing the class file as an >>>>>>>>>>>>>>>> embedded byte array in the test. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which >>>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>> validates >>>>>>>>>>>>>>>>> parameter names correctly. Apologies for the last one. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review this patch, which implements correct >>>>>>>>>>>>>>>>>> behavior for >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class >>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The bug report is here: >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The webrev is here: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This review is also on crucible. The ID is CR-JDK8TL-182. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From eric.mccorkle at oracle.com Wed Oct 2 20:08:56 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 02 Oct 2013 16:08:56 -0400 Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions In-Reply-To: <524C79E4.8040303@oracle.com> References: <5233260C.3010607@oracle.com> <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com> <52334CED.1030900@oracle.com> <52335156.3050308@gmail.com> <52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com> <523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com> <523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com> <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com> <5241E4CB.5030807@oracle.com> <524A6E83.5000802@oracle.com> <524B304E.1090601@oracle.com> <524C6C2A.4020408@oracle.com> <524C79E4.8040303@oracle.com> Message-ID: <524C7D58.9020609@oracle.com> Thanks, Joe. I reverted Modifier, and removed the list (I thought I had done that already). I will push after a successful test run. On 10/02/13 15:54, Joe Darcy wrote: > Hi Eric, > > Please revert the change to j.l.r.Modifer. The fix can be pushed with > just that modification; however, I strongly recommend also removing the > "here is everything that can go wrong" list from j.l.r.Executable. Core > reflection generally doesn't delve into such details in the main-line > API docs and calling the details out in the exception type should be > sufficient. > > Cheers, > > -Joe > > On 10/2/2013 11:55 AM, Eric McCorkle wrote: >> I've updated the test, switched to an in-memory class loader, and added >> a test case. Please review. >> >> On 10/01/13 16:27, Eric McCorkle wrote: >>> On 10/01/13 02:41, Joe Darcy wrote: >>> >>> (Suggested changes have been applied) >>> >>>> I think the test is acceptable as-is, but an RFE could be filed for >>>> some >>>> refactoring (having each bad class be represented as a diff from a base >>>> byte[], avoiding sending the bytes through the file system). >>>> >>> Better yet: I've filed an RFE for a framework for generating bad class >>> files. >>> >>> Webrev has been updated, please review: >>> http://cr.openjdk.java.net/~emc/8020981/ >>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 9/24/2013 12:15 PM, Eric McCorkle wrote: >>>>> Webrev updated to address these issues. >>>>> >>>>> On 09/24/13 07:51, Joel Borggren-Franck wrote: >>>>> >>>>>> 364 try { >>>>>> 365 tmp = getParameters0(); >>>>>> 366 } catch(IllegalArgumentException e) { >>>>>> 367 // Rethrow ClassFormatErrors >>>>>> 368 throw new MalformedParametersException("Invalid >>>>>> constant pool index"); >>>>>> 369 } >>>>>> >>>>>> What is causing the IAE? Have you considered having >>>>>> MalformedParametersExcepton taking a Throwable cause and having >>>>>> the IAE >>>>>> as cause? >>>>>> >>>>> The IAE comes from hotspot itself. There is a standard constant pool >>>>> index verifying function that throws IAE if given a bad index. >>>>> >>>>>> On 2013-09-19, Eric McCorkle wrote: >>>>>>> The webrev has been updated with Joe's comments addressed. >>>>>>> >>>>>>> On 09/19/13 00:11, David Holmes wrote: >>>>>>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote: >>>>>>>>> This still needs to be reviewed. >>>>>>>> You seem to have ignored Joe's comments regarding the change to >>>>>>>> Modifier >>>>>>>> being incorrect. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> On 09/16/13 14:50, Eric McCorkle wrote: >>>>>>>>>> I pulled the class files into byte array constants, as a >>>>>>>>>> temporary >>>>>>>>>> measure until a viable method for testing bad class files is >>>>>>>>>> developed. >>>>>>>>>> >>>>>>>>>> The webrev has been refreshed. The class files will be taken out >>>>>>>>>> before >>>>>>>>>> I push. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>> >>>>>>>>>> On 09/13/13 20:48, Joe Darcy wrote: >>>>>>>>>>> To avoid storing binaries in Hg, you could try something like: >>>>>>>>>>> >>>>>>>>>>> * uuencode / ascii armor the class file >>>>>>>>>>> * convert to byte array in the test >>>>>>>>>>> * load classes from byte array >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote: >>>>>>>>>>>> I did it by hand with emacs. >>>>>>>>>>>> >>>>>>>>>>>> I would really rather tackle the bad class files for testing >>>>>>>>>>>> issue >>>>>>>>>>>> once >>>>>>>>>>>> and for all, the Right Way (tm). But with ZBB looming, now is >>>>>>>>>>>> not the >>>>>>>>>>>> time to do it. >>>>>>>>>>>> >>>>>>>>>>>> Hence, I have created this task >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674 >>>>>>>>>>>> >>>>>>>>>>>> I also just created this one: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812 >>>>>>>>>>>> >>>>>>>>>>>> On 09/13/13 13:54, Peter Levart wrote: >>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>> >>>>>>>>>>>>> How did you create those class files? By hand using a HEX >>>>>>>>>>>>> editor? Did >>>>>>>>>>>>> you create a program that patched the original class file? >>>>>>>>>>>>> If the >>>>>>>>>>>>> later >>>>>>>>>>>>> is the case, you could pack that patching logic inside a >>>>>>>>>>>>> custom >>>>>>>>>>>>> ClassLoader... >>>>>>>>>>>>> >>>>>>>>>>>>> To hacky? Dependent on future changes of javac? At least >>>>>>>>>>>>> the "bad >>>>>>>>>>>>> name" >>>>>>>>>>>>> patching could be performed trivially and reliably, I think: >>>>>>>>>>>>> search and >>>>>>>>>>>>> replace with same-length string. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, Peter >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote: >>>>>>>>>>>>>> Ugh. Byte arrays of class file data is really a horrible >>>>>>>>>>>>>> solution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have already filed a task for test development post ZBB to >>>>>>>>>>>>>> develop a >>>>>>>>>>>>>> solution for generating bad class files. I'd prefer to >>>>>>>>>>>>>> file a >>>>>>>>>>>>>> follow-up >>>>>>>>>>>>>> to this to add the bad class file tests when that's done. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>>> I think the right thing to do is to include the original >>>>>>>>>>>>>>> compiling >>>>>>>>>>>>>>> source in a comment, together with a comment on how you >>>>>>>>>>>>>>> modify >>>>>>>>>>>>>>> them, and then the result as a byte array. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our >>>>>>>>>>>>>>> repo. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is no simple means of generating bad class files for >>>>>>>>>>>>>>>> testing. >>>>>>>>>>>>>>>> This is a huge deficiency in our testing abilities. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no >>>>>>>>>>>>>>>> choice >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> to check in no test for this patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, anyone can run the test I've provided with the >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> files and >>>>>>>>>>>>>>>> see that it works. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote: >>>>>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> IIRC we don't check in classfiles into the repo. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files >>>>>>>>>>>>>>>>> in jdk, >>>>>>>>>>>>>>>>> but ASM might be an option, or storing the class file >>>>>>>>>>>>>>>>> as an >>>>>>>>>>>>>>>>> embedded byte array in the test. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>>>> /Joel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which >>>>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>>> validates >>>>>>>>>>>>>>>>>> parameter names correctly. Apologies for the last one. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review this patch, which implements correct >>>>>>>>>>>>>>>>>>> behavior for >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class >>>>>>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The bug report is here: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The webrev is here: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This review is also on crucible. The ID is >>>>>>>>>>>>>>>>>>> CR-JDK8TL-182. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > From huizhe.wang at oracle.com Wed Oct 2 20:43:33 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 02 Oct 2013 13:43:33 -0700 Subject: write to testbase dir [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions Message-ID: <524C8575.6060109@oracle.com> Not sure if this question has been asked before. But is it a general rule that no data should be written to the testbase dir? This test (javax/xml/jaxp/parsers/8022548/XOMParserTest.java) does a transform that writes result to "test.src". From the bug report, it gets an Access is denied error on Windows. Is the fix replacing "test.src" with "test.classes" as Daniel suggested? Thanks, Joe From roger.riggs at oracle.com Wed Oct 2 21:16:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 02 Oct 2013 17:16:52 -0400 Subject: Please Review java.time static interface methods move to supporting class In-Reply-To: <524C6941.9020808@oracle.com> References: <524C4352.1030807@oracle.com> <524C6941.9020808@oracle.com> Message-ID: <524C8D44.7040903@oracle.com> Hi Sherman, Most of the new static factories in util and streams are methods. For example, that return interfaces (like Comparable). I think they are more clearly factories when defined as methods, even if they return a constant value. For consistency, I would retain them as methods and to allow future additions to have parameters even though the current set does not have any with parameters. I would retain "Temporal" on all the interfaces and consider dropping Temporal from the TemporalAdjusters and TemporalQueries classes. Roger On 10/2/2013 2:43 PM, Xueming Shen wrote: > Hi, > > While it might make sense to have method to return the adjuster for > TemporalAdjusters, is there any real benefit to have those parentheses > for TemporalQueries? Maybe it can just be an enum? Or we are considering > adding more parametrized adjusters in the future? Aren't we? > > Now all interfaces and their corresponding utilities are TemporalXYZ, > maybe it is worth considering just to drop the "Temporal"? I know > I may ask too much:-) > > The rest looks fine. > > -Sherman > > > On 10/02/2013 09:01 AM, roger riggs wrote: >> As noted in the issue[1], the static methods in the TemporalAdjuster >> and TemporalQuery >> interfaces that provide implementations of Adjusters and Queries seem >> out of >> place and are better located in a related supporting class so the >> purpose and >> function of the interfaces are not diluted. Adding more methods in >> the future >> will be a better fit in the class. >> >> The static methods of TemporalAdjuster are moved to TemporalAdjusters >> and the static method of TemporalQuery are moved to TemporalQueries. >> Those classes were previously package private and are now public. >> >> Please review and comment: >> >> javadoc: >> http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8025722 >> >> > From mandy.chung at oracle.com Wed Oct 2 22:03:47 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Oct 2013 15:03:47 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity In-Reply-To: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> Message-ID: <524C9843.50704@oracle.com> On 10/1/13 10:19 PM, John Rose wrote: > Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable. > > Here is the respin: > http://cr.openjdk.java.net/~jrose/8025112/webrev.01 Looks good to me. Mandy > > ? John > > On Oct 1, 2013, at 3:15 PM, John Rose wrote: > >> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. >> >> It also adjusts some unit tests. >> >> The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. >> >> The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. >> >> http://cr.openjdk.java.net/~jrose/8025112/webrev.00 >> >> For more background, see my JavaOne presentation: >> http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf >> >> Thanks, >> ? John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From dmitry.samersoff at oracle.com Wed Oct 2 22:18:58 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Oct 2013 02:18:58 +0400 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524C79AA.4090209@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C79AA.4090209@oracle.com> Message-ID: <524C9BD2.4050701@oracle.com> Chris, I'm not sure immediate native retry make sence here because tipically EAGAIN of getaddrinfo caused by network failure, like unreachable nameserver. (see my previous letter) -Dmitry On 2013-10-02 23:53, Chris Hegarty wrote: > On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >> .... >> So, how about this approach: >> >> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >> do one immediate native retry. >> 2) If the retry fails with the same error, then throw a UHE with a >> specific message or cause. > > Sounds good to me. > >> Questions: >> >> A) Would it be better to do the retry in the Java layer, perhaps with >> a very short wait? > > native, without any wait, should be sufficient. > >> B) Should the message or cause in #2 be explicitly document in the >> javadoc? > > I don't think it is necessary for this to be documented. It is more > informational. > > -Chris. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From eric.mccorkle at oracle.com Wed Oct 2 23:14:18 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 02 Oct 2013 23:14:18 +0000 Subject: hg: jdk8/tl/jdk: 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Message-ID: <20131002231431.6950C62CC5@hg.openjdk.java.net> Changeset: cb8946eda85b Author: emc Date: 2013-10-02 19:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb8946eda85b 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Summary: Fix behavior of parameter reflection API for malformed class files. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java + src/share/classes/java/lang/reflect/MalformedParametersException.java ! src/share/classes/java/lang/reflect/Parameter.java + test/java/lang/reflect/Parameter/BadClassFiles.java From henry.jen at oracle.com Wed Oct 2 23:56:27 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 02 Oct 2013 16:56:27 -0700 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524C458D.8070907@gmail.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> <524C2BE4.30602@univ-mlv.fr> <524C458D.8070907@gmail.com> Message-ID: <524CB2AB.305@oracle.com> Hi, Please review update of the webrev at http://cr.openjdk.java.net/~henryjen/ccc/8023524/4/webrev This update address comments from Remi and Peter, - Remove the unnecessary static field, also take out not needed singleton behavior of ProxyClassesDumper - Ensure InvalidPathException won't stop InnerClassLambdaMetaFactory - Change test code to create readonly directory that didn't work properly on Windows. Cheers, Henry From scolebourne at joda.org Thu Oct 3 01:22:10 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 3 Oct 2013 02:22:10 +0100 Subject: Please Review java.time static interface methods move to supporting class In-Reply-To: <524C8D44.7040903@oracle.com> References: <524C4352.1030807@oracle.com> <524C6941.9020808@oracle.com> <524C8D44.7040903@oracle.com> Message-ID: I would agree that methods work best here although we do use constants in other places (such as DTFormatter where it emphasises the immutability) I want to keep the Temporal prefix. Removing it from the static classes does shorten code, but no other pluralized helper class changes the name (eg. Collections, Objects). Stephen On 2 October 2013 22:16, roger riggs wrote: > Hi Sherman, > > Most of the new static factories in util and streams are methods. > For example, that return interfaces (like Comparable). > > I think they are more clearly factories when defined as methods, even if > they return a constant value. > For consistency, I would retain them as methods and to allow future > additions > to have parameters even though the current set does not have any with > parameters. > > I would retain "Temporal" on all the interfaces and consider dropping > Temporal from the TemporalAdjusters and TemporalQueries classes. > > Roger > > > > On 10/2/2013 2:43 PM, Xueming Shen wrote: >> >> Hi, >> >> While it might make sense to have method to return the adjuster for >> TemporalAdjusters, is there any real benefit to have those parentheses >> for TemporalQueries? Maybe it can just be an enum? Or we are considering >> adding more parametrized adjusters in the future? Aren't we? >> >> Now all interfaces and their corresponding utilities are TemporalXYZ, >> maybe it is worth considering just to drop the "Temporal"? I know >> I may ask too much:-) >> >> The rest looks fine. >> >> -Sherman >> >> >> On 10/02/2013 09:01 AM, roger riggs wrote: >>> >>> As noted in the issue[1], the static methods in the TemporalAdjuster and >>> TemporalQuery >>> interfaces that provide implementations of Adjusters and Queries seem out >>> of >>> place and are better located in a related supporting class so the purpose >>> and >>> function of the interfaces are not diluted. Adding more methods in the >>> future >>> will be a better fit in the class. >>> >>> The static methods of TemporalAdjuster are moved to TemporalAdjusters >>> and the static method of TemporalQuery are moved to TemporalQueries. >>> Those classes were previously package private and are now public. >>> >>> Please review and comment: >>> >>> javadoc: >>> http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ >>> >>> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ >>> >>> Thanks, Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8025722 >>> >>> >> > From david.holmes at oracle.com Thu Oct 3 02:06:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Oct 2013 12:06:23 +1000 Subject: [concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524C51B5.3040905@cs.oswego.edu> References: <524C51B5.3040905@cs.oswego.edu> Message-ID: <524CD11F.7070200@oracle.com> On 3/10/2013 3:02 AM, Doug Lea wrote: > On 10/02/2013 12:29 PM, Martin Buchholz wrote: >> FutureTask.cancel(true) invokes thread.interrupt on the thread (if any) >> currently running the task. >> This should succeed even if modifyThread permission is denied by the >> security >> manager. >> > > We haven't interpreted "should" in this way in the past here or in > related contexts, but I don't see are reason not to, pending any > objections by security folks. We have been tightening the conditions under which interrupts can be issued, so relaxing them in this way is simply not acceptable. David ----- > -Doug > > >> Here's a proposed fix for jdk8+: >> >> --- src/main/java/util/concurrent/FutureTask.java15 May 2013 02:39:59 >> -00001.103 >> +++ src/main/java/util/concurrent/FutureTask.java2 Oct 2013 16:25:23 >> -0000 >> @@ -132,6 +132,12 @@ >> return state != NEW; >> } >> + private static void privilegedInterrupt(Thread t) { >> + java.security.PrivilegedAction doInterrupt = >> + () -> { t.interrupt(); return null; }; >> + java.security.AccessController.doPrivileged(doInterrupt); >> + } >> + >> public boolean cancel(boolean mayInterruptIfRunning) { >> if (!(state == NEW && >> UNSAFE.compareAndSwapInt(this, stateOffset, NEW, >> @@ -142,7 +148,11 @@ >> try { >> Thread t = runner; >> if (t != null) >> - t.interrupt(); >> + try { >> + t.interrupt(); >> + } catch (SecurityException e) { >> + privilegedInterrupt(t); >> + } >> } finally { // final state >> UNSAFE.putOrderedInt(this, stateOffset, >> INTERRUPTED); >> } >> >> >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> > From david.holmes at oracle.com Thu Oct 3 02:13:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Oct 2013 12:13:30 +1000 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: <524C4E9B.5080602@gmail.com> Message-ID: <524CD2CA.2070901@oracle.com> On 3/10/2013 2:54 AM, Martin Buchholz wrote: > On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart wrote: > >> Hi Martin, >> >> If you want to optimize for without-security-manager case > > > I want to optimize for the case that Thread.interrupt does not throw > SecurityException How is your proposal optimizing that case ??? David From martinrb at google.com Thu Oct 3 03:55:00 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2013 20:55:00 -0700 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524CD2CA.2070901@oracle.com> References: <524C4E9B.5080602@gmail.com> <524CD2CA.2070901@oracle.com> Message-ID: On Wed, Oct 2, 2013 at 7:13 PM, David Holmes wrote: > On 3/10/2013 2:54 AM, Martin Buchholz wrote: > >> On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart >> wrote: >> >> Hi Martin, >>> >>> If you want to optimize for without-security-manager case >>> >> >> >> I want to optimize for the case that Thread.interrupt does not throw >> SecurityException >> > > How is your proposal optimizing that case ??? Instead of doing extra work to avoid a SecurityException, I am assuming a SecurityException is rare, and risk having to throw it twice. From david.holmes at oracle.com Thu Oct 3 04:03:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Oct 2013 14:03:31 +1000 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: <524C4E9B.5080602@gmail.com> <524CD2CA.2070901@oracle.com> Message-ID: <524CEC93.20106@oracle.com> On 3/10/2013 1:55 PM, Martin Buchholz wrote: > On Wed, Oct 2, 2013 at 7:13 PM, David Holmes wrote: > >> On 3/10/2013 2:54 AM, Martin Buchholz wrote: >> >>> On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart >>> wrote: >>> >>> Hi Martin, >>>> >>>> If you want to optimize for without-security-manager case >>>> >>> >>> >>> I want to optimize for the case that Thread.interrupt does not throw >>> SecurityException >>> >> >> How is your proposal optimizing that case ??? > > > Instead of doing extra work to avoid a SecurityException, I am assuming a > SecurityException is rare, and risk having to throw it twice. Sorry I'm missing something - what extra work are you avoiding and where? The original code just did t.interrupt() now you've added try/catch with a second privileged interrupt attempt. I don't see anything being avoided. Are you referring to caller code that catches the SecurityException itself and somehow retries? David From martinrb at google.com Thu Oct 3 04:11:01 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Oct 2013 21:11:01 -0700 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524CEC93.20106@oracle.com> References: <524C4E9B.5080602@gmail.com> <524CD2CA.2070901@oracle.com> <524CEC93.20106@oracle.com> Message-ID: I was responding to Peter Levart's suggestion of checking for the presence of a security manager before calling doPrivileged. Which is not an important question now, given that the primary question is whether we should allow future.cancel() to interrupt within a doPrivileged. Alternatively, is there a reasonable way for a security manager to enable such usages without enabling arbitrary modifyThread? On Wed, Oct 2, 2013 at 9:03 PM, David Holmes wrote: > On 3/10/2013 1:55 PM, Martin Buchholz wrote: > >> On Wed, Oct 2, 2013 at 7:13 PM, David Holmes ** >> wrote: >> >> On 3/10/2013 2:54 AM, Martin Buchholz wrote: >>> >>> On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart >>>> wrote: >>>> >>>> Hi Martin, >>>> >>>>> >>>>> If you want to optimize for without-security-manager case >>>>> >>>>> >>>> >>>> I want to optimize for the case that Thread.interrupt does not throw >>>> SecurityException >>>> >>>> >>> How is your proposal optimizing that case ??? >>> >> >> >> Instead of doing extra work to avoid a SecurityException, I am assuming a >> SecurityException is rare, and risk having to throw it twice. >> > > Sorry I'm missing something - what extra work are you avoiding and where? > The original code just did t.interrupt() now you've added try/catch with a > second privileged interrupt attempt. I don't see anything being avoided. > Are you referring to caller code that catches the SecurityException itself > and somehow retries? > > David > > From Alan.Bateman at oracle.com Thu Oct 3 04:48:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Oct 2013 21:48:56 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: <524CF738.7090709@oracle.com> On 02/10/2013 12:40, Brian Burkhalter wrote: > : > > 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then > do one immediate native retry. > 2) If the retry fails with the same error, then throw a UHE with a > specific message or cause. > It's very possible the retry will fail the same way but should be harmless (modulo the delay if is a timeout). Having the UHE be thrown with the message from gai_strerror would be must more useful. The reason I suggesting use a cause is because UHE has always been thrown with the host name as the detail message (and very possible that there are dependencies somewhere on this). -Alan. From Alan.Bateman at oracle.com Thu Oct 3 04:56:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Oct 2013 21:56:45 -0700 Subject: RFR 8025567 Mark relevant public stream tests as serialization hostile In-Reply-To: <8749BE22-D1BE-4529-B24F-A362A05E36BF@oracle.com> References: <8749BE22-D1BE-4529-B24F-A362A05E36BF@oracle.com> Message-ID: <524CF90D.5040802@oracle.com> On 01/10/2013 05:10, Paul Sandoz wrote: > Hi, > > This patch marks certain stream tests as serialization hostile. Such tests will ignored by by lambda serialization testing framework: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8025567-test-serialization-hostile/webrev/ > > Paul. > Looks okay to me (I'm serialization hostile too :-) -Alan From david.holmes at oracle.com Thu Oct 3 05:12:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Oct 2013 15:12:43 +1000 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: <524C4E9B.5080602@gmail.com> <524CD2CA.2070901@oracle.com> <524CEC93.20106@oracle.com> Message-ID: <524CFCCB.2060000@oracle.com> On 3/10/2013 2:11 PM, Martin Buchholz wrote: > I was responding to Peter Levart's suggestion of checking for the presence > of a security manager before calling doPrivileged. Which is not an > important question now, given that the primary question is whether we > should allow future.cancel() to interrupt within a doPrivileged. Ah I see. > Alternatively, is there a reasonable way for a security manager to enable > such usages without enabling arbitrary modifyThread? I'm not quite sure what you are asking. Thread permissions are notoriously coarse-grained. I thought that was a big mistake when the security architecture was updated in 1.2 (?) but here we are a decade (or more) later and it seems noone really complained. So be it. Hypothetically we could define finer-grained permissions to differ interrupt from nasty things like stop/suspend. But in practice unless we change how we assign that permission then you would still require it and wouldn't have it unless using a custom security policy - which would allow you to deal with the modifyThread permission too. David ----- > > On Wed, Oct 2, 2013 at 9:03 PM, David Holmes wrote: > >> On 3/10/2013 1:55 PM, Martin Buchholz wrote: >> >>> On Wed, Oct 2, 2013 at 7:13 PM, David Holmes ** >>> wrote: >>> >>> On 3/10/2013 2:54 AM, Martin Buchholz wrote: >>>> >>>> On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart >>>>> wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>>> >>>>>> If you want to optimize for without-security-manager case >>>>>> >>>>>> >>>>> >>>>> I want to optimize for the case that Thread.interrupt does not throw >>>>> SecurityException >>>>> >>>>> >>>> How is your proposal optimizing that case ??? >>>> >>> >>> >>> Instead of doing extra work to avoid a SecurityException, I am assuming a >>> SecurityException is rare, and risk having to throw it twice. >>> >> >> Sorry I'm missing something - what extra work are you avoiding and where? >> The original code just did t.interrupt() now you've added try/catch with a >> second privileged interrupt attempt. I don't see anything being avoided. >> Are you referring to caller code that catches the SecurityException itself >> and somehow retries? >> >> David >> >> From Alan.Bateman at oracle.com Thu Oct 3 05:13:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Oct 2013 22:13:35 -0700 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524C4E90.9030205@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> Message-ID: <524CFCFF.4030805@oracle.com> On 02/10/2013 09:49, Aleksey Shipilev wrote: > On 10/02/2013 08:31 PM, Alan Bateman wrote: >> On 02/10/2013 07:43, Aleksey Shipilev wrote: >>> http://cr.openjdk.java.net/~shade/6857566/webrev.00/ >>> >> I'd like to review, I just don't have time at the moment. > Thanks Alan, we can wait. BTW: Is this important enough to attempt to do this late in 8? I just wonder about a significant change like switching to weak references and whether it would be more sensible to hold it back to do early in 9. -Alan. From Alan.Bateman at oracle.com Thu Oct 3 05:44:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Oct 2013 22:44:39 -0700 Subject: write to testbase dir [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions In-Reply-To: <524C8575.6060109@oracle.com> References: <524C8575.6060109@oracle.com> Message-ID: <524D0447.8000206@oracle.com> On 02/10/2013 13:43, huizhe wang wrote: > Not sure if this question has been asked before. But is it a general > rule that no data should be written to the testbase dir? > > This test (javax/xml/jaxp/parsers/8022548/XOMParserTest.java) does a > transform that writes result to "test.src". From the bug report, it > gets an Access is denied error on Windows. > > Is the fix replacing "test.src" with "test.classes" as Daniel suggested? Right, tests shouldn't be writing to test.src. jtreg runs tests with a working directory where you can create temporary files so you don't have to specify a directory. The temporary file directory is another choice although not always the best choice as you can fill that up easily and also it's not easy to find the files after a test failure. Another useful thing to know is that there are jtreg options to retain the files in the working directory when a test fails. -Alan From peter.levart at gmail.com Thu Oct 3 07:33:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Oct 2013 09:33:29 +0200 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524CB2AB.305@oracle.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> <524C2BE4.30602@univ-mlv.fr> <524C458D.8070907@gmail.com> <524CB2AB.305@oracle.com> Message-ID: <524D1DC9.9070208@gmail.com> Hi Henry, I think you want to revert the order of the following two lines in ProxyClassDumper: 67 isReadyToUse(); 68 dumpDir = tmp; Otherwise looks good now. The following is up to you. Just style nits... If you wanted to be extra user-friendly, you could log all transitions of "valid dir" -> "invalid dir" and vice versa. Like the following: private boolean isReadyToUse() { if (dumpDir == null) { return false; } String errMsg; if (!Files.exists(dumpDir)) { errMsg = "Directory " + dumpDir + " does not exist"; } else if (!Files.isDirectory(dumpDir)) { errMsg = "Path " + dumpDir + " is not a directory"; } else if (!Files.isWritable(dumpDir)) { errMsg = "Directory " + dumpDir + " is not writable"; } else { // show info message about re-validated directory if (invalidDir.getAndSet(false)) { PlatformLogger.getLogger(ProxyClassesDumper.class.getName()) .info("Directory " + dumpDir + " is writable directory now - dumping restored"); } // validated dump directory, ready to go return true; } // show warning message about invalidated directory if (! invalidDir.getAndSet(true)) { PlatformLogger.getLogger(ProxyClassesDumper.class.getName()) .warning(errMsg + " - dumping temporarily disabled"); } return false; } In constructor's exception handler, you could write: PlatformLogger.getLogger(ProxyClassesDumper.class.getName()) .warning("Path " + path + " is not valid - dumping permanently disabled", ex); You don't need .toString() calls for objects that are part of string concatenation expressions. It's done automatically for you. It's even more safe, since it can avoid NPE when any such object is null... Regards, Peter On 10/03/2013 01:56 AM, Henry Jen wrote: > Hi, > > Please review update of the webrev at > http://cr.openjdk.java.net/~henryjen/ccc/8023524/4/webrev > > This update address comments from Remi and Peter, > > - Remove the unnecessary static field, also take out not needed > singleton behavior of ProxyClassesDumper > - Ensure InvalidPathException won't stop InnerClassLambdaMetaFactory > - Change test code to create readonly directory that didn't work > properly on Windows. > > Cheers, > Henry From chris.hegarty at oracle.com Thu Oct 3 09:11:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Oct 2013 10:11:35 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524C9BD2.4050701@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C79AA.4090209@oracle.com> <524C9BD2.4050701@oracle.com> Message-ID: <524D34C7.7070805@oracle.com> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: > Chris, > > I'm not sure immediate native retry make sence here because tipically > EAGAIN of getaddrinfo caused by network failure, like unreachable > nameserver. (see my previous letter) OK, while not ideal ( please don't shoot! ) what do others think of Thread.yield() before retry. It is an attempt to allow other threads on the system do some work before us, therefore potentially swapping out our failed lookup thread until rescheduled. I'm just trying to avoid baking in a hardcoded sleep/wait value ( since we don't know what that should be ). The use of Thread.yield(), if acceptable, would of course most likely make sense to push the retry logic back up into the Java level. -Chris. > > -Dmitry > > On 2013-10-02 23:53, Chris Hegarty wrote: >> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >>> .... >>> So, how about this approach: >>> >>> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >>> do one immediate native retry. >>> 2) If the retry fails with the same error, then throw a UHE with a >>> specific message or cause. >> >> Sounds good to me. >> >>> Questions: >>> >>> A) Would it be better to do the retry in the Java layer, perhaps with >>> a very short wait? >> >> native, without any wait, should be sufficient. >> >>> B) Should the message or cause in #2 be explicitly document in the >>> javadoc? >> >> I don't think it is necessary for this to be documented. It is more >> informational. >> >> -Chris. > > From dmitry.samersoff at oracle.com Thu Oct 3 09:44:52 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Oct 2013 13:44:52 +0400 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524D34C7.7070805@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C79AA.4090209@oracle.com> <524C9BD2.4050701@oracle.com> <524D34C7.7070805@oracle.com> Message-ID: <524D3C94.5060901@oracle.com> Chris, On my opinion, it's better to just return meaningful exception to customer and let them deal with network issue (as current webrev does). Typical network failure requires at least couple of milliseconds to recover so immediate retry most probably fails with the same error. >From the other side - cu has lots of possibility to defend against such failures on application level. E.g. popup a message box "please check your wiring and try again" In a future, it might be possible to add a timeout parameter to corresponding Java-level functions and keep trying on Java level until we get result or timeout, but it requires much more work and probably out of scope of this CR. -Dmitry On 2013-10-03 13:11, Chris Hegarty wrote: > On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: >> Chris, >> >> I'm not sure immediate native retry make sence here because tipically >> EAGAIN of getaddrinfo caused by network failure, like unreachable >> nameserver. (see my previous letter) > > OK, while not ideal ( please don't shoot! ) what do others think of > Thread.yield() before retry. It is an attempt to allow other threads on > the system do some work before us, therefore potentially swapping out > our failed lookup thread until rescheduled. I'm just trying to avoid > baking in a hardcoded sleep/wait value ( since we don't know what that > should be ). > > The use of Thread.yield(), if acceptable, would of course most likely > make sense to push the retry logic back up into the Java level. > > -Chris. > >> >> -Dmitry >> >> On 2013-10-02 23:53, Chris Hegarty wrote: >>> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >>>> .... >>>> So, how about this approach: >>>> >>>> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >>>> do one immediate native retry. >>>> 2) If the retry fails with the same error, then throw a UHE with a >>>> specific message or cause. >>> >>> Sounds good to me. >>> >>>> Questions: >>>> >>>> A) Would it be better to do the retry in the Java layer, perhaps with >>>> a very short wait? >>> >>> native, without any wait, should be sufficient. >>> >>>> B) Should the message or cause in #2 be explicitly document in the >>>> javadoc? >>> >>> I don't think it is necessary for this to be documented. It is more >>> informational. >>> >>> -Chris. >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From chris.hegarty at oracle.com Thu Oct 3 10:10:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Oct 2013 11:10:39 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524D3C94.5060901@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C79AA.4090209@oracle.com> <524C9BD2.4050701@oracle.com> <524D34C7.7070805@oracle.com> <524D3C94.5060901@oracle.com> Message-ID: <524D429F.4070501@oracle.com> Thanks Dmitry, I think we have agreement that the cause of the UHE should contain an Exception containing the gai_strerror string message. I can live without adding retry logic. -Chris. On 10/03/2013 10:44 AM, Dmitry Samersoff wrote: > Chris, > > On my opinion, it's better to just return meaningful exception to > customer and let them deal with network issue (as current webrev does). > > Typical network failure requires at least couple of milliseconds to > recover so immediate retry most probably fails with the same error. > > From the other side - cu has lots of possibility to defend against such > failures on application level. E.g. popup a message box "please check > your wiring and try again" > > In a future, > > it might be possible to add a timeout parameter to corresponding > Java-level functions and keep trying on Java level until we get result > or timeout, but it requires much more work and probably out of scope of > this CR. > > -Dmitry > > > On 2013-10-03 13:11, Chris Hegarty wrote: >> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: >>> Chris, >>> >>> I'm not sure immediate native retry make sence here because tipically >>> EAGAIN of getaddrinfo caused by network failure, like unreachable >>> nameserver. (see my previous letter) >> >> OK, while not ideal ( please don't shoot! ) what do others think of >> Thread.yield() before retry. It is an attempt to allow other threads on >> the system do some work before us, therefore potentially swapping out >> our failed lookup thread until rescheduled. I'm just trying to avoid >> baking in a hardcoded sleep/wait value ( since we don't know what that >> should be ). >> >> The use of Thread.yield(), if acceptable, would of course most likely >> make sense to push the retry logic back up into the Java level. >> >> -Chris. >> >>> >>> -Dmitry >>> >>> On 2013-10-02 23:53, Chris Hegarty wrote: >>>> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >>>>> .... >>>>> So, how about this approach: >>>>> >>>>> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >>>>> do one immediate native retry. >>>>> 2) If the retry fails with the same error, then throw a UHE with a >>>>> specific message or cause. >>>> >>>> Sounds good to me. >>>> >>>>> Questions: >>>>> >>>>> A) Would it be better to do the retry in the Java layer, perhaps with >>>>> a very short wait? >>>> >>>> native, without any wait, should be sufficient. >>>> >>>>> B) Should the message or cause in #2 be explicitly document in the >>>>> javadoc? >>>> >>>> I don't think it is necessary for this to be documented. It is more >>>> informational. >>>> >>>> -Chris. >>> >>> > > From dmitry.samersoff at oracle.com Thu Oct 3 10:11:07 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Oct 2013 14:11:07 +0400 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <524D429F.4070501@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <524C79AA.4090209@oracle.com> <524C9BD2.4050701@oracle.com> <524D34C7.7070805@oracle.com> <524D3C94.5060901@oracle.com> <524D429F.4070501@oracle.com> Message-ID: <524D42BB.4070206@oracle.com> Chris, On 2013-10-03 14:10, Chris Hegarty wrote: > Thanks Dmitry, > > I think we have agreement that the cause of the UHE should contain an > Exception containing the gai_strerror string message. I can live without > adding retry logic. I'm ok with that. -Dmitry > > -Chris. > > On 10/03/2013 10:44 AM, Dmitry Samersoff wrote: >> Chris, >> >> On my opinion, it's better to just return meaningful exception to >> customer and let them deal with network issue (as current webrev does). >> >> Typical network failure requires at least couple of milliseconds to >> recover so immediate retry most probably fails with the same error. >> >> From the other side - cu has lots of possibility to defend against such >> failures on application level. E.g. popup a message box "please check >> your wiring and try again" >> >> In a future, >> >> it might be possible to add a timeout parameter to corresponding >> Java-level functions and keep trying on Java level until we get result >> or timeout, but it requires much more work and probably out of scope of >> this CR. >> >> -Dmitry >> >> >> On 2013-10-03 13:11, Chris Hegarty wrote: >>> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: >>>> Chris, >>>> >>>> I'm not sure immediate native retry make sence here because tipically >>>> EAGAIN of getaddrinfo caused by network failure, like unreachable >>>> nameserver. (see my previous letter) >>> >>> OK, while not ideal ( please don't shoot! ) what do others think of >>> Thread.yield() before retry. It is an attempt to allow other threads on >>> the system do some work before us, therefore potentially swapping out >>> our failed lookup thread until rescheduled. I'm just trying to avoid >>> baking in a hardcoded sleep/wait value ( since we don't know what that >>> should be ). >>> >>> The use of Thread.yield(), if acceptable, would of course most likely >>> make sense to push the retry logic back up into the Java level. >>> >>> -Chris. >>> >>>> >>>> -Dmitry >>>> >>>> On 2013-10-02 23:53, Chris Hegarty wrote: >>>>> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >>>>>> .... >>>>>> So, how about this approach: >>>>>> >>>>>> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >>>>>> do one immediate native retry. >>>>>> 2) If the retry fails with the same error, then throw a UHE with a >>>>>> specific message or cause. >>>>> >>>>> Sounds good to me. >>>>> >>>>>> Questions: >>>>>> >>>>>> A) Would it be better to do the retry in the Java layer, perhaps with >>>>>> a very short wait? >>>>> >>>>> native, without any wait, should be sufficient. >>>>> >>>>>> B) Should the message or cause in #2 be explicitly document in the >>>>>> javadoc? >>>>> >>>>> I don't think it is necessary for this to be documented. It is more >>>>> informational. >>>>> >>>>> -Chris. >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From paul.sandoz at oracle.com Thu Oct 3 10:12:22 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 03 Oct 2013 10:12:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131003101314.93FAA62CE2@hg.openjdk.java.net> Changeset: 811c35a6a58f Author: psandoz Date: 2013-10-02 16:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c35a6a58f 8025534: Unsafe typecast in java.util.stream.Streams.Nodes 8025538: Unsafe typecast in java.util.stream.SpinedBuffer 8025533: Unsafe typecast in java.util.stream.Streams.RangeIntSpliterator.splitPoint() 8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray() Reviewed-by: chegar ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Streams.java Changeset: c55a7941050c Author: psandoz Date: 2013-10-03 10:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a7941050c 8025567: Mark relevant public stream tests as serialization hostile Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java From paul.sandoz at oracle.com Thu Oct 3 10:32:33 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Oct 2013 12:32:33 +0200 Subject: SplittableRandom update In-Reply-To: <524AF245.9040203@oracle.com> References: <523C57A6.2000508@cs.oswego.edu> <524AF245.9040203@oracle.com> Message-ID: <995CCD0B-3D5E-46CF-86A3-66C1BC910D87@oracle.com> On Oct 1, 2013, at 6:03 PM, Joe Darcy wrote: > On 10/1/2013 4:18 AM, Paul Sandoz wrote: >> On Sep 20, 2013, at 5:30 PM, Martin Buchholz wrote: >>> Looks good. >>> >>> Random nitpicks: >>> >>> I prefer the old variable name DOUBLE_UNIT to DOUBLE_ULP; else you are >>> inventing a slightly different meaning for ULP. >>> >>> I think using hex floating point literals is preferred: >>> >>> - private static final double DOUBLE_ULP = 1.0 / (1L << 53); >>> + private static final double DOUBLE_ULP = 0x1.0p-53; >>> >> I don't have any strong preference on the above comments, Doug? > > Please use the hex literals in a case like this; it is exactly the situation they were designed for. > OK. Updated: - to use hex floating point literals for all the random impls (i retained the other way in comments, since devs may not be familiar with this). - reverted DOUBLE_ULP back to DOUBLE_UNIT. http://cr.openjdk.java.net/~psandoz/tl/JDK-8025136-SR-enhancements/webrev/ Paul. From paul.sandoz at oracle.com Thu Oct 3 10:48:57 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Oct 2013 12:48:57 +0200 Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed In-Reply-To: References: <5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu> <5236FDBB.9010209@gmail.com> <523714E2.4010906@oracle.com> <52371807.9080401@gmail.com> <52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com> <52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu> <656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com> <5237929F.7070200@cs.oswego.edu> Message-ID: <66C726B1-7E3E-4326-B450-BDB5D8B51706@oracle.com> [Catching up after J1] On Sep 24, 2013, at 9:16 AM, Martin Buchholz wrote: > Stupid SplittableRandom tricks: > > System.out.println(sr.nextDouble(0.0d, > Double.POSITIVE_INFINITY)); > always prints constant 1.7976931348623157E308 > > which might be considered a bug. > Right, Double.MAX_VALUE. We thought not worth the effort of exhaustively supporting all possible IllegalArgumentException cases: nextDouble(+oo) => Double.MAX_VALUE nextDouble(-oo, finite) => NaN nextDouble(-oo, +oo) => NaN nextDouble(finite, +oo) => Double.MAX_VALUE > --- > > The spec below fails to be pedantically correct when one of the args is NaN. > > * @throws IllegalArgumentException if {@code origin} is greater than > * or equal to {@code bound} > */ > public double nextDouble(double origin, double bound) { > > Better to draw inspiration from the spec for > * @throws IllegalArgumentException if {@code bound} is not positive > */ > public double nextDouble(double bound) { > > and write: > > * @throws IllegalArgumentException if {@code bound - origin} is not > positive > */ > public double nextDouble(double origin, double bound) { > That would be a good change to tack on to that for the better reporting of incorrect bounds. Paul. From paul.sandoz at oracle.com Thu Oct 3 12:32:45 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Oct 2013 14:32:45 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524CFCFF.4030805@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> Message-ID: <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> On Oct 3, 2013, at 7:13 AM, Alan Bateman wrote: > On 02/10/2013 09:49, Aleksey Shipilev wrote: >> On 10/02/2013 08:31 PM, Alan Bateman wrote: >>> On 02/10/2013 07:43, Aleksey Shipilev wrote: >>>> http://cr.openjdk.java.net/~shade/6857566/webrev.00/ >>>> >>> I'd like to review, I just don't have time at the moment. >> Thanks Alan, we can wait. > BTW: Is this important enough to attempt to do this late in 8? I just wonder about a significant change like switching to weak references and whether it would be more sensible to hold it back to do early in 9. > It appears that cleaner is used (within the JDK) exclusively for nio native/direct buffers although an intention was for a more light weight mechanism to that of finalization. grepcode.com reports only one external use: http://grepcode.com/search/usages?id=repository.grepcode.com$java$root at jdk$openjdk at 7-b147@sun$misc at Cleaner&start=0&type=type&k=u Given the minimal usage perhaps the risk of moving from phantom to weak refs is reduced. Maybe Cleaner could be repurposed and moved to the nio area? Alexsey, what do you observe if you revert back Cleaner to a PhantomReference and retain QUEUE/CLEANERS but not assistCleanupSlow? Paul From david.lloyd at redhat.com Thu Oct 3 12:39:38 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 03 Oct 2013 07:39:38 -0500 Subject: FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: <524CFCCB.2060000@oracle.com> References: <524C4E9B.5080602@gmail.com> <524CD2CA.2070901@oracle.com> <524CEC93.20106@oracle.com> <524CFCCB.2060000@oracle.com> Message-ID: <524D658A.8090305@redhat.com> On 10/03/2013 12:12 AM, David Holmes wrote: > On 3/10/2013 2:11 PM, Martin Buchholz wrote: >> I was responding to Peter Levart's suggestion of checking for the >> presence >> of a security manager before calling doPrivileged. Which is not an >> important question now, given that the primary question is whether we >> should allow future.cancel() to interrupt within a doPrivileged. > > Ah I see. > >> Alternatively, is there a reasonable way for a security manager to enable >> such usages without enabling arbitrary modifyThread? > > I'm not quite sure what you are asking. Thread permissions are > notoriously coarse-grained. I thought that was a big mistake when the > security architecture was updated in 1.2 (?) but here we are a decade > (or more) later and it seems noone really complained. So be it. > > Hypothetically we could define finer-grained permissions to differ > interrupt from nasty things like stop/suspend. But in practice unless we > change how we assign that permission then you would still require it and > wouldn't have it unless using a custom security policy - which would > allow you to deal with the modifyThread permission too. Permissions can imply other Permissions. Any RuntimePermission whose action is "modifyThread" could be (in code) modified to imply a host of finer-grained ThreadPermission or something like that. -- - DML From aleksey.shipilev at oracle.com Thu Oct 3 12:40:47 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 03 Oct 2013 16:40:47 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> Message-ID: <524D65CF.3010209@oracle.com> On 10/03/2013 04:32 PM, Paul Sandoz wrote: > Alexsey, what do you observe if you revert back Cleaner to a > PhantomReference and retain QUEUE/CLEANERS but not > assistCleanupSlow? I observed the minuscule probability (my estimate is <0.1%) we hit the OOME with the original test. This is literally the very aggressive fallback strategy. -Aleksey. From dmitry.samersoff at oracle.com Thu Oct 3 12:55:27 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 03 Oct 2013 12:55:27 +0000 Subject: hg: jdk8/tl/jdk: 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Message-ID: <20131003125539.805AB62CEC@hg.openjdk.java.net> Changeset: 5d6dc0cba08f Author: dsamersoff Date: 2013-10-03 16:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d6dc0cba08f 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh From peter.levart at gmail.com Thu Oct 3 13:14:17 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 03 Oct 2013 15:14:17 +0200 Subject: [concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged In-Reply-To: References: <524C51B5.3040905@cs.oswego.edu> <524C7181.3060802@oracle.com> Message-ID: <524D6DA9.2050407@gmail.com> On 10/02/2013 09:31 PM, Martin Buchholz wrote: >> >Objection. I can straightaway see a way of getting an instance of a JDK-8 >> >FutureTask with a runner that is not current running the FutureTask.run, >> >without so much as needing a race. That would allow an adversary to to >> >interrupt a thread in contravention of the security policy. > Interesting - FutureTask is designed to not make that possible - runner is > not exposed, and is supposed to be set only while executing the task. Do > we have a bug? Yes, the "bug" is in java.lang.Thread. Its inherent to the API for interrupt status handling. Thread has only one bit of information for interrupt status and one can not know whether the Thread.isInterrupted() == true is originating from Future.cancel(true) or some other legal interaction between the interrupted thread and some other interrupting thread. So FutureTask chooses not to clear the eventual interrupted status of the thread before it exits the run() method although it might have been interrupted by Future.cancel(true): /** * Ensures that any interrupt from a possible cancel(true) is only * delivered to a task while in run or runAndReset. */ private void handlePossibleCancellationInterrupt(int s) { // It is possible for our interrupter to stall before getting a // chance to interrupt us. Let's spin-wait patiently. if (s == INTERRUPTING) while (state == INTERRUPTING) Thread.yield(); // wait out pending interrupt // assert state == INTERRUPTED; // We want to clear any interrupt we may have received from // cancel(true). However, it is permissible to use interrupts // as an independent mechanism for a task to communicate with // its caller, and there is no way to clear only the // cancellation interrupt. // // Thread.interrupted(); } So the thread might be left in interrupted state after the task has finished it's run() method. But I don't think it's possible to interrupt some thread via FutureTask.cancel(true) unless that thread has "recently" been executing the task's run() method. Regards, Peter From alexander.zuev at oracle.com Thu Oct 3 13:41:00 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Thu, 03 Oct 2013 13:41:00 +0000 Subject: hg: jdk8/tl/jdk: 8025738: locale related test fails on langtools mac 10.7 test host Message-ID: <20131003134121.D9BFE62CEE@hg.openjdk.java.net> Changeset: 9c32a9490eac Author: kizune Date: 2013-10-03 17:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c32a9490eac 8025738: locale related test fails on langtools mac 10.7 test host Reviewed-by: ksrini ! test/tools/launcher/DiacriticTest.java From daniel.fuchs at oracle.com Thu Oct 3 14:47:52 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 03 Oct 2013 16:47:52 +0200 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <52449684.2080609@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> Message-ID: <524D8398.4000005@oracle.com> Hi Mandy, Thanks for your comments! On 9/26/13 10:18 PM, Mandy Chung wrote: > Hi Daniel, > > This is a good solution for Logger subclasses or existing apps that rely > on the previous stack walk search to lookup a resource bundle.I have > some comments on the specification: > > Logger.setResourceBundle(ResourceBundle rb) > Should this method simply throw NPE if rb == null since we can't > reset a non-null rb/rbname to null? Excellent suggestion. > > Some suggestion to the javadoc: > > > * Sets the resource bundle for this logger to use for localization. > * > * @param bundle The resource bundle that this logger shall use. > * @throws IllegalArgumentException if the given bundle doesn't have a > * {@linkplain ResourceBundle#getBaseBundleName base name}, > * or if this logger already has a resource bundle set but > * the given bundle has a different base name. > Done. > The getLogger(String name, String rbname) spec and the class specification > should be updated about different ways in setting a resource bundle for > a logger. > > For example in the class spec, this paragraph and text following it talks > about resource bundle and name and also logrb method: > > Each Logger may have a ResourceBundle name associated with it. > The named bundle will be used for localizing logging messages. > If a Logger does not have its own ResourceBundle name, then > it will inherit the ResourceBundle name from its parent, > recursively up the tree. > > Adding @see #setResourceBundle in the getLogger method would be helpful. I have reworked the part of the class specification that talks about ResourceBundles and ResourceBundle names. > It'd be good to clarify the spec of getResourceBundle and > getResourceBundleName > methods that they return the ResourceBundle and its base name if set via > setResourceBundle method. Perhaps it might be good for the class spec > to capture different ways to set the resource bundle and and have the > methods > to refer that specification. I have updated the documentation of these two methods - and it should be more clear now. > > The current implementation of the getLogger(String name, String rbname) > method > uses the caller's class loader to look up the resource bundle. Do you mind > taking this opportunity to update the spec to match the current > implementation? > This fix is a follow-up on that change. OK - I have updated the paragraph that explains how bundle names are mapped to ResourceBundle objects in the class description. Since the mapping - if required - happens at logging time - I think it's better to leave it at the class level. > Maybe we should just use varargs (JDK-5001993) to replace the two > logrb methods one taking a single parameter and the other taking an > array of parameters: > public void logrb(Level level, String sourceClass, String > sourceMethod, > ResourceBundle bundle, String msg, Object... params) > Done. > I can live with the inconsistency. > > ResourceBundle.getBaseBundleName - this is more a question to Naoto. > > The implementation note about this method may return a pathname > but the spec states that it returns a fully qualified class name > is a bit strange. Can you elaborate what problem we have here? > I am missing the context to connect how this is related to the > older versions of JRE I have simplified this part with Naoto's help. The new webrev is here: http://cr.openjdk.java.net/~dfuchs/webrev_8013839/webrev.07/ Thanks a lot for all the good feedbacks! -- daniel > > thanks > Mandy > > > On 9/20/2013 5:33 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a patch for: >> >> 8013839: Enhance Logger API for handling of resource bundles, and >> 4814565: (rb) add method to get basename from a ResourceBundle >> >> >> >> 1. It adds a ResourceBundle.getBaseBundleName() method, >> 2. It adds a Logger.setResourceBundle(ResourceBundle) method, >> 3. It adds a series of Logger.logrb(...) that take a ResourceBundle >> object instead of a ResourceBundle name. >> The previous versions of Logger.logrb(...) that took a >> resource bundle name are therefore no longer needed, >> they offer no added value above the new methods, and >> are thus now deprecated. >> >> Logger.getLogger(name, rbname) will continue to work as before, >> and will also throw an exception if a RB with a different name >> has been set before, either through setResourceBundle or >> Logger.getLogger(name, rbname). >> >> Logger.setResourceBundle works similarly to >> Logger.getLogger(name, rbname) in the sense that it will not >> allow to replace an existing bundle, unless both have the same >> name. Like for Logger.getLogger(name, rbname) - it doesn't matter >> by which method the previous bundle has been set. >> >> This is mostly for consistency of the API - if thread A has >> requested a logger with resource bundle name 'foo.Bundle' >> and thread B attempts to set the resource bundle of that >> logger to 'bar.Bundle' then thread B will get an IAE. >> >> The resource bundle passed to Logger.setResourceBundle *must* >> have a base name. Note that ResourceBundle objects will have >> a base name by default if they have been loaded through >> one of the ResourceBundle.getBundle(...) methods; >> If ResourceBundle.getBaseBundleName() returns null an IAE >> will be thrown. >> >> Logger.setResourceBundle requires the "control" permission. >> >> When a resource bundle is set with Logger.setResourceBundle, >> then it's that resource bundle locale that will be used >> when logging (and not the default locale). >> >> I have written a set of unit tests which should cover all the points >> listed above. >> >> best regards, >> >> -- daniel > From mandy.chung at oracle.com Thu Oct 3 15:32:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Oct 2013 08:32:26 -0700 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <524D8398.4000005@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> <524D8398.4000005@oracle.com> Message-ID: <524D8E0A.30404@oracle.com> Hi Daniel, On 10/3/2013 7:47 AM, Daniel Fuchs wrote: > > The new webrev is here: > http://cr.openjdk.java.net/~dfuchs/webrev_8013839/webrev.07/ Looks good. Thanks for improving the javadoc. line 1264 formatting nits - there are extra spaces that can be removed. 1892 * @throws NullPointerException if the given bundle is {@code null}. This is already captured in the package summary. No need to specify this @throws NPE. setResourceBundle(bundle) forgets to check NPE (it should call Objects.requireNonNull(bundle). I think it should move line 1913-1915 to the beginning after NPE check. I think canReplaceResourceBundle method body is simple that inlining in line 1908 would be cleaner and still readable. Mandy From daniel.fuchs at oracle.com Thu Oct 3 15:56:43 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 03 Oct 2013 17:56:43 +0200 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <524D8E0A.30404@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> <524D8398.4000005@oracle.com> <524D8E0A.30404@oracle.com> Message-ID: <524D93BB.20501@oracle.com> On 10/3/13 5:32 PM, Mandy Chung wrote: > Hi Daniel, > > On 10/3/2013 7:47 AM, Daniel Fuchs wrote: >> >> The new webrev is here: >> http://cr.openjdk.java.net/~dfuchs/webrev_8013839/webrev.07/ > > Looks good. Thanks for improving the javadoc. > > line 1264 formatting nits - there are extra spaces that can be removed. Right. Thanks for spotting that. > 1892 * @throws NullPointerException if the given bundle is {@code > null}. > > This is already captured in the package summary. No need to specify this > @throws NPE. Other methods (like getLogger) have @throws NPE in their javadoc. > setResourceBundle(bundle) forgets to check NPE (it should call > Objects.requireNonNull(bundle). Line 1903 has this effect. I will add a comment to make it clear that the NPE is intended. > I think it should move line 1913-1915 > to the beginning after NPE check. I think canReplaceResourceBundle > method body is simple that inlining in line 1908 would be cleaner and > still readable. Right - done. new webrev: -- daniel > > Mandy From xueming.shen at oracle.com Thu Oct 3 17:11:11 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 03 Oct 2013 10:11:11 -0700 Subject: Review java.time test refactoring In-Reply-To: <524B1A3B.8000203@oracle.com> References: <523A1BCF.3030001@oracle.com> <524B1A3B.8000203@oracle.com> Message-ID: <524DA52F.3000608@oracle.com> Looks fine. -Sherman On 10/01/2013 11:53 AM, roger riggs wrote: > Ping, needs a Reviewer. > > http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/ > > Updated the webrev with the renamed test classes to distinguish them from the > non-serialization tests in a different package. > > Thanks, Roger > > On 9/23/2013 11:04 AM, Stephen Colebourne wrote: >> The change looks fine AFAICT. I would prefer to see the new serial >> package test classes have names that end in "Serialization", eg >> "TCKLocalDateSerialization", but if that does not happen it is not the >> end of the world. >> Stephen >> >> >> On 18 September 2013 22:31, roger riggs wrote: >>> A review of the TCK tests for java.time resulted in a number of changes >>> including refactoring the serialization tests into subpackages to follow JCK >>> conventions, >>> discovery that a number of tests were missing for serialization, and cleanup >>> of the test code to utilize common test functions for testing serialization. >>> Thanks to the JCK folks for identifying the issues and doing some of the >>> refactoring. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/ >>> >>> * JDK-8024896 >>> Refactor java.time serialization tests into separate subpackage >>> >>> * JDK-8024427 >>> Missing java.time.chrono serialization tests >>> >>> Thanks, Roger >>> > From robert.field at oracle.com Thu Oct 3 17:24:42 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 03 Oct 2013 17:24:42 +0000 Subject: hg: jdk8/tl/jdk: 8010433: Remove lambda metafactory work-around to JDK-8005119 Message-ID: <20131003172512.E48F462D0B@hg.openjdk.java.net> Changeset: 8d8b809dd294 Author: rfield Date: 2013-10-03 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d8b809dd294 8010433: Remove lambda metafactory work-around to JDK-8005119 Summary: Restore invokespecial to lambda metafactory Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java From coleen.phillimore at oracle.com Thu Oct 3 18:02:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Oct 2013 14:02:45 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Message-ID: <524DB145.5030109@oracle.com> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ bug link https://bugs.openjdk.java.net/browse/JDK-8025238 test case for jdk8 repository: open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk Thanks, Coleen From robert.field at oracle.com Thu Oct 3 18:27:36 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 03 Oct 2013 18:27:36 +0000 Subject: hg: jdk8/tl/jdk: 8020849: jdk/lambda/vm/DefaultMethodsTest.java Message-ID: <20131003182839.8556662D1C@hg.openjdk.java.net> Changeset: 1b3616c4a836 Author: rfield Date: 2013-10-03 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b3616c4a836 8020849: jdk/lambda/vm/DefaultMethodsTest.java Summary: Bridge generation has been removed from the VM. Fix is to remove tests that no longer make sense. Reviewed-by: ksrini ! test/jdk/lambda/vm/DefaultMethodsTest.java From xueming.shen at oracle.com Thu Oct 3 18:38:44 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 03 Oct 2013 11:38:44 -0700 Subject: Review Request for project Threeten updates In-Reply-To: <524B13E1.4090202@oracle.com> References: <524B13E1.4090202@oracle.com> Message-ID: <524DB9B4.8080400@oracle.com> (1) until(Temporal endExclusive, TEmporalUnit unit) -> Shouldn't we invoke requireNonNull() for unit before invoking unit.between(...)? (2) It appears we started to use "endExclusive" in "until() methods, while the param has been renamed to be "exclusive" explicitly, personally I prefer still keep the word "exclusive" in its spec, or at least we want to be consistent, for example LocalDate.until(ChronoLocalDate) still keeps the "exclusive" after renaming. (3) We have the erquireNonNull check pattern below in most places if (X instanceof Y) { ... } Objects.requireNonNull(X, "x"); but the plus/minus(TemporalAmount amountToSubtract) appears to be Objects.requireNonoNull(...) if (X instanceof ...) {...} (4) spec and impl of the until(end, unit) has been updated regarding passing the "converted" input temporal as the second argument for unit.between(...) If the unit is not a {@code ChronoUnit}, then the result of this method is obtained by invoking {@code TemporalUnit.between(Temporal, Temporal)} passing {@code this} as the first argument and the converted input temporal as the second argument. I do see the TemporalUnit.between() has wording regarding the first and second must be the same "type/class", otherwise, it will send the ball back to Temporal, then we might end up with a loop. My guess these new wording is to prevent a possible implementation deadlock? But it appears the super Temporal/ChronoLocalXYZ interfaces still claim the "input temporal as the second argument", though it also insists that "Note that the unit's {@code between} method must only be invoked if two temporal objects have exactly the same type evaluated by {@code getClass()}." and the sample shows it indeed passes the converted one. just a small typo here? (The ChronoLocalXYZImpl.until(end, unit) probably needs to update the api doc to explicitly describe this change as well, instead of "@Override", if the wording in Temporal/ChronoLocalXYz is indeed by design?) -Sherman On 10/01/2013 11:26 AM, roger riggs wrote: > Please review these changes from the Threeten project for integration into jdk-tl. > > http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/ > > 8023762: Add ChronoPeriod interface and bind period to Chronology > Summary: Make Period ISO-only, adding a Chronology-specific period concept > Contributed-by: scolebourne at joda.org > > 8023763: Rename ChronoDateImpl > Summary: Rename ChronoDateImpl to ChronoLocalDateImpl > Contributed-by: scolebourne at joda.org > > 8023764: Optimize Period addition > Summary: Optimise plus/minus for common cases > Contributed-by: scolebourne at joda.org > > 8024835: Change until() to accept any compatible temporal > Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary > Contributed-by: scolebourne at joda.org > > 8024807: Add getChronlogy() to CLDT/CZDT > Summary: Alternative to method is clunky and hard to find > Contributed-by: scolebourne at joda.org > > 8024834: Better return type for TemporalField resolve > Summary: Allow resolve method to return more than just ChronoLocalDate > Contributed-by: scolebourne at joda.org > > 8024999: Instant.Parse typo in example > Summary: javadoc only fix to correct example to use "." and "Z" > > Thanks, Roger > > > > From henry.jen at oracle.com Thu Oct 3 18:37:40 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 03 Oct 2013 11:37:40 -0700 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <524D1DC9.9070208@gmail.com> References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com> <523A307E.6080202@oracle.com> <523AA764.60301@redhat.com> <52420B31.2070703@oracle.com> <524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com> <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com> <524B54E4.9010506@oracle.com> <524B60B7.1060905@univ-mlv.fr> <518EFBE7-909E-42D9-B7BD-CF3CBDB408EE@oracle.com> <524BF320.8070807@univ-mlv.fr> <524C29EB.8010108@gmail.com> <524C2BE4.30602@univ-mlv.fr> <524C458D.8070907@gmail.com> <524CB2AB.305@oracle.com> <524D1DC9.9070208@gmail.com> Message-ID: <524DB974.9040805@oracle.com> OK, hopefully we are close to the end here on comments, unless there are security related issues. We still need +1 from a jdk8 "reviewer", http://cr.openjdk.java.net/~henryjen/ccc/8023524/5/webrev This update include what Peter's latest suggestion, and since we don't have a reliable way to create read-only directory on Windows, we simply skip the test on non-posix filesystems, that is, Windows. Cheers, Henry From mandy.chung at oracle.com Thu Oct 3 19:29:07 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Oct 2013 12:29:07 -0700 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <524D93BB.20501@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> <524D8398.4000005@oracle.com> <524D8E0A.30404@oracle.com> <524D93BB.20501@oracle.com> Message-ID: <524DC583.8060104@oracle.com> On 10/3/2013 8:56 AM, Daniel Fuchs wrote: > > Other methods (like getLogger) have @throws NPE in their javadoc. True and I guess the NPE statement in the package summary was added afterwards. I could see that it was meant to clean up the existing javadoc some days (something for the future if you wish). > >> setResourceBundle(bundle) forgets to check NPE (it should call >> Objects.requireNonNull(bundle). > > Line 1903 has this effect. I will add a comment to make it clear > that the NPE is intended. Okay. > new webrev: > test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java 109 return new Vector(java.util.Arrays.asList( 110 new String[] {"dummy"})).elements(); Could you use Collections.enumeration? test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java 194 if (foobaz.getResourceBundleName() != null) { 195 throw new RuntimeException("Unexpected bundle: " 196 + foobar.getResourceBundle()); 197 } I guess you meant to print foobar.getResourceBundleName() in line 196. The test cases are good. It'd be good to add some comments to describe what each case verifies when appropriate. You can make these changes before you push. No need for a new webrev. thanks Mandy From staffan.larsen at oracle.com Thu Oct 3 19:29:53 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Oct 2013 21:29:53 +0200 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: Looks good! (Obviously I would think so for the testcase :-) ) Thanks for fixing, /Staffan On 3 okt 2013, at 20:02, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by method_idnum so handle null. > > This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From serguei.spitsyn at oracle.com Thu Oct 3 19:50:58 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 03 Oct 2013 12:50:58 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DCAA2.7050305@oracle.com> Coleen, The fix looks good. It is nice you've come up with this. Thanks, Serguei On 10/3/13 11:02 AM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From daniel.daugherty at oracle.com Thu Oct 3 20:07:25 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 14:07:25 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DCE7D.7020703@oracle.com> > http://cr.openjdk.java.net/~coleenp/8025238/ src/share/vm/classfile/javaClasses.cpp 1804 if (method == NULL) { 1805 // leave name and fileName null 1806 java_lang_StackTraceElement::set_lineNumber(element(), -1); Is it possible to set the name and fileName to something? A caller may not be expecting those to be NULL. Also, holder->method_with_idnum(method_id) should be able to search the previous class version list and find the obsolete Method* that matches the 'method_id' value. src/share/vm/prims/jvmtiRedefineClasses.cpp Better comment than the original. Dan On 10/3/13 12:02 PM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From roger.riggs at oracle.com Thu Oct 3 20:20:21 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 03 Oct 2013 20:20:21 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131003202235.747C262D32@hg.openjdk.java.net> Changeset: 01b8604e8268 Author: rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contributed-by: paul.rank at oracle.com ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/serial/TCKDuration.java + test/java/time/tck/java/time/serial/TCKInstant.java + test/java/time/tck/java/time/serial/TCKLocalDate.java + test/java/time/tck/java/time/serial/TCKLocalDateTime.java + test/java/time/tck/java/time/serial/TCKLocalTime.java + test/java/time/tck/java/time/serial/TCKMonthDay.java + test/java/time/tck/java/time/serial/TCKOffsetDateTime.java + test/java/time/tck/java/time/serial/TCKOffsetTime.java + test/java/time/tck/java/time/serial/TCKPeriod.java + test/java/time/tck/java/time/serial/TCKYear.java + test/java/time/tck/java/time/serial/TCKYearMonth.java + test/java/time/tck/java/time/serial/TCKZoneId.java + test/java/time/tck/java/time/serial/TCKZoneOffset.java + test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/serial/TCKZoneRules.java Changeset: e813b58bd6db Author: rriggs Date: 2013-10-03 15:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e813b58bd6db 8024427: Missing java.time.chrono serialization tests Summary: Add tests and cleanup existing serialization tests Reviewed-by: sherman ! src/share/classes/java/time/temporal/ValueRange.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java + test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java + test/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java < test/java/time/tck/java/time/serial/TCKDuration.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java < test/java/time/tck/java/time/serial/TCKInstant.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDate.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDateTime.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalTime.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java < test/java/time/tck/java/time/serial/TCKMonthDay.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetDateTime.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetTime.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java < test/java/time/tck/java/time/serial/TCKPeriod.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java < test/java/time/tck/java/time/serial/TCKYearMonth.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java < test/java/time/tck/java/time/serial/TCKYear.java ! test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java < test/java/time/tck/java/time/serial/TCKZoneId.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java < test/java/time/tck/java/time/serial/TCKZoneOffset.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.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/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneRules.java ! test/java/time/test/java/time/AbstractTest.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java From daniel.daugherty at oracle.com Thu Oct 3 20:28:56 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 14:28:56 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DD388.8060706@oracle.com> > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk test/java/lang/instrument/RedefineMethodInBacktrace.sh No comments. test/java/lang/instrument/RedefineMethodInBacktraceApp.java line 78: t.setDaemon(true); Why make the target thread a daemon? Wouldn't it be a more complete test to do Thread.join() of that thread just to be sure that the target thread has finished (and is not stuck)? test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java Nice sync logic with the test driver. Thumbs up. Dan On 10/3/13 12:02 PM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen > > From roger.riggs at oracle.com Thu Oct 3 21:03:21 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 03 Oct 2013 17:03:21 -0400 Subject: Review Request for project Threeten updates In-Reply-To: <524DB9B4.8080400@oracle.com> References: <524B13E1.4090202@oracle.com> <524DB9B4.8080400@oracle.com> Message-ID: <524DDB99.7000703@oracle.com> Hi Sherman, On 10/3/2013 2:38 PM, Xueming Shen wrote: > > (1) until(Temporal endExclusive, TEmporalUnit unit) > -> Shouldn't we invoke requireNonNull() for unit before invoking > unit.between(...)? There is no doubt that invoking unit.between() will cause an NPE if unit is null. Adding requireNonNull will only improve the error message and add bulk to the code. > > (2) It appears we started to use "endExclusive" in "until() methods, > while the param > has been renamed to be "exclusive" explicitly, personally I > prefer still keep the > word "exclusive" in its spec, or at least we want to be > consistent, for example > LocalDate.until(ChronoLocalDate) still keeps the "exclusive" > after renaming. The wording of the @param tags were not changed. We could add ", exclusive, " to the @param tags. > > (3) We have the requireNonNull check pattern below in most places > if (X instanceof Y) { ... } > Objects.requireNonNull(X, "x"); Isn't that just useless, instanceof only returns true for non-null argument. > > but the plus/minus(TemporalAmount amountToSubtract) appears to be > > Objects.requireNonNull(...) > if (X instanceof ...) {...} This form would identify the null as coming from the parameter but the null check would be performed twice (unless HS optimized) > > (4) spec and impl of the until(end, unit) has been updated regarding > passing the > "converted" input temporal as the second argument for > unit.between(...) > > If the unit is not a {@code ChronoUnit}, then the result of this > method > is obtained by invoking {@code TemporalUnit.between(Temporal, > Temporal)} > passing {@code this} as the first argument and the converted input > temporal > as the second argument. > I do see the TemporalUnit.between() has wording regarding the > first and second must be > the same "type/class", otherwise, it will send the ball back to > Temporal, then we might > end up with a loop. My guess these new wording is to prevent a > possible implementation > deadlock? But it appears the super Temporal/ChronoLocalXYZ > interfaces still claim > the "input temporal as the second argument", though it also > insists that That's an oversight and is inconsistent with the behavior defined by the pseudocode. It should say "converted input temporal" as it does in other places. Both Temporal.until and ChronoLocalDate.until(Temporal...) should be corrected. > > "Note that the unit's {@code between} method must only be invoked > if two temporal > objects have exactly the same type evaluated by {@code getClass()}." > > and the sample shows it indeed passes the converted one. just a > small typo here? yes > > (The ChronoLocalXYZImpl.until(end, unit) probably needs to update > the api > doc to explicitly describe this change as well, instead of > "@Override", if the wording > in Temporal/ChronoLocalXYz is indeed by design?) When corrected, it should apply equally to ChronoXXXX. Thanks, Roger > > -Sherman > > On 10/01/2013 11:26 AM, roger riggs wrote: >> Please review these changes from the Threeten project for integration >> into jdk-tl. >> >> http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/ >> >> >> 8023762: Add ChronoPeriod interface and bind period to Chronology >> Summary: Make Period ISO-only, adding a Chronology-specific period >> concept >> Contributed-by: scolebourne at joda.org >> >> 8023763: Rename ChronoDateImpl >> Summary: Rename ChronoDateImpl to ChronoLocalDateImpl >> Contributed-by: scolebourne at joda.org >> >> 8023764: Optimize Period addition >> Summary: Optimise plus/minus for common cases >> Contributed-by: scolebourne at joda.org >> >> 8024835: Change until() to accept any compatible temporal >> Summary: Method until(Temporal,TemporalUnit) now uses from() to >> convert; Enhance from() methods where necessary >> Contributed-by: scolebourne at joda.org >> >> 8024807: Add getChronlogy() to CLDT/CZDT >> Summary: Alternative to method is clunky and hard to find >> Contributed-by: scolebourne at joda.org >> >> 8024834: Better return type for TemporalField resolve >> Summary: Allow resolve method to return more than just ChronoLocalDate >> Contributed-by: scolebourne at joda.org >> >> 8024999: Instant.Parse typo in example >> Summary: javadoc only fix to correct example to use "." and "Z" >> >> Thanks, Roger >> >> >> >> > From christian.thalinger at oracle.com Thu Oct 3 21:57:43 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 14:57:43 -0700 Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members In-Reply-To: References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com> <239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com> <523C69EA.3030107@oracle.com> <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com> Message-ID: <1B49E2DD-D109-46B5-B225-856E37177285@oracle.com> Looks good. On Oct 2, 2013, at 12:33 PM, John Rose wrote: > Push-button webrev generator to the rescue: > http://cr.openjdk.java.net/~jrose/8024599/webrev.01 > > ? John > > On Oct 2, 2013, at 11:23 AM, Christian Thalinger wrote: > >> Since there is no new webrev I assume you incorporated all the stuff below. If that's the case then it looks good. >> >> On Sep 20, 2013, at 6:18 PM, John Rose wrote: >> >>> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov wrote: >>> >>>> John, >>>> >>>> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it. >>> >>> OK. I think I had it in mainly to make sure the unit tests did something interesting. >> >>> >>>> Regarding the test: >>>> 31 * @run main/othervm/timeout=3600 >>>> - why do you have timeout set to 1h? >>> >>> Copy-and-paste from some other test. Removed. >>> >>>> I like the idea how you count events. >>>> >>>> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized. >>> >>> Good idea. But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types. I did the following, for each of the six test cases: >>> >>> @@ -150,9 +150,11 @@ >>> } >>> >>> private static int runFoo() throws Throwable { >>> + assertEquals(Init1Tick, 0); // Init1 not initialized yet >>> int t1 = tick("runFoo"); >>> int t2 = (int) INDY_foo().invokeExact(); >>> int t3 = tick("runFoo done"); >>> + assertEquals(Init1Tick, t2); // when Init1 was initialized >>> assertEquals(t1+2, t3); // exactly two ticks in between >>> assertEquals(t1+1, t2); // init happened inside >>> return t2; >> >>> >>> >>> ? John >>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 9/20/13 1:38 AM, John Rose wrote: >>>>> On Sep 12, 2013, at 7:24 PM, John Rose >>>> > wrote: >>>>> >>>>>> Please review this change for a change to the JSR 292 implementation: >>>>>> >>>>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/ >>>>>> >>>>>> Summary: Align MH semantic with bytecode behavior of constructor and >>>>>> static member accesses, regarding invocation. >>>>>> >>>>>> The change is to javadoc and unit tests, documenting and testing some >>>>>> corner cases of JSR 292 APIs. >>>>> >>>>> I have a reviewer (Alex Buckley) for the documentation changes, but I >>>>> would also like a quick code review for the unit test. >>>>> >>>>> Also, there is a code insertion (predicated on a "false" symbolic >>>>> constant) which serves to document the buggy JDK 7 behavior. I'm not >>>>> particularly attached to it, so I'm open to either a yea or nay on >>>>> keeping it. Leaning nay at the moment. >>>>> >>>>> ? John >>>>> >>>>> >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From xueming.shen at oracle.com Thu Oct 3 22:08:06 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 03 Oct 2013 15:08:06 -0700 Subject: Review Request for project Threeten updates In-Reply-To: <524DDB99.7000703@oracle.com> References: <524B13E1.4090202@oracle.com> <524DB9B4.8080400@oracle.com> <524DDB99.7000703@oracle.com> Message-ID: <524DEAC6.60906@oracle.com> On 10/03/2013 02:03 PM, roger riggs wrote: > Hi Sherman, > > On 10/3/2013 2:38 PM, Xueming Shen wrote: >> >> (1) until(Temporal endExclusive, TEmporalUnit unit) >> -> Shouldn't we invoke requireNonNull() for unit before invoking unit.between(...)? > There is no doubt that invoking unit.between() will cause an NPE if unit is null. > Adding requireNonNull will only improve the error message and add bulk to the code. Most of the use cases of requireNonNull here are "no doubt that a NPE will be triggered" and the only benefit of having them is to improve the err msg and there for add bulk to the code. What I'm saying here is the consistency. > >> >> (3) We have the requireNonNull check pattern below in most places >> if (X instanceof Y) { ... } >> Objects.requireNonNull(X, "x"); > Isn't that just useless, instanceof only returns true for non-null argument. >> >> but the plus/minus(TemporalAmount amountToSubtract) appears to be >> >> Objects.requireNonNull(...) >> if (X instanceof ...) {...} > This form would identify the null as coming from the parameter but the null check would > be performed twice (unless HS optimized) >> I may not have stated my observation clearly enough. In most of the cases the code inside {...} returned. My guess of intent of the original code is to optimize the case of non-null parameter AND the X is the instance of Y, which should be normal use scenario. But the plus/minus implementation appears not try to optimize this (null always triggers false for instanceof) for case that the amountToAdd is indeed a Period. This is also related my argument in (1), why we check requireNonNull here but not in (1). Well, not a big deal though. -Sherman From john.r.rose at oracle.com Thu Oct 3 22:44:39 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Oct 2013 15:44:39 -0700 Subject: Fwd: RFR (L) 8024761: JSR 292 improve performance of generic invocation References: <321B997C-A151-4162-BF5E-6E37F413AC4B@oracle.com> Message-ID: Here is a cross-post of a 292 review. Additional reviews are welcome. I will be integrating this into jdk8/tl/jdk/. ? John Begin forwarded message: From: Christian Thalinger Subject: Re: RFR (L) 8024761: JSR 292 improve performance of generic invocation Date: September 26, 2013 6:46:23 PM PDT To: Da Vinci Machine Project Cc: "hotspot-compiler-dev at openjdk.java.net compiler" Reply-To: Da Vinci Machine Project On Sep 18, 2013, at 6:43 PM, John Rose wrote: > On Sep 18, 2013, at 2:11 PM, Christian Thalinger wrote: > >> src/share/classes/java/lang/invoke/CallSite.java: >> >> + if (3 + argv.length > MethodType.MAX_MH_ARITY) >> + MethodType invocationType = MethodType.genericMethodType(3 + argv.length); >> + MethodHandle spreader = invocationType.invokers().spreadInvoker(3); >> >> Could we use a defined constant for "3"? > > Yes. >> >> src/share/classes/java/lang/invoke/Invokers.java: >> >> + if (targetType == targetType.erase() && targetType.parameterCount() < 10) >> >> The same here for "10". > > Fixed; factored to a subroutine. > >> Actually, exactInvoker and generalInvoker's code could be factored into one method. >> >> + /*non-public*/ MethodHandle basicInvoker() { >> + //invoker.form.compileToBytecode(); > > Done. > >> Please remove commented lines. >> >> + static MemberName exactInvokeLinkerMethod(MethodType mtype, Object[] appendixResult) { >> + static MemberName genericInvokeLinkerMethod(MethodType mtype, Object[] appendixResult) { >> >> These two could also be factored into one method. > > Done. I removed those two, and called the one new method from MethodHandleNatives. > >> + // Return an adapter for invokeExact or generic invoke, as a MH or constant pool linker >> + // mtype : the caller's method type (either basic or full-custom) >> + // customized : whether to use a trailing appendix argument (to carry the mtype) >> + // which&0x01 : whether it is a CP adapter ("linker") or MHs.invoker value ("invoker") >> + // which&0x02 : whether it is for invokeExact or generic invoke >> + // >> + // If !customized, caller is responsible for supplying, during adapter execution, >> + // a copy of the exact mtype. This is because the adapter might be generalized to >> + // a basic type. >> + private static LambdaForm invokeHandleForm(MethodType mtype, boolean customized, int which) { >> >> Why are you not using Javadoc style for this method comment? It's still helpful in IDEs. > > Fixed. > >> src/share/classes/java/lang/invoke/LambdaForm.java: >> >> static void traceInterpreter(String event, Object obj, Object... args) { >> + if (!(TRACE_INTERPRETER && INIT_DONE)) return; > > Done. >> >> Why not use the same pattern: >> >> + if (TRACE_INTERPRETER && INIT_DONE) >> >> as the other places? >> >> + static final boolean INIT_DONE = Boolean.TRUE.booleanValue(); >> >> Why are we having this after all? > > I removed it; see webrev. There's a comment which explains the problem and the nicer replacement. Good comment. Thank you. > >> src/share/classes/java/lang/invoke/MemberName.java: >> >> + public MemberName asNormalOriginal() { >> >> Could you add a comment to this method? It's not clear to me what "normal" and "original" mean here. > > Done. > >> + public MemberName(byte refKind, Class defClass, String name, Object type) { >> + @SuppressWarnings("LocalVariableHidesMemberVariable") >> + int kindFlags; >> >> The SuppressWarnings is in the other constructors because of the name "flags". You don't need it here. Maybe rename the others as well and get rid of the annotation. > > OK; I removed 2/3 of them. > >> src/share/classes/java/lang/invoke/MethodHandleNatives.java: >> >> static String refKindName(byte refKind) { >> assert(refKindIsValid(refKind)); >> - return REFERENCE_KIND_NAME[refKind]; >> + switch (refKind) { >> >> After this change REFERENCE_KIND_NAME is not used anymore. > > Good catch. > >> src/share/classes/java/lang/invoke/MethodHandles.java: >> >> + member.getName().getClass(); member.getType().getClass(); // NPE >> >> Please don't! It would be nice to have at least a different line number in the backtrace. > > OK. I split three such lines. > > I would like to switch all these to Objects.requireNonNull, but only after a little performance testing to make sure we don't have surprises. > >> src/share/classes/java/lang/invoke/MethodTypeForm.java: >> >> + //Lookup.findVirtual(MethodHandle.class, name, type); >> >> Either remove it or add a comment why it's there. > > Commented better now. > > While testing, I found a spot in BoundMethodHandle that needed a tweak to avoid a bootstrap problem. (Too many of those.) > > I sharpened the type of 'caller' in CallSite.makeSite. > > The webrev is updated: > http://cr.openjdk.java.net/~jrose/8024761/webrev.01/ This looks good. > > Thanks! > > ? John > >> On Sep 12, 2013, at 6:36 PM, John Rose wrote: >> >>> Please review this change for a change to the JSR 292 implementation: >>> >>> http://cr.openjdk.java.net/~jrose/8024761/webrev.00/ >>> >>> Bug description: The performance of MethodHandle.invoke is very slow when the call site type differs from the method handle type. When the types differ, the invocation is defined to proceed as if two steps were taken: >>> >>> 1. the target method handle is first adjusted to the call site type, by MethodHandles.asType >>> >>> 2. the type-adjusted method handle is invoked directly, by MethodHandles.invokeExact >>> >>> The existing code (from JDK 7) awkwardly performs the type adjustment on every call. But performing the type analysis and adapter creation on every call is inherently slow. A good fix is to cache the result of step 1 (MethodHandles.asType), since step 2 is already reasonably fast. >>> >>> For most applications, a one-element cache on each individual method handle is a reasonable choice. It has the particular advantage of speeding up invocations of non-varargs bootstrap methods. To benefit from this, the bootstrap methods themselves need to be uniquified across multiple class files, so this work will also include a cache to benefit commonly-used bootstrap methods, such as JDK 8's LambdaMetafactory.metafactory. >>> >>> Additional caches could be based on the call site, the call site type, the target type, or the target's MH.form. >>> >>> Thanks, >>> ? John >>> >>> P.S. Since this is an implementation change oriented toward performance, the review request is to mlvm-dev and hotspot-compiler-dev. >>> Changes which are oriented toward functionality will go to mlvm-dev and core-libs-dev. >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From coleen.phillimore at oracle.com Thu Oct 3 22:49:52 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 18:49:52 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DD388.8060706@oracle.com> References: <524DB145.5030109@oracle.com> <524DD388.8060706@oracle.com> Message-ID: <524DF490.3000005@oracle.com> Thanks Dan - On 10/3/2013 4:28 PM, Daniel D. Daugherty wrote: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > test/java/lang/instrument/RedefineMethodInBacktrace.sh > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceApp.java > line 78: t.setDaemon(true); > Why make the target thread a daemon? Wouldn't it be a more > complete test to do Thread.join() of that thread just to > be sure that the target thread has finished (and is not > stuck)? Staffan, can you answer this? Coleen > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java > test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java > Nice sync logic with the test driver. > > Thumbs up. > > Dan > > > On 10/3/13 12:02 PM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Thu Oct 3 22:56:21 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 18:56:21 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DCE7D.7020703@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> Message-ID: <524DF615.4000808@oracle.com> Thanks Dan - On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~coleenp/8025238/ > > src/share/vm/classfile/javaClasses.cpp > 1804 if (method == NULL) { > 1805 // leave name and fileName null > 1806 java_lang_StackTraceElement::set_lineNumber(element(), -1); > Is it possible to set the name and fileName to something? > A caller may not be expecting those to be NULL. > > Also, holder->method_with_idnum(method_id) should be able to > search the previous class version list and find the obsolete > Method* that matches the 'method_id' value. > We don't save the obsolete versions on the previous version list, only the emcp versions. I just looked at the old code and that's always been the case. So the method that has the method_idnum that isn't supposed to be found is an obsolete method. Coleen > src/share/vm/prims/jvmtiRedefineClasses.cpp > Better comment than the original. > > Dan > > > On 10/3/13 12:02 PM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen > From daniel.daugherty at oracle.com Thu Oct 3 23:01:34 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 17:01:34 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF615.4000808@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> <524DF615.4000808@oracle.com> Message-ID: <524DF74E.9090205@oracle.com> On 10/3/13 4:56 PM, Coleen Phillmore wrote: > > Thanks Dan - > > On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~coleenp/8025238/ >> >> src/share/vm/classfile/javaClasses.cpp >> 1804 if (method == NULL) { >> 1805 // leave name and fileName null >> 1806 java_lang_StackTraceElement::set_lineNumber(element(), -1); >> Is it possible to set the name and fileName to something? >> A caller may not be expecting those to be NULL. >> >> Also, holder->method_with_idnum(method_id) should be able to >> search the previous class version list and find the obsolete >> Method* that matches the 'method_id' value. >> > > We don't save the obsolete versions on the previous version list, only > the emcp versions. I just looked at the old code and that's always > been the case. So the method that has the method_idnum that isn't > supposed to be found is an obsolete method. Clearly I've forgotten... thumbs up! Dan > > Coleen > >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> Better comment than the original. >> >> Dan >> >> >> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>> Summary: Redefined class in stack trace may not be found by >>> method_idnum so handle null. >>> >>> This is a simple change. I had another change to save the method >>> name (as u2) in the backtrace, but it's not worth the extra >>> footprint in backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) >>> instead of Method* to avoid Method* from being redefined and >>> deallocated. I made a change to InstanceKlass::method_from_idnum() >>> to return null rather than the last method in the list, which causes >>> this crash. Dan and I went down the long rabbit-hole of why >>> method_idnum is changed for obsolete methods and we think there's >>> some cleanup and potential bugs in this area. But this is not that >>> change. I'll file another bug to continue this investigation for >>> jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review >>> request. Also tested with all of the vm testbase tests, mlvm tests, >>> and java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Thu Oct 3 23:01:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:01:39 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DCAA2.7050305@oracle.com> References: <524DB145.5030109@oracle.com> <524DCAA2.7050305@oracle.com> Message-ID: <524DF753.6070601@oracle.com> Thanks Serguei! Coleen On 10/3/2013 3:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good. > It is nice you've come up with this. > > Thanks, > Serguei > > On 10/3/13 11:02 AM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Thu Oct 3 23:02:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:02:01 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> Message-ID: <524DF769.5020509@oracle.com> On 10/3/2013 3:29 PM, Staffan Larsen wrote: > Looks good! (Obviously I would think so for the testcase :-) ) Thanks for the testcase! Coleen > > Thanks for fixing, > /Staffan > > On 3 okt 2013, at 20:02, Coleen Phillimore wrote: > >> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. >> >> This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Oct 3 23:02:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:02:44 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF74E.9090205@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> <524DF615.4000808@oracle.com> <524DF74E.9090205@oracle.com> Message-ID: <524DF794.4000909@oracle.com> On 10/3/2013 7:01 PM, Daniel D. Daugherty wrote: > On 10/3/13 4:56 PM, Coleen Phillmore wrote: >> >> Thanks Dan - >> >> On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: >>> > http://cr.openjdk.java.net/~coleenp/8025238/ >>> >>> src/share/vm/classfile/javaClasses.cpp >>> 1804 if (method == NULL) { >>> 1805 // leave name and fileName null >>> 1806 java_lang_StackTraceElement::set_lineNumber(element(), -1); >>> Is it possible to set the name and fileName to something? >>> A caller may not be expecting those to be NULL. >>> >>> Also, holder->method_with_idnum(method_id) should be able to >>> search the previous class version list and find the obsolete >>> Method* that matches the 'method_id' value. >>> >> >> We don't save the obsolete versions on the previous version list, >> only the emcp versions. I just looked at the old code and that's >> always been the case. So the method that has the method_idnum that >> isn't supposed to be found is an obsolete method. > > Clearly I've forgotten... thumbs up! :) Thanks, Coleen > > Dan > > >> >> Coleen >> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> Better comment than the original. >>> >>> Dan >>> >>> >>> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>>> Summary: Redefined class in stack trace may not be found by >>>> method_idnum so handle null. >>>> >>>> This is a simple change. I had another change to save the method >>>> name (as u2) in the backtrace, but it's not worth the extra >>>> footprint in backtraces for this rare case. >>>> >>>> The root problem was that we save method_idnum in the backtrace >>>> (u2) instead of Method* to avoid Method* from being redefined and >>>> deallocated. I made a change to InstanceKlass::method_from_idnum() >>>> to return null rather than the last method in the list, which >>>> causes this crash. Dan and I went down the long rabbit-hole of why >>>> method_idnum is changed for obsolete methods and we think there's >>>> some cleanup and potential bugs in this area. But this is not that >>>> change. I'll file another bug to continue this investigation for >>>> jdk9 (or 8uN). >>>> >>>> Staffan created a test - am including core-libs for the review >>>> request. Also tested with all of the vm testbase tests, mlvm >>>> tests, and java/lang/instrument tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>>> >>>> test case for jdk8 repository: >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>>> >>>> Thanks, >>>> Coleen >>> >> > From brian.burkhalter at oracle.com Thu Oct 3 23:10:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 16:10:39 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE Message-ID: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> Please review and comment at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 Webrev: http://cr.openjdk.java.net/~bpb/7179567/ Summary * Document and throw IAE from URLClassLoader constructors. * Throw ClassNotFoundException if null is passed to findClass method of a ClassLoader. * Clarify specification of SecureClassLoader.getPermissions. This change would require an approved CCC request and JCK test changes. Thanks, Brian From brian.burkhalter at oracle.com Thu Oct 3 23:17:00 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 16:17:00 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject Message-ID: Please review and comment at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8016252 Webrev: http://cr.openjdk.java.net/~bpb/8016252/ Summary * Improve validation checks in HashSet.readObject(). Would this change imply updating the serialVersionUID? Thanks, Brian From brent.christian at oracle.com Thu Oct 3 23:31:40 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 03 Oct 2013 16:31:40 -0700 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position Message-ID: <524DFE5C.1030705@oracle.com> Please review my fix for 8024709 : "TreeMap.DescendingKeyIterator 'remove' confuses iterator position" There are two possible code paths for performing a "descending" iteration over the elements in a TreeMep, depending on how the iteration is setup. For instance, treemap.descendingKeySet().iterator(); will use a TreeMap.NavigableSubMap.DescendingSubMapIterator This code correctly handles Iterator.remove(). On the other hand, treemap.navigableKeySet().descendingIterator(); will use a TreeMap.DescendingKeyIterator. This code does not correctly handle remove(), and results in a "confused" iterator. TreeMap.DescendingKeyIterator should override remove() with code similar to that in TreeMap.NavigableSubMap.SubMapIterator.removeDescending(). Bug report: https://bugs.openjdk.java.net/browse/JDK-8024709 Webrev: http://cr.openjdk.java.net/~bchristi/8024709/webrev.00/ An automated test run has not turned up any problems. Thanks, -Brent From brian.burkhalter at oracle.com Thu Oct 3 23:34:56 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 16:34:56 -0700 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks Message-ID: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> Threading and Random Number Experts, Revisiting https://bugs.openjdk.java.net/browse/JDK-7189139 which was last discussed in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020524.html Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. If this seems reasonable, does anyone have suggestions as to testing? Thanks, Brian From mike.duigou at oracle.com Thu Oct 3 23:53:54 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 3 Oct 2013 16:53:54 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> Message-ID: <1EF2DD7F-5F07-40D4-AC3B-819B14E9B010@oracle.com> I would normally suggest throwing NPE rather than other exceptions for detected invalid nulls. You can also then use Objects.requireNonNull() Mike On Oct 3 2013, at 16:10 , Brian Burkhalter wrote: > Please review and comment at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 > Webrev: http://cr.openjdk.java.net/~bpb/7179567/ > > Summary > * Document and throw IAE from URLClassLoader constructors. > * Throw ClassNotFoundException if null is passed to findClass method of a ClassLoader. > * Clarify specification of SecureClassLoader.getPermissions. > > This change would require an approved CCC request and JCK test changes. > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Oct 4 00:12:48 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 17:12:48 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <1EF2DD7F-5F07-40D4-AC3B-819B14E9B010@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <1EF2DD7F-5F07-40D4-AC3B-819B14E9B010@oracle.com> Message-ID: <172831AA-7F48-49C6-9BC1-5D9B74EB3810@oracle.com> So if s/IAE/NPE/ then the rest appears within reason? Brian On Oct 3, 2013, at 4:53 PM, Mike Duigou wrote: > I would normally suggest throwing NPE rather than other exceptions for detected invalid nulls. You can also then use Objects.requireNonNull() > > Mike > > On Oct 3 2013, at 16:10 , Brian Burkhalter wrote: > >> >> Summary >> * Document and throw IAE from URLClassLoader constructors. >> * Throw ClassNotFoundException if null is passed to findClass method of a ClassLoader. >> * Clarify specification of SecureClassLoader.getPermissions. From mike.duigou at oracle.com Fri Oct 4 00:14:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 3 Oct 2013 17:14:51 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <172831AA-7F48-49C6-9BC1-5D9B74EB3810@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <1EF2DD7F-5F07-40D4-AC3B-819B14E9B010@oracle.com> <172831AA-7F48-49C6-9BC1-5D9B74EB3810@oracle.com> Message-ID: <074CAD62-BD15-4F19-B2C0-59316D67CCBE@oracle.com> On Oct 3 2013, at 17:12 , Brian Burkhalter wrote: > So if s/IAE/NPE/ then the rest appears within reason? Yes. I would also changes the CNFE to an NPE. I have no comment (and total ignorance) on the SecureClassLoader changes. I couldn't approve this change without more research. Mike > Brian > > On Oct 3, 2013, at 4:53 PM, Mike Duigou wrote: > >> I would normally suggest throwing NPE rather than other exceptions for detected invalid nulls. You can also then use Objects.requireNonNull() >> >> Mike >> >> On Oct 3 2013, at 16:10 , Brian Burkhalter wrote: >> >>> >>> Summary >>> * Document and throw IAE from URLClassLoader constructors. >>> * Throw ClassNotFoundException if null is passed to findClass method of a ClassLoader. >>> * Clarify specification of SecureClassLoader.getPermissions. > From Alan.Bateman at oracle.com Fri Oct 4 00:35:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Oct 2013 17:35:23 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> Message-ID: <524E0D4B.8050601@oracle.com> On 03/10/2013 16:10, Brian Burkhalter wrote: > Please review and comment at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 > Webrev: http://cr.openjdk.java.net/~bpb/7179567/ > > Summary > * Document and throw IAE from URLClassLoader constructors. If urls is null then it looks like the long standing behavior is to throw NPE. If so then would be simpler to just specify that rather than switching to IAE? : > * Clarify specification of SecureClassLoader.getPermissions. > A minor comment on SecureClassLoader is that you might want to align the @throws to match the other @exception usages in the class. Will you be adding tests for these cases to the webrev? -Alan. From brian.burkhalter at oracle.com Fri Oct 4 00:38:50 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 17:38:50 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <524E0D4B.8050601@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> Message-ID: <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: > On 03/10/2013 16:10, Brian Burkhalter wrote: >> Please review and comment at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ >> >> Summary >> * Document and throw IAE from URLClassLoader constructors. > If urls is null then it looks like the long standing behavior is to throw NPE. If so then would be simpler to just specify that rather than switching to IAE? It would be. I think the main point is to catch the null parameter as soon as possible. I can easily do the s/IAE/NPE/ change in the revision. >> * Clarify specification of SecureClassLoader.getPermissions. >> > A minor comment on SecureClassLoader is that you might want to align the @throws to match the other @exception usages in the class. I saw that difference but am used to using "@throws." Is there any preference of one over the other in new code? > Will you be adding tests for these cases to the webrev? As needed once the concept in general is accepted. Brian From brian.burkhalter at oracle.com Fri Oct 4 00:58:42 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Oct 2013 17:58:42 -0700 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <524B89F1.7090602@bbs.darktech.org> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> Message-ID: <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> I have reviewed this proposed change a couple of times in its current form and it looks good to me. It would be good to see some comments about the general concept from BigInt cognoscenti, and from (a) Reviewer(s) as concerns the @implNote addition as well as the new ArithmeticExceptions added at several points in the javadoc. With respect to these latter, in the event the patch were to be approved, would a CCC request be in order? Brian On Oct 1, 2013, at 7:50 PM, cowwoc wrote: > Sounds good. Thanks for the clarification. > > Gili > > On 01/10/2013 9:25 PM, Dmitry Nadezhin wrote: >> I see that I misused the word "to clamp" in this discussion. >> I guess that addition with "clumping" means: >> return x + y < MIN_VALUE ? MIN_VALUE : x + y > MAX_VALUE ? MAX_VALUE : x + >> y; >> >> The patch actually throws ArithmeticException on overflow: >> if (x + y < MIN_VALUE || x + y > MAX_VALUE) throw new ArithmetiException(); >> else return x + y; >> >> The word "clamp" appeared in the discussion only. >> Comments in the patch don't contain it. They say: >> >> BigInteger constructors and operations throw {@code >> ArithmeticException} whenthe result is out of the supported range. >> >> On Tue, Oct 1, 2013 at 11:45 PM, cowwoc wrote: >> >>> I prefer throwing exceptions on unusual conditions (e.g. overflow) and >>> letting the user clamp the value if they so wish. Clamping will lead to >>> unexpected behavior once values fall outside this range. Yes, it will be >>> documented, but I daresay most applications won't ever check for it and >>> produce incorrect results as a consequence. >>> >>> Gili >>> >>> >>> On 01/10/2013 2:19 PM, Dmitry Nadezhin wrote: >>> >>>> Dear BigInteger experts, >>>> Do you have comments to my previous message ? >>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>> September/021264.html From david.holmes at oracle.com Fri Oct 4 02:27:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 12:27:56 +1000 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> Message-ID: <524E27AC.307@oracle.com> +1 on NPE rather than IAE - this is the common approach used elsewhere. It also means some explicit checks can be removed. BUT these explicit null URL checks could be relatively expensive. The same for the findClass(String name) change. It just bugs me that we have to slow down correct code with explicit null checks. For findClass if you just let NPE be thrown then we should trigger it without need for an explicit check. No comment on getPermissions. (This seems to be a mixed bag of issues). David On 4/10/2013 10:38 AM, Brian Burkhalter wrote: > > On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: > >> On 03/10/2013 16:10, Brian Burkhalter wrote: >>> Please review and comment at your convenience. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ >>> >>> Summary >>> * Document and throw IAE from URLClassLoader constructors. >> If urls is null then it looks like the long standing behavior is to throw NPE. If so then would be simpler to just specify that rather than switching to IAE? > > It would be. I think the main point is to catch the null parameter as soon as possible. I can easily do the s/IAE/NPE/ change in the revision. > >>> * Clarify specification of SecureClassLoader.getPermissions. >>> >> A minor comment on SecureClassLoader is that you might want to align the @throws to match the other @exception usages in the class. > > I saw that difference but am used to using "@throws." Is there any preference of one over the other in new code? > >> Will you be adding tests for these cases to the webrev? > > As needed once the concept in general is accepted. > > Brian > From mike.duigou at oracle.com Fri Oct 4 03:35:47 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 3 Oct 2013 20:35:47 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair Message-ID: Hello all; This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. Mike From Alan.Bateman at oracle.com Fri Oct 4 05:14:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Oct 2013 22:14:51 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: References: Message-ID: <524E4ECB.2040007@oracle.com> On 03/10/2013 16:17, Brian Burkhalter wrote: > Please review and comment at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8016252 > Webrev: http://cr.openjdk.java.net/~bpb/8016252/ > > Summary > * Improve validation checks in HashSet.readObject(). > > Would this change imply updating the serialVersionUID? > I assume that capacity and loadFactor will be checked when attempting to create the HashMap so I don't think we strictly need the additional checks. As regards size > capacity, then won't that break things if the loadFactor is high? The size < 0 case seems to be harmless, we'll just end up with an empty Set. You SVUID shouldn't be updated (the serial form hasn't changed). -Alan. From david.holmes at oracle.com Fri Oct 4 05:15:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 15:15:56 +1000 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: References: Message-ID: <524E4F0C.9060101@oracle.com> On 4/10/2013 1:35 PM, Mike Duigou wrote: > Hello all; > > This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. It isn't at all clear to me what specification you are using to define the expected behaviour here. I would have thought that anyone supplying a remapping function needs to be aware of whether the target map supports nulls or not, and that the remapping function should then do the right thing if null is encountered. Instead you are making the decision to bypass the remapping function if you encounter a null. David > The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. > > http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ > > Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. > > Mike > From Alan.Bateman at oracle.com Fri Oct 4 05:28:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Oct 2013 22:28:09 -0700 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: <524DFE5C.1030705@oracle.com> References: <524DFE5C.1030705@oracle.com> Message-ID: <524E51E9.5060400@oracle.com> On 03/10/2013 16:31, Brent Christian wrote: > Please review my fix for 8024709 : "TreeMap.DescendingKeyIterator > 'remove' confuses iterator position" > > There are two possible code paths for performing a "descending" > iteration over the elements in a TreeMep, depending on how the > iteration is setup. > > For instance, > treemap.descendingKeySet().iterator(); > will use a > TreeMap.NavigableSubMap.DescendingSubMapIterator > This code correctly handles Iterator.remove(). > > On the other hand, > treemap.navigableKeySet().descendingIterator(); > will use a > TreeMap.DescendingKeyIterator. > This code does not correctly handle remove(), and results in a > "confused" iterator. > > > TreeMap.DescendingKeyIterator should override remove() with code > similar to that in > TreeMap.NavigableSubMap.SubMapIterator.removeDescending(). > > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8024709 > > Webrev: > http://cr.openjdk.java.net/~bchristi/8024709/webrev.00/ The remove looks right to me and next() should return the predecessor that is already set. The test looks okay (although you might want to align the parameters to checkDescendingIteratorRemove), I just wonder if you would be worth generating additional cases to exercise this code a bit more. -Alan From david.holmes at oracle.com Fri Oct 4 05:47:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 15:47:19 +1000 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: <524E5667.3070102@oracle.com> Brian, On 3/10/2013 5:40 AM, Brian Burkhalter wrote: > I agree that is an ugly style but it guarantees that mistakes such as > > if (error = EAI_AGAIN) {} > > are caught at compilation time. True but as I understand it this is not the preferred/common style in the JDK code. David From jan.lahoda at oracle.com Fri Oct 4 06:32:03 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 04 Oct 2013 06:32:03 +0000 Subject: hg: jdk8/tl/langtools: 8025118: Annotation processing api returns default modifier for interface without default methods Message-ID: <20131004063211.3E5F362D4D@hg.openjdk.java.net> Changeset: c13305cf8528 Author: jlahoda Date: 2013-10-04 08:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestTypeElement.java From joe.darcy at oracle.com Fri Oct 4 06:43:24 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 03 Oct 2013 23:43:24 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported Message-ID: <524E638C.6090302@oracle.com> Hello, Per previous discussions on the mailing list, we've decided to rename the annotation type "jdk.Supported" to "jdk.Exported". Other than the file rename, the changes to the contents of the type are below: /** - * Indicates whether or not a JDK specific type or package is a - * supported part of the JDK. + * Indicates whether or not a JDK specific type or package is an + * exported part of the JDK suitable for use outside of the JDK + * implementation itself. * * This annotation should only be applied to types and packages * outside of the Java SE namespaces of {@code java.*} and * {@code javax.*} packages. For example, certain portions of {@code * com.sun.*} are official parts of the JDK meant to be generally @@ -42,12 +43,12 @@ * @since 1.8 */ @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.PACKAGE}) - at Supported -public @interface Supported { + at Exported +public @interface Exported { /** - * Whether or not this package or type is a supported part of the JDK. + * Whether or not the annotated type or package is an exported part of the JDK. */ boolean value() default true; } The webrev http://cr.openjdk.java.net/~darcy/8025913.0/ also contains the update for replacing all previous uses of jdk.Supported in the langtools repo with jdk.Exported. The Supported annotation type was not applied outside of langtools. Rebuild of langtools with this change and a clean build of the jdk both worked fine. Thanks, -Joe From staffan.larsen at oracle.com Fri Oct 4 07:11:09 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Oct 2013 09:11:09 +0200 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF490.3000005@oracle.com> References: <524DB145.5030109@oracle.com> <524DD388.8060706@oracle.com> <524DF490.3000005@oracle.com> Message-ID: On 4 okt 2013, at 00:49, Coleen Phillmore wrote: > > Thanks Dan - > > On 10/3/2013 4:28 PM, Daniel D. Daugherty wrote: >> > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> test/java/lang/instrument/RedefineMethodInBacktrace.sh >> No comments. >> >> test/java/lang/instrument/RedefineMethodInBacktraceApp.java >> line 78: t.setDaemon(true); >> Why make the target thread a daemon? Wouldn't it be a more >> complete test to do Thread.join() of that thread just to >> be sure that the target thread has finished (and is not >> stuck)? > > Staffan, can you answer this? You could do it either way. I don't have a strong opinion. It's possible that the deamonization is a leftover from one of my iterations of the test. /Staffan > > Coleen > >> >> test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java >> test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java >> Nice sync logic with the test driver. >> >> Thumbs up. >> >> Dan >> >> >> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. >>> >>> This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >>> >>> >> > From aleksey.shipilev at oracle.com Fri Oct 4 07:18:57 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 04 Oct 2013 11:18:57 +0400 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> Message-ID: <524E6BE1.6080406@oracle.com> On 10/04/2013 03:34 AM, Brian Burkhalter wrote: > Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. Seems OK with me, as long as Miller-Rabin test tolerates the lower-entropy PRNG. > If this seems reasonable, does anyone have suggestions as to testing? I would like to see the functional tests. We can take the list of prime numbers [1] as set P, and then check: a) numbers in intersect([2;N), P) return isProbablyPrime=true in more than >(1 - 1/2^cert) cases; b) all numbers in difference([2;N), P) return isProbablyPrime=false N > 50.000.000 would sound convincing. -Aleksey. [1] http://primes.utm.edu/lists/small/ From paul.sandoz at oracle.com Fri Oct 4 07:51:55 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Oct 2013 09:51:55 +0200 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <61E1ED5F-F053-448C-BE8B-FFCF7C6AFDD1@oracle.com> +1. Paul. On Oct 4, 2013, at 8:43 AM, Joe Darcy wrote: > Hello, > > Per previous discussions on the mailing list, we've decided to rename the annotation type "jdk.Supported" to "jdk.Exported". > > Other than the file rename, the changes to the contents of the type are below: > > /** > - * Indicates whether or not a JDK specific type or package is a > - * supported part of the JDK. > + * Indicates whether or not a JDK specific type or package is an > + * exported part of the JDK suitable for use outside of the JDK > + * implementation itself. > * > * This annotation should only be applied to types and packages > * outside of the Java SE namespaces of {@code java.*} and > * {@code javax.*} packages. For example, certain portions of {@code > * com.sun.*} are official parts of the JDK meant to be generally > > @@ -42,12 +43,12 @@ > * @since 1.8 > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE, ElementType.PACKAGE}) > - at Supported > -public @interface Supported { > + at Exported > +public @interface Exported { > /** > - * Whether or not this package or type is a supported part of the JDK. > + * Whether or not the annotated type or package is an exported part of the JDK. > */ > boolean value() default true; > } > > The webrev > > http://cr.openjdk.java.net/~darcy/8025913.0/ > > also contains the update for replacing all previous uses of jdk.Supported in the langtools repo with jdk.Exported. The Supported annotation type was not applied outside of langtools. > > Rebuild of langtools with this change and a clean build of the jdk both worked fine. > > Thanks, > > -Joe From peter.levart at gmail.com Fri Oct 4 07:54:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 04 Oct 2013 09:54:50 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524D65CF.3010209@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> <524D65CF.3010209@oracle.com> Message-ID: <524E744A.9040802@gmail.com> Hi Aleksey, I played with reference handling code and got the following idea: Instead of iterating over the set of active Cleaners looking for those that were cleared by the VM, make ReferenceQueue.poll/remove help ReferenceHandler thread in enqueue-ing the references. This assumes VM links the References into a discovered list at the same time as clearing them. Here's a prototype of this approach: http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.01/ It is maybe to aggressive to hook helping enqueue references on the public ReferenceQueue.poll/remove methods which affects other code too, but that could be changed (use package-private API between ReferenceQueue and Cleaner). With this variant, I was not able to fail the DirectBufferTest on my machine (4 cores i7) with 1,2,4,8,16,32,64 threads and -XX:MaxDirectMemorySize=100m. It sometimes fails quickly at 128 threads and sometimes passes 60 seconds without failure. There's certainly room for improvement. Without the patch it fails after ~500 iterations as soon as 2 threads are used. So what do you think of the approach in general? You see, I tried to avoid Thread.sleep() calls to prove the approach is very predictable even without them. The help-enqueue-references code is executed out of ReferenceQueue.poll/remove synchronized blocks, so there is no guarantee that all pending Cleaners have been processed before giving-up with OOME. Adding a short Thread.sleep() in the Bits loop: System.gc(); try { Thread.sleep(100L); } catch (InterruptedException x) {} cleans = Cleaner.assistCleanup(); Might help. It could even be exponential backoff. Regards, Peter On 10/03/2013 02:40 PM, Aleksey Shipilev wrote: > On 10/03/2013 04:32 PM, Paul Sandoz wrote: >> Alexsey, what do you observe if you revert back Cleaner to a >> PhantomReference and retain QUEUE/CLEANERS but not >> assistCleanupSlow? > I observed the minuscule probability (my estimate is <0.1%) we hit the > OOME with the original test. This is literally the very aggressive > fallback strategy. > > -Aleksey. From aleksey.shipilev at oracle.com Fri Oct 4 07:57:37 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 04 Oct 2013 11:57:37 +0400 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: <524E6BE1.6080406@oracle.com> References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> Message-ID: <524E74F1.80101@oracle.com> On 10/04/2013 11:18 AM, Aleksey Shipilev wrote: > On 10/04/2013 03:34 AM, Brian Burkhalter wrote: >> Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. > > Seems OK with me, as long as Miller-Rabin test tolerates the > lower-entropy PRNG. > >> If this seems reasonable, does anyone have suggestions as to testing? > > I would like to see the functional tests. > > We can take the list of prime numbers [1] as set P, and then check: > a) numbers in intersect([2;N), P) return isProbablyPrime=true in more > than >(1 - 1/2^cert) cases; > b) all numbers in difference([2;N), P) return isProbablyPrime=false Wait, this is one is wrong (too general). I meant to say all numbers in [2;N) that return isProbablyPrime=false are not in P. > N > 50.000.000 would sound convincing. I need this list for another reason, so I had preprocessed the first 50M primes here: http://cr.openjdk.java.net/~shade/scratch/primes-50M.txt.xz -Aleksey. From forax at univ-mlv.fr Fri Oct 4 08:27:01 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Oct 2013 10:27:01 +0200 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <61E1ED5F-F053-448C-BE8B-FFCF7C6AFDD1@oracle.com> References: <524E638C.6090302@oracle.com> <61E1ED5F-F053-448C-BE8B-FFCF7C6AFDD1@oracle.com> Message-ID: <524E7BD5.6050905@univ-mlv.fr> On 10/04/2013 09:51 AM, Paul Sandoz wrote: > +1. > > Paul. Yes, nice. I like the fact that Exported is annotated by itself :) R?mi > > On Oct 4, 2013, at 8:43 AM, Joe Darcy wrote: > >> Hello, >> >> Per previous discussions on the mailing list, we've decided to rename the annotation type "jdk.Supported" to "jdk.Exported". >> >> Other than the file rename, the changes to the contents of the type are below: >> >> /** >> - * Indicates whether or not a JDK specific type or package is a >> - * supported part of the JDK. >> + * Indicates whether or not a JDK specific type or package is an >> + * exported part of the JDK suitable for use outside of the JDK >> + * implementation itself. >> * >> * This annotation should only be applied to types and packages >> * outside of the Java SE namespaces of {@code java.*} and >> * {@code javax.*} packages. For example, certain portions of {@code >> * com.sun.*} are official parts of the JDK meant to be generally >> >> @@ -42,12 +43,12 @@ >> * @since 1.8 >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> @Target({ElementType.TYPE, ElementType.PACKAGE}) >> - at Supported >> -public @interface Supported { >> + at Exported >> +public @interface Exported { >> /** >> - * Whether or not this package or type is a supported part of the JDK. >> + * Whether or not the annotated type or package is an exported part of the JDK. >> */ >> boolean value() default true; >> } >> >> The webrev >> >> http://cr.openjdk.java.net/~darcy/8025913.0/ >> >> also contains the update for replacing all previous uses of jdk.Supported in the langtools repo with jdk.Exported. The Supported annotation type was not applied outside of langtools. >> >> Rebuild of langtools with this change and a clean build of the jdk both worked fine. >> >> Thanks, >> >> -Joe From paul.sandoz at oracle.com Fri Oct 4 08:33:01 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Oct 2013 10:33:01 +0200 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: <524E6BE1.6080406@oracle.com> References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> Message-ID: <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> On Oct 4, 2013, at 9:18 AM, Aleksey Shipilev wrote: > On 10/04/2013 03:34 AM, Brian Burkhalter wrote: >> Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. > > Seems OK with me, Same here. > as long as Miller-Rabin test tolerates the > lower-entropy PRNG. > I think so given recent updates to TLR. >> If this seems reasonable, does anyone have suggestions as to testing? > > I would like to see the functional tests. > > We can take the list of prime numbers [1] as set P, and then check: > a) numbers in intersect([2;N), P) return isProbablyPrime=true in more > than >(1 - 1/2^cert) cases; Plus the certainty is capped at 100 if the bit length of the big int < 100 (which is the case for the first 50M primes). For large bit lengths it is even less (capped at 4 for > 1024). (IIUC it is (1 - 1/4^N) for N iterations [1], for the impl N = certainty/2.) Paul. [1] http://mathworld.wolfram.com/Rabin-MillerStrongPseudoprimeTest.html > b) all numbers in difference([2;N), P) return isProbablyPrime=false > > N > 50.000.000 would sound convincing. > > -Aleksey. > > [1] http://primes.utm.edu/lists/small/ From paul.sandoz at oracle.com Fri Oct 4 08:51:45 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Oct 2013 10:51:45 +0200 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: <524E51E9.5060400@oracle.com> References: <524DFE5C.1030705@oracle.com> <524E51E9.5060400@oracle.com> Message-ID: On Oct 4, 2013, at 7:28 AM, Alan Bateman wrote: > On 03/10/2013 16:31, Brent Christian wrote: >> Please review my fix for 8024709 : "TreeMap.DescendingKeyIterator 'remove' confuses iterator position" >> >> There are two possible code paths for performing a "descending" iteration over the elements in a TreeMep, depending on how the iteration is setup. >> >> For instance, >> treemap.descendingKeySet().iterator(); >> will use a >> TreeMap.NavigableSubMap.DescendingSubMapIterator >> This code correctly handles Iterator.remove(). >> >> On the other hand, >> treemap.navigableKeySet().descendingIterator(); >> will use a >> TreeMap.DescendingKeyIterator. >> This code does not correctly handle remove(), and results in a "confused" iterator. >> >> >> TreeMap.DescendingKeyIterator should override remove() with code >> similar to that in TreeMap.NavigableSubMap.SubMapIterator.removeDescending(). >> >> >> Bug report: >> https://bugs.openjdk.java.net/browse/JDK-8024709 >> >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8024709/webrev.00/ > The remove looks right to me and next() should return the predecessor that is already set. > Looks ok to me too. > The test looks okay (although you might want to align the parameters to checkDescendingIteratorRemove), I just wonder if you would be worth generating additional cases to exercise this code a bit more. > One could write a general test without having to pass in expicit values and if so i suspect it is better to pass in the ascending collection and descending iterator (since the toArray could be implemented using an iterator): void checkTraverse2Remove1Traverse1(Collection aC, Iterator dIt) { T[] values = (T) aC.toArray(); int n = values.length -1; equalNext(dIt, values[n--]); equalNext(dIt, values[n--]); it.remove(); equalNext(dIt, values[n]); } Might also be useful to have a test that removes the last traversed element. Paul. From daniel.fuchs at oracle.com Fri Oct 4 10:02:16 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Oct 2013 12:02:16 +0200 Subject: (jaxp) RFR - 8025745: Clarify API documentation of JAXP factories. Message-ID: <524E9228.5050608@oracle.com> Hi, Please find below a fix for: 8025745: Clarify API documentation of JAXP factories. [1] This is an API doc only changes which clarifies the usage of ServiceLoader by JAXP factories - as was implemented by JDK-8005954 [2] Basically it makes it explicit in the doc that the ServiceLoader will the TCCL - or if that is null, the system class loader. http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.00/ best regards -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8025745 [2] https://bugs.openjdk.java.net/browse/JDK-8005954 From scolebourne at joda.org Fri Oct 4 10:16:09 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 4 Oct 2013 11:16:09 +0100 Subject: Review Request for project Threeten updates In-Reply-To: <524DEAC6.60906@oracle.com> References: <524B13E1.4090202@oracle.com> <524DB9B4.8080400@oracle.com> <524DDB99.7000703@oracle.com> <524DEAC6.60906@oracle.com> Message-ID: On 3 October 2013 23:08, Xueming Shen wrote: > (2) It appears we started to use "endExclusive" in "until() methods, while > the param > has been renamed to be "exclusive" explicitly, personally I prefer > still keep the > word "exclusive" in its spec, or at least we want to be consistent, for > example > LocalDate.until(ChronoLocalDate) still keeps the "exclusive" after > renaming. The "exclusive" in the parameter name is for IDE autocompletion. I'm surprised I didn't put it in before as its my long standing practice and very useful for users. The Javadoc should also state exclusive. > On 10/03/2013 02:03 PM, roger riggs wrote: >> On 10/3/2013 2:38 PM, Xueming Shen wrote: >>> (1) until(Temporal endExclusive, TEmporalUnit unit) >>> -> Shouldn't we invoke requireNonNull() for unit before invoking >>> unit.between(...)? >> >> There is no doubt that invoking unit.between() will cause an NPE if unit >> is null. >> Adding requireNonNull will only improve the error message and add bulk to >> the code. > > Most of the use cases of requireNonNull here are "no doubt that a NPE will > be triggered" > and the only benefit of having them is to improve the err msg and there for > add bulk to > the code. What I'm saying here is the consistency. There are lots of places in 310 where we have Objects.requireNotNull and lots of places where we don't. Where we don't the minimum should be an early throw of NPE that would be simple for a user to identify. If it would be complex to identify then requireNotNull is useful. So, not entirely consistent, but not completely inconsistent either... >>> (3) We have the requireNonNull check pattern below in most places >>> if (X instanceof Y) { ... } >>> Objects.requireNonNull(X, "x"); >> >> Isn't that just useless, instanceof only returns true for non-null >> argument. Yes, that check is useless. > I may not have stated my observation clearly enough. In most of the cases > the code inside {...} returned. My guess of intent of the original code is > to > optimize the case of non-null parameter AND the X is the instance of Y, > which > should be normal use scenario. But the plus/minus implementation appears > not try to optimize this (null always triggers false for instanceof) for > case that > the amountToAdd is indeed a Period. This is also related my argument in (1), > why we check requireNonNull here but not in (1). Well, not a big deal > though. In general, if there is a sensible order of code for minor optimisation I tried to do it. But it might not be consistent. Stephen From michael.x.mcmahon at oracle.com Fri Oct 4 10:49:37 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 04 Oct 2013 11:49:37 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <524E0D4B.8050601@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> Message-ID: <524E9D41.7040808@oracle.com> On 04/10/13 01:35, Alan Bateman wrote: > On 03/10/2013 16:10, Brian Burkhalter wrote: >> Please review and comment at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ >> >> Summary >> * Document and throw IAE from URLClassLoader constructors. > If urls is null then it looks like the long standing behavior is to > throw NPE. If so then would be simpler to just specify that rather > than switching to IAE? > I agree. Documenting NPE seems reasonable to me. I'm not convinced of the need for any behavior changes in the class. Michael. > : > >> * Clarify specification of SecureClassLoader.getPermissions. >> > A minor comment on SecureClassLoader is that you might want to align > the @throws to match the other @exception usages in the class. > > Will you be adding tests for these cases to the webrev? > > -Alan. From lance.andersen at oracle.com Fri Oct 4 11:25:18 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 4 Oct 2013 07:25:18 -0400 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <05B04E31-CB36-4E3C-A710-58EEA0871AC7@oracle.com> +1 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 Oct 4, 2013, at 2:43 AM, Joe Darcy wrote: > Hello, > > Per previous discussions on the mailing list, we've decided to rename the annotation type "jdk.Supported" to "jdk.Exported". > > Other than the file rename, the changes to the contents of the type are below: > > /** > - * Indicates whether or not a JDK specific type or package is a > - * supported part of the JDK. > + * Indicates whether or not a JDK specific type or package is an > + * exported part of the JDK suitable for use outside of the JDK > + * implementation itself. > * > * This annotation should only be applied to types and packages > * outside of the Java SE namespaces of {@code java.*} and > * {@code javax.*} packages. For example, certain portions of {@code > * com.sun.*} are official parts of the JDK meant to be generally > > @@ -42,12 +43,12 @@ > * @since 1.8 > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE, ElementType.PACKAGE}) > - at Supported > -public @interface Supported { > + at Exported > +public @interface Exported { > /** > - * Whether or not this package or type is a supported part of the JDK. > + * Whether or not the annotated type or package is an exported part of the JDK. > */ > boolean value() default true; > } > > The webrev > > http://cr.openjdk.java.net/~darcy/8025913.0/ > > also contains the update for replacing all previous uses of jdk.Supported in the langtools repo with jdk.Exported. The Supported annotation type was not applied outside of langtools. > > Rebuild of langtools with this change and a clean build of the jdk both worked fine. > > Thanks, > > -Joe From pavel.punegov at oracle.com Fri Oct 4 11:39:01 2013 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 04 Oct 2013 15:39:01 +0400 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds Message-ID: <1888522.a2LG2QfRuS@trisuli> Please review this fix for the test bug Issue: https://bugs.openjdk.java.net/browse/JDK-8024660 Webrev: http://cr.openjdk.java.net/~robm/8024660/webrev.01/ Summary: Add a wait for process C finish before we return and pass the test. There are also some code improvements made for easier code reading. Thanks, Pavel From peter.levart at gmail.com Fri Oct 4 12:43:26 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 04 Oct 2013 14:43:26 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524E744A.9040802@gmail.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> <524D65CF.3010209@oracle.com> <524E744A.9040802@gmail.com> Message-ID: <524EB7EE.6060801@gmail.com> Hi Aleksey, This one is even better: http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.02/ Instead of hooking up on the ReferenceQueue.poll/remove methods, there are two new methods in ReferenceQueue: drain/drainLoop - only the 1st one helps in enqueue-ing while holding the queue's lock. This guarantees that no pending references are left behind - well only one single Reference can be skipped - the one in-transit in the ReferenceHandler thread. The other, drainLoop, is used in CleanerHandler thread to process Cleaners in background. This one does not do any helping. The only reason for using: cleanersQueue.drainLoop(c -> ((Cleaner)c).clean()); instead of external looping: for (;;) { Cleaner c = (Cleaner) cleanersQueue.remove(); c.clean(); } is that with drainLoop, the queue's lock is not relinquished between de-queue-ing the Cleaner and invoking it's clean() method. This prevents another Cleaner to be left behind when drain() is called. With this variant, using no Thread.sleep(), I can not make DirectBufferTest to fail, no matter how many allocating threads I start (1, 2, 4, 8, 16, ..., 256). Regards, Peter On 10/04/2013 09:54 AM, Peter Levart wrote: > Hi Aleksey, > > I played with reference handling code and got the following idea: > Instead of iterating over the set of active Cleaners looking for those > that were cleared by the VM, make ReferenceQueue.poll/remove help > ReferenceHandler thread in enqueue-ing the references. This assumes VM > links the References into a discovered list at the same time as > clearing them. Here's a prototype of this approach: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.01/ > > It is maybe to aggressive to hook helping enqueue references on the > public ReferenceQueue.poll/remove methods which affects other code > too, but that could be changed (use package-private API between > ReferenceQueue and Cleaner). With this variant, I was not able to fail > the DirectBufferTest on my machine (4 cores i7) with 1,2,4,8,16,32,64 > threads and -XX:MaxDirectMemorySize=100m. It sometimes fails quickly > at 128 threads and sometimes passes 60 seconds without failure. > There's certainly room for improvement. Without the patch it fails > after ~500 iterations as soon as 2 threads are used. > > So what do you think of the approach in general? You see, I tried to > avoid Thread.sleep() calls to prove the approach is very predictable > even without them. The help-enqueue-references code is executed out of > ReferenceQueue.poll/remove synchronized blocks, so there is no > guarantee that all pending Cleaners have been processed before > giving-up with OOME. Adding a short Thread.sleep() in the Bits loop: > > System.gc(); > try { > Thread.sleep(100L); > } > catch (InterruptedException x) {} > cleans = Cleaner.assistCleanup(); > > Might help. It could even be exponential backoff. > > Regards, Peter > > On 10/03/2013 02:40 PM, Aleksey Shipilev wrote: >> On 10/03/2013 04:32 PM, Paul Sandoz wrote: >>> Alexsey, what do you observe if you revert back Cleaner to a >>> PhantomReference and retain QUEUE/CLEANERS but not >>> assistCleanupSlow? >> I observed the minuscule probability (my estimate is <0.1%) we hit the >> OOME with the original test. This is literally the very aggressive >> fallback strategy. >> >> -Aleksey. > From sundararajan.athijegannathan at oracle.com Fri Oct 4 13:05:39 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 04 Oct 2013 13:05:39 +0000 Subject: hg: jdk8/tl/nashorn: 8025771: Enhance Nashorn Contexts Message-ID: <20131004130547.E8AB662D72@hg.openjdk.java.net> Changeset: 3470bc26128f Author: sundar Date: 2013-10-04 16:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3470bc26128f 8025771: Enhance Nashorn Contexts Reviewed-by: jlaskey, hannesw - make/java.security.override ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8023026.js + test/script/sandbox/arrayclass.js + test/script/sandbox/arrayclass.js.EXPECTED From Alan.Bateman at oracle.com Fri Oct 4 13:08:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Oct 2013 06:08:16 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <524EBDC0.7080207@oracle.com> On 03/10/2013 23:43, Joe Darcy wrote: > : > > The webrev > > http://cr.openjdk.java.net/~darcy/8025913.0/ > > also contains the update for replacing all previous uses of > jdk.Supported in the langtools repo with jdk.Exported. The Supported > annotation type was not applied outside of langtools. Thanks Joe, I'm happy with this. I will send a re-base the webrev the patch that adds this to the exports APIs in the jdk repository and send that out soon (hopefully next week). -Alan From Alan.Bateman at oracle.com Fri Oct 4 13:33:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Oct 2013 06:33:04 -0700 Subject: (jaxp) RFR - 8025745: Clarify API documentation of JAXP factories. In-Reply-To: <524E9228.5050608@oracle.com> References: <524E9228.5050608@oracle.com> Message-ID: <524EC390.50500@oracle.com> On 04/10/2013 03:02, Daniel Fuchs wrote: > : > > http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.00/ This mostly looks good, the only thing is that it reads "the service-provider will use ..." but I think you mean "the service-provider loading facility will use ..." -Alan. From aleksey.shipilev at oracle.com Fri Oct 4 13:37:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 04 Oct 2013 17:37:43 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524EB7EE.6060801@gmail.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> <524D65CF.3010209@oracle.com> <524E744A.9040802@gmail.com> <524EB7EE.6060801@gmail.com> Message-ID: <524EC4A7.2070009@oracle.com> Hi Peter, On 10/04/2013 04:43 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.02/ So you are taking on assisting the ReferenceHandler directly. Nice idea. I can only glimpse over the changes at this point... - You can't add the public methods to java.ref.* APIs (as easily); should we require this, turn new methods to privates, and use sun.misc.SharedSecrets as the doorway. - The internal double-linked list schematics makes me itchy; my patch cleaned this up, can yours? - ReferenceQueue.drainLoop: combine the try blocks - Reference: rename enqueueNext -> tryEnqueueNext - Reference: rename waitForNotifyIfNonePending -> waitForNotify - Reference: please don't move static initializer, harder to read the cahnge - Bits: please declare the variables on the individual lines - Bits: don't you want to keep Thread.sleep(100) around to let GC catch up with the reference processing? This will also help the case of completely asynchronous System.gc() -- your code will just spin over the System.gc()'s and throw OOME. - Cleaner: cleanCount is a strange name given we most probably anticipate and tolerate overflow. There is also the theoretical chance we will overflow and spin right to the same count. Make it AtomicLong? - Cleaner: since we are using JDK 8 interfaces anyway, why not using the lambda for cleanConsumer? Thanks, -Aleksey. From staffan.larsen at oracle.com Fri Oct 4 13:19:00 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 04 Oct 2013 13:19:00 +0000 Subject: hg: jdk8/tl/jdk: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Message-ID: <20131004131913.076C062D74@hg.openjdk.java.net> Changeset: 77ba1e67707c Author: allwin Date: 2013-10-04 15:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77ba1e67707c 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Reviewed-by: sla, jbachorik ! test/ProblemList.txt From daniel.fuchs at oracle.com Fri Oct 4 14:44:42 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Oct 2013 16:44:42 +0200 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <524DC583.8060104@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> <524D8398.4000005@oracle.com> <524D8E0A.30404@oracle.com> <524D93BB.20501@oracle.com> <524DC583.8060104@oracle.com> Message-ID: <524ED45A.9080105@oracle.com> Hi Mandy, On 10/3/13 9:29 PM, Mandy Chung wrote: > > test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java > > 109 return new Vector(java.util.Arrays.asList( > 110 new String[] {"dummy"})).elements(); > > Could you use Collections.enumeration? Excellent! Yes I will. > test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java > > 194 if (foobaz.getResourceBundleName() != null) { > 195 throw new RuntimeException("Unexpected bundle: " > 196 + foobar.getResourceBundle()); > 197 } > > I guess you meant to print foobar.getResourceBundleName() in line 196. Oops - yes - thanks for catching that. > The test cases are good. It'd be good to add some comments to > describe what each case verifies when appropriate. > > You can make these changes before you push. No need for a new webrev. OK - thanks -- daniel > > thanks > Mandy > From roger.riggs at oracle.com Fri Oct 4 14:45:15 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 04 Oct 2013 10:45:15 -0400 Subject: Review Request for project Threeten updates In-Reply-To: References: <524B13E1.4090202@oracle.com> <524DB9B4.8080400@oracle.com> <524DDB99.7000703@oracle.com> <524DEAC6.60906@oracle.com> Message-ID: <524ED47B.2030504@oracle.com> The webrev has been updated to: - In the until methods, add exclusive to the descriptions in the @param tags in addition to the parameter name - Optimize the use of requireNonNull so it appears only in the paths for instanceof == false - Clarified in Temporal.until that the *converted* input temporal is passed to the between method. http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/ Thanks, Roger On 10/4/2013 6:16 AM, Stephen Colebourne wrote: > On 3 October 2013 23:08, Xueming Shen wrote: >> (2) It appears we started to use "endExclusive" in "until() methods, while >> the param >> has been renamed to be "exclusive" explicitly, personally I prefer >> still keep the >> word "exclusive" in its spec, or at least we want to be consistent, for >> example >> LocalDate.until(ChronoLocalDate) still keeps the "exclusive" after >> renaming. > The "exclusive" in the parameter name is for IDE autocompletion. I'm > surprised I didn't put it in before as its my long standing practice > and very useful for users. The Javadoc should also state exclusive. > >> On 10/03/2013 02:03 PM, roger riggs wrote: >>> On 10/3/2013 2:38 PM, Xueming Shen wrote: >>>> (1) until(Temporal endExclusive, TEmporalUnit unit) >>>> -> Shouldn't we invoke requireNonNull() for unit before invoking >>>> unit.between(...)? >>> There is no doubt that invoking unit.between() will cause an NPE if unit >>> is null. >>> Adding requireNonNull will only improve the error message and add bulk to >>> the code. >> Most of the use cases of requireNonNull here are "no doubt that a NPE will >> be triggered" >> and the only benefit of having them is to improve the err msg and there for >> add bulk to >> the code. What I'm saying here is the consistency. > There are lots of places in 310 where we have Objects.requireNotNull > and lots of places where we don't. Where we don't the minimum should > be an early throw of NPE that would be simple for a user to identify. > If it would be complex to identify then requireNotNull is useful. > > So, not entirely consistent, but not completely inconsistent either... > >>>> (3) We have the requireNonNull check pattern below in most places >>>> if (X instanceof Y) { ... } >>>> Objects.requireNonNull(X, "x"); >>> Isn't that just useless, instanceof only returns true for non-null >>> argument. > Yes, that check is useless. > > >> I may not have stated my observation clearly enough. In most of the cases >> the code inside {...} returned. My guess of intent of the original code is >> to >> optimize the case of non-null parameter AND the X is the instance of Y, >> which >> should be normal use scenario. But the plus/minus implementation appears >> not try to optimize this (null always triggers false for instanceof) for >> case that >> the amountToAdd is indeed a Period. This is also related my argument in (1), >> why we check requireNonNull here but not in (1). Well, not a big deal >> though. > In general, if there is a sensible order of code for minor > optimisation I tried to do it. But it might not be consistent. > > Stephen From mandy.chung at oracle.com Fri Oct 4 15:06:00 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 04 Oct 2013 08:06:00 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <524ED958.9090106@oracle.com> Looks good. Mandy On 10/3/2013 11:43 PM, Joe Darcy wrote: > Hello, > > Per previous discussions on the mailing list, we've decided to rename > the annotation type "jdk.Supported" to "jdk.Exported". > > Other than the file rename, the changes to the contents of the type > are below: > > /** > - * Indicates whether or not a JDK specific type or package is a > - * supported part of the JDK. > + * Indicates whether or not a JDK specific type or package is an > + * exported part of the JDK suitable for use outside of the JDK > + * implementation itself. > * > * This annotation should only be applied to types and packages > * outside of the Java SE namespaces of {@code java.*} and > * {@code javax.*} packages. For example, certain portions of {@code > * com.sun.*} are official parts of the JDK meant to be generally > > @@ -42,12 +43,12 @@ > * @since 1.8 > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE, ElementType.PACKAGE}) > - at Supported > -public @interface Supported { > + at Exported > +public @interface Exported { > /** > - * Whether or not this package or type is a supported part of the > JDK. > + * Whether or not the annotated type or package is an exported > part of the JDK. > */ > boolean value() default true; > } > > The webrev > > http://cr.openjdk.java.net/~darcy/8025913.0/ > > also contains the update for replacing all previous uses of > jdk.Supported in the langtools repo with jdk.Exported. The Supported > annotation type was not applied outside of langtools. > > Rebuild of langtools with this change and a clean build of the jdk > both worked fine. > > Thanks, > > -Joe From rob.mckenna at oracle.com Fri Oct 4 15:10:08 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 04 Oct 2013 16:10:08 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <1888522.a2LG2QfRuS@trisuli> References: <1888522.a2LG2QfRuS@trisuli> Message-ID: <524EDA50.5080706@oracle.com> Hi Pavel, Thanks for sorting this out. I'm not a reviewer but hopefully Alan will have a look when he gets a chance. Based on the bug description this looks good to me though. -Rob On 04/10/13 12:39, Pavel Punegov wrote: > > Please review this fix for the test bug > > Issue: https://bugs.openjdk.java.net/browse/JDK-8024660 > > Webrev: http://cr.openjdk.java.net/~robm/8024660/webrev.01/ > > Summary: > > Add a wait for process C finish before we return and pass the test. > > There are also some code improvements made for easier code reading. > > Thanks, > > Pavel > From vincent.x.ryan at oracle.com Fri Oct 4 15:06:58 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 04 Oct 2013 15:06:58 +0000 Subject: hg: jdk8/tl/jdk: 8008296: keytool utility doesn't support '-importpassword' command Message-ID: <20131004150846.CCBE862D79@hg.openjdk.java.net> Changeset: b5aad88cbf12 Author: vinnie Date: 2013-10-04 16:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5aad88cbf12 8008296: keytool utility doesn't support '-importpassword' command Reviewed-by: weijun ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/StorePasswords.java + test/sun/security/tools/keytool/StorePasswordsByShell.sh From xueming.shen at oracle.com Fri Oct 4 15:39:49 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 04 Oct 2013 08:39:49 -0700 Subject: Review Request for project Threeten updates In-Reply-To: <524ED47B.2030504@oracle.com> References: <524B13E1.4090202@oracle.com> <524DB9B4.8080400@oracle.com> <524DDB99.7000703@oracle.com> <524DEAC6.60906@oracle.com> <524ED47B.2030504@oracle.com> Message-ID: <524EE145.3060606@oracle.com> looks fine. -sherman On 10/4/13 7:45 AM, roger riggs wrote: > The webrev has been updated to: > - In the until methods, add exclusive to the descriptions in the > @param tags in addition to the parameter name > - Optimize the use of requireNonNull so it appears only in the paths > for instanceof == false > - Clarified in Temporal.until that the *converted* input temporal is > passed to the between method. > > http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/ > > > Thanks, Roger > > > On 10/4/2013 6:16 AM, Stephen Colebourne wrote: >> On 3 October 2013 23:08, Xueming Shen wrote: >>> (2) It appears we started to use "endExclusive" in "until() methods, >>> while >>> the param >>> has been renamed to be "exclusive" explicitly, personally I >>> prefer >>> still keep the >>> word "exclusive" in its spec, or at least we want to be >>> consistent, for >>> example >>> LocalDate.until(ChronoLocalDate) still keeps the "exclusive" >>> after >>> renaming. >> The "exclusive" in the parameter name is for IDE autocompletion. I'm >> surprised I didn't put it in before as its my long standing practice >> and very useful for users. The Javadoc should also state exclusive. >> >>> On 10/03/2013 02:03 PM, roger riggs wrote: >>>> On 10/3/2013 2:38 PM, Xueming Shen wrote: >>>>> (1) until(Temporal endExclusive, TEmporalUnit unit) >>>>> -> Shouldn't we invoke requireNonNull() for unit before invoking >>>>> unit.between(...)? >>>> There is no doubt that invoking unit.between() will cause an NPE if >>>> unit >>>> is null. >>>> Adding requireNonNull will only improve the error message and add >>>> bulk to >>>> the code. >>> Most of the use cases of requireNonNull here are "no doubt that a >>> NPE will >>> be triggered" >>> and the only benefit of having them is to improve the err msg and >>> there for >>> add bulk to >>> the code. What I'm saying here is the consistency. >> There are lots of places in 310 where we have Objects.requireNotNull >> and lots of places where we don't. Where we don't the minimum should >> be an early throw of NPE that would be simple for a user to identify. >> If it would be complex to identify then requireNotNull is useful. >> >> So, not entirely consistent, but not completely inconsistent either... >> >>>>> (3) We have the requireNonNull check pattern below in most places >>>>> if (X instanceof Y) { ... } >>>>> Objects.requireNonNull(X, "x"); >>>> Isn't that just useless, instanceof only returns true for non-null >>>> argument. >> Yes, that check is useless. >> >> >>> I may not have stated my observation clearly enough. In most of the >>> cases >>> the code inside {...} returned. My guess of intent of the original >>> code is >>> to >>> optimize the case of non-null parameter AND the X is the instance of Y, >>> which >>> should be normal use scenario. But the plus/minus implementation >>> appears >>> not try to optimize this (null always triggers false for instanceof) >>> for >>> case that >>> the amountToAdd is indeed a Period. This is also related my argument >>> in (1), >>> why we check requireNonNull here but not in (1). Well, not a big deal >>> though. >> In general, if there is a sensible order of code for minor >> optimisation I tried to do it. But it might not be consistent. >> >> Stephen > From alexander.zuev at oracle.com Fri Oct 4 15:39:23 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Fri, 04 Oct 2013 15:39:23 +0000 Subject: hg: jdk8/tl/langtools: 7096170: should remove unused support for enabling javac logging Message-ID: <20131004153931.CB4C862D7A@hg.openjdk.java.net> Changeset: c0d44b1e6b6a Author: kizune Date: 2013-10-04 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d44b1e6b6a 7096170: should remove unused support for enabling javac logging Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From daniel.fuchs at oracle.com Fri Oct 4 16:11:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Oct 2013 18:11:08 +0200 Subject: (jaxp) RFR - 8025745: Clarify API documentation of JAXP factories. In-Reply-To: <524EC390.50500@oracle.com> References: <524E9228.5050608@oracle.com> <524EC390.50500@oracle.com> Message-ID: <524EE89C.6080603@oracle.com> On 10/4/13 3:33 PM, Alan Bateman wrote: > On 04/10/2013 03:02, Daniel Fuchs wrote: >> : >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.00/ > This mostly looks good, the only thing is that it reads "the > service-provider will use ..." but I think you mean "the > service-provider loading facility will use ..." > > -Alan. Right! Thanks for spotting that Alan. http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.01 -- daniel From paul.sandoz at oracle.com Fri Oct 4 16:36:17 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Oct 2013 18:36:17 +0200 Subject: (jaxp) RFR - 8025745: Clarify API documentation of JAXP factories. In-Reply-To: <524EE89C.6080603@oracle.com> References: <524E9228.5050608@oracle.com> <524EC390.50500@oracle.com> <524EE89C.6080603@oracle.com> Message-ID: <6690D6A9-9CCD-49AD-9336-02722E477399@oracle.com> On Oct 4, 2013, at 6:11 PM, Daniel Fuchs wrote: > On 10/4/13 3:33 PM, Alan Bateman wrote: >> On 04/10/2013 03:02, Daniel Fuchs wrote: >>> : >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.00/ >> This mostly looks good, the only thing is that it reads "the >> service-provider will use ..." but I think you mean "the >> service-provider loading facility will use ..." >> >> -Alan. > > Right! Thanks for spotting that Alan. > > http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.01 > Looks good. It would be nice to factor out the repeating text to a link in package javadoc, but there does not appear to be any suitable shared location; stuff on java.xml might work but probably will look out of place. Paul. From jonathan.gibbons at oracle.com Fri Oct 4 16:53:38 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Oct 2013 09:53:38 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <524EF292.9060200@oracle.com> On 10/03/2013 11:43 PM, Joe Darcy wrote: > Hello, > > Per previous discussions on the mailing list, we've decided to rename > the annotation type "jdk.Supported" to "jdk.Exported". > > Other than the file rename, the changes to the contents of the type > are below: > > /** > - * Indicates whether or not a JDK specific type or package is a > - * supported part of the JDK. > + * Indicates whether or not a JDK specific type or package is an > + * exported part of the JDK suitable for use outside of the JDK > + * implementation itself. > * > * This annotation should only be applied to types and packages > * outside of the Java SE namespaces of {@code java.*} and > * {@code javax.*} packages. For example, certain portions of {@code > * com.sun.*} are official parts of the JDK meant to be generally > > @@ -42,12 +43,12 @@ > * @since 1.8 > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE, ElementType.PACKAGE}) > - at Supported > -public @interface Supported { > + at Exported > +public @interface Exported { > /** > - * Whether or not this package or type is a supported part of the > JDK. > + * Whether or not the annotated type or package is an exported > part of the JDK. > */ > boolean value() default true; > } > > The webrev > > http://cr.openjdk.java.net/~darcy/8025913.0/ > > also contains the update for replacing all previous uses of > jdk.Supported in the langtools repo with jdk.Exported. The Supported > annotation type was not applied outside of langtools. > > Rebuild of langtools with this change and a clean build of the jdk > both worked fine. > > Thanks, > > -Joe Looks OK to me. -- Jon From roger.riggs at oracle.com Fri Oct 4 16:53:10 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 04 Oct 2013 16:53:10 +0000 Subject: hg: jdk8/tl/jdk: 7 new changesets Message-ID: <20131004165456.3C0CA62D87@hg.openjdk.java.net> Changeset: 1de0fac9b962 Author: rriggs Date: 2013-08-29 20:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1de0fac9b962 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/ZonedDateTime.java Changeset: 356df1b99976 Author: rriggs Date: 2013-08-30 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/356df1b99976 8023763: Rename ChronoDateImpl Summary: Rename ChronoDateImpl to ChronoLocalDateImpl Reviewed-by: sherman Contributed-by: scolebourne at joda.org - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.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 Changeset: 5d73f7a2db51 Author: rriggs Date: 2013-09-04 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d73f7a2db51 8023762: Add ChronoPeriod interface and bind period to Chronology Summary: Make Period ISO-only, adding a Chronology-specific period concept Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoPeriod.java + src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/Temporal.java ! test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/chrono/TCKChronoPeriod.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: 79077f1641cc Author: rriggs Date: 2013-09-14 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79077f1641cc 8024835: Change until() to accept any compatible temporal Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! 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/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java Changeset: 14a187dc4ffe Author: rriggs Date: 2013-10-04 12:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14a187dc4ffe 8024999: Instant.Parse typo in example Summary: javadoc only fix to correct example to use "." and "Z" Reviewed-by: sherman ! src/share/classes/java/time/Instant.java Changeset: f9c701ba04e7 Author: rriggs Date: 2013-09-14 22:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9c701ba04e7 8024807: Add getChronlogy() to CLDT/CZDT Summary: Alternative to method is clunky and hard to find Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java Changeset: e12b912ab98e Author: rriggs Date: 2013-09-14 22:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e12b912ab98e 8024834: Better return type for TemporalField resolve Summary: Allow resolve method to return more than just ChronoLocalDate Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalField.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java From robert.field at oracle.com Fri Oct 4 16:55:18 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 04 Oct 2013 16:55:18 +0000 Subject: hg: jdk8/tl/jdk: 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Message-ID: <20131004165529.DFDB862D88@hg.openjdk.java.net> Changeset: 7736abdf0805 Author: rfield Date: 2013-10-04 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7736abdf0805 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Summary: remove DefaultMethodsTest from jdk/test/problemList.txt Reviewed-by: mduigou ! test/ProblemList.txt From peter.levart at gmail.com Fri Oct 4 16:56:26 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 04 Oct 2013 18:56:26 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524EC4A7.2070009@oracle.com> References: <524C30FA.1010209@oracle.com> <524C4A6A.4030105@oracle.com> <524C4E90.9030205@oracle.com> <524CFCFF.4030805@oracle.com> <4E412661-477A-4F6E-8078-B186BA346CC7@oracle.com> <524D65CF.3010209@oracle.com> <524E744A.9040802@gmail.com> <524EB7EE.6060801@gmail.com> <524EC4A7.2070009@oracle.com> Message-ID: <524EF33A.5010404@gmail.com> On 10/04/2013 03:37 PM, Aleksey Shipilev wrote: > Hi Peter, > > On 10/04/2013 04:43 PM, Peter Levart wrote: >> >http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.02/ > So you are taking on assisting the ReferenceHandler directly. Nice idea. Hi Aleksey, I will go over your notes in a later followup. This time I present an even more refined and simple approach: http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.03/ The trouble with previous approach was that while assisting ReferenceHandler thread and doing the cleaning synchronously "instead" of CleanerHandler thread (RQ.drain), the cleanersQueue was locked. If ReferenceHandler wanted to enqueue some Cleaner into cleanersQueue at that time, it would block and other Reference queueing would be impacted. So we're back to square-one when ReferenceHandler thread was processing Cleaners directly. Your approach doesn't have this problem. So I devised another variant where we are helping ReferenceHandler but not with enqueue-ing. We're stealing Cleaners from the pending list in batches instead of going through trouble of enqueue-ing them one by one just to be able to de-queue them afterwards in the same thread. In order to prevent CleanerHandler from interfering while synchronous assistance is in progress (I really want to know when there're no more pending Cleaners - or at least when almost all of them have been processed - this is when I give-up and let Bits throw OOME), the CleanerHandler is paused by interrupting it. Thread.sleep() can be inserted later between System.gc() and assistCleanup() if gc() happens to be asynchronous in some VM. The javadoc says the following: /Calling the //|gc|//method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects. / ...this appears as synchronous to me and it behaves so in HotSpot. I'm just guessing, but I think that gc() triggers safepoint processing and waits for safepoint to begin. It only returns when safepoint is done and VM has already processed all references. But I don't know if that is guaranteed in all VMs. Anyway, above variation is also predictable. I haven't been able to fail the test with any number of allocating threads. Let me now go over your notes and see what still applies to this version... Regards, Peter From joe.darcy at oracle.com Fri Oct 4 17:00:53 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 04 Oct 2013 17:00:53 +0000 Subject: hg: jdk8/tl/langtools: 8025913: Rename jdk.Supported to jdk.Exported Message-ID: <20131004170100.617D762D89@hg.openjdk.java.net> Changeset: 379c04c090cf Author: darcy Date: 2013-10-04 10:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/379c04c090cf 8025913: Rename jdk.Supported to jdk.Exported Reviewed-by: psandoz, forax, lancea, alanb, mchung, jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocSourcePositions.java ! src/share/classes/com/sun/source/util/DocTreePath.java ! src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java + src/share/classes/jdk/Exported.java - src/share/classes/jdk/Supported.java From mark.reinhold at oracle.com Fri Oct 4 17:30:43 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Oct 2013 10:30:43 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <524E638C.6090302@oracle.com> References: <524E638C.6090302@oracle.com> Message-ID: <20131004103043.409454@eggemoggin.niobe.net> 2013/10/3 16:43 -0700, joe.darcy at oracle.com: > Per previous discussions on the mailing list, we've decided to rename > the annotation type "jdk.Supported" to "jdk.Exported". > > ... Looks good to me. One question, though: Is it intended that one use of this annotation can be overridden by another at a deeper lexical level? For example: @Supported public class X { @Supported(false) public static class Y { } } Equivalently, imagine @Supported in a package-info.java file and @Supported(false) on a type within that package. If so then it'd be helpful to mention this possibility in the specification. - Mark From christian.thalinger at oracle.com Fri Oct 4 18:17:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 11:17:38 -0700 Subject: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector In-Reply-To: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> Message-ID: <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com> src/share/classes/java/lang/invoke/MethodHandles.java: You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.: + * If the filter method handle {@code coll} consumes one argument and produces + * a non-void result, then {@code collectArguments(mh, N, coll)} + * is equivalent to {@code filterArguments(mh, N, coll)}. Otherwise this looks good. On Sep 12, 2013, at 7:55 PM, John Rose wrote: > Please review this change for a change to the JSR 292 implementation: > > http://cr.openjdk.java.net/~jrose/8001110/webrev.00/ > > Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types > > The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs. > > Bug Description: Currently, a method handle can be transformed so that multiple arguments are collected and passed to the original method handle. However, the two routes to doing this are both limited to special purposes. > > (They are asCollector, which collects only trailing arguments, and only into an array; and foldArguments, which collects only leading arguments into filter function, and passes both the filtered result *and* the original arguments to the original.) > > MethodHandles.collectArguments(mh, pos, collector) should produce a method handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*) }, where the span of arguments b* is located by pos and the arity of the collector. > > There is internal machinery in any JSR 292 implementation to do this. It should be made available to users. > > This is a missing part of the JSR 292 spec. > > Thanks, > ? John > > P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev. > Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From huizhe.wang at oracle.com Fri Oct 4 18:28:25 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 04 Oct 2013 11:28:25 -0700 Subject: (jaxp) RFR - 8025745: Clarify API documentation of JAXP factories. In-Reply-To: <6690D6A9-9CCD-49AD-9336-02722E477399@oracle.com> References: <524E9228.5050608@oracle.com> <524EC390.50500@oracle.com> <524EE89C.6080603@oracle.com> <6690D6A9-9CCD-49AD-9336-02722E477399@oracle.com> Message-ID: <524F08C9.8010302@oracle.com> On 10/4/2013 9:36 AM, Paul Sandoz wrote: > On Oct 4, 2013, at 6:11 PM, Daniel Fuchs wrote: > >> On 10/4/13 3:33 PM, Alan Bateman wrote: >>> On 04/10/2013 03:02, Daniel Fuchs wrote: >>>> : >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.00/ >>> This mostly looks good, the only thing is that it reads "the >>> service-provider will use ..." but I think you mean "the >>> service-provider loading facility will use ..." >>> >>> -Alan. >> Right! Thanks for spotting that Alan. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8025745/webrev.01 >> > Looks good. > > It would be nice to factor out the repeating text to a link in package javadoc, but there does not appear to be any suitable shared location; stuff on java.xml might work but probably will look out of place. True. It might have been a good fit if we had a package such as javax.xml.jaxp for the core JAXP APIs, similar to javax.xml.ws that covers the core JAX-WS APIs. Joe > > Paul. From john.r.rose at oracle.com Fri Oct 4 18:34:53 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Oct 2013 11:34:53 -0700 Subject: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector In-Reply-To: <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com> References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com> Message-ID: <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param also. ? John On Oct 4, 2013, at 11:17 AM, Christian Thalinger wrote: > You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.: > > + * If the filter method handle {@code coll} consumes one argument and produces > + * a non-void result, then {@code collectArguments(mh, N, coll)} > + * is equivalent to {@code filterArguments(mh, N, coll)}. From mark.reinhold at oracle.com Fri Oct 4 18:39:35 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Oct 2013 11:39:35 -0700 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <524CFCFF.4030805@oracle.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> Message-ID: <20131004113935.633938@eggemoggin.niobe.net> 2013/10/2 15:13 -0700, alan.bateman at oracle.com: > BTW: Is this important enough to attempt to do this late in 8? I just > wonder about a significant change like switching to weak references and > whether it would be more sensible to hold it back to do early in 9. I share your concern. This is extraordinarily sensitive code. Now is not the time to rewrite it for JDK 8. - Mark From daniel.fuchs at oracle.com Fri Oct 4 18:41:28 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 04 Oct 2013 18:41:28 +0000 Subject: hg: jdk8/tl/jaxp: 8025745: Clarify API documentation of JAXP factories. Message-ID: <20131004184134.9F52C62D8E@hg.openjdk.java.net> Changeset: f031b2fe21cd Author: dfuchs Date: 2013-10-04 19:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f031b2fe21cd 8025745: Clarify API documentation of JAXP factories. Summary: Clarifies usage of ServiceLoader in JAXP factories. Reviewed-by: alanb, joehw, psandoz ! src/javax/xml/datatype/DatatypeFactory.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/SAXParserFactory.java ! src/javax/xml/stream/XMLEventFactory.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/stream/XMLOutputFactory.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java ! src/javax/xml/xpath/XPathFactory.java From roger.riggs at oracle.com Fri Oct 4 19:37:19 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 04 Oct 2013 15:37:19 -0400 Subject: RFR: improved exception messages in java.time 8025718 Message-ID: <524F18EF.7020808@oracle.com> Hi, Please review these small improvements in messages resulting from parsing date and time errors and corresponding tests. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-better-msg-8025718/ JBS: https://bugs.openjdk.java.net/browse/JDK-8025718 Thanks, Roger From bhavesh.x.patel at oracle.com Fri Oct 4 20:32:59 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 20:32:59 +0000 Subject: hg: jdk8/tl/langtools: 8008164: Invisible table captions in javadoc-generated html Message-ID: <20131004203309.BA4EA62D95@hg.openjdk.java.net> Changeset: 6e186ca11ec0 Author: bpatel Date: 2013-10-04 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e186ca11ec0 8008164: Invisible table captions in javadoc-generated html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testHtmlTableStyles/TestHtmlTableStyles.java + test/com/sun/javadoc/testHtmlTableStyles/pkg1/TestTable.java + test/com/sun/javadoc/testHtmlTableStyles/pkg2/TestUse.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java From bhavesh.x.patel at oracle.com Fri Oct 4 20:41:46 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 20:41:46 +0000 Subject: hg: jdk8/tl/langtools: 8024756: method grouping tabs are not selectable Message-ID: <20131004204149.F270A62D96@hg.openjdk.java.net> Changeset: 3344ea7404b1 Author: bpatel Date: 2013-10-04 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3344ea7404b1 8024756: method grouping tabs are not selectable Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java From brian.burkhalter at oracle.com Fri Oct 4 20:58:12 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 4 Oct 2013 13:58:12 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> Message-ID: <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: > On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: > >> On 03/10/2013 16:10, Brian Burkhalter wrote: >>> Please review and comment at your convenience. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ An updated webrev which I hope adequately addresses the expressed concerns may be found at: http://cr.openjdk.java.net/~bpb/7179567.2/ > >> Will you be adding tests for these cases to the webrev? > > As needed once the concept in general is accepted. The foregoing webrev includes a test of the affected public methods. Thanks, Brian From jonathan.gibbons at oracle.com Fri Oct 4 21:00:16 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 21:00:16 +0000 Subject: hg: jdk8/tl/langtools: 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Message-ID: <20131004210020.038FF62D97@hg.openjdk.java.net> Changeset: 2fa6ced325cc Author: jjg Date: 2013-10-04 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2fa6ced325cc 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/errors/TestBadProcessor.java From john.r.rose at oracle.com Fri Oct 4 21:40:46 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Oct 2013 14:40:46 -0700 Subject: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector In-Reply-To: <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com> References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com> <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com> Message-ID: Actually it's OK: The name "coll" is defined a couple lines up by the "A collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term "filter" is persistently applied to it. So I think it is intelligible as posted. ? John On Oct 4, 2013, at 11:34 AM, John Rose wrote: > Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param also. ? John > > On Oct 4, 2013, at 11:17 AM, Christian Thalinger wrote: > >> You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.: >> >> + * If the filter method handle {@code coll} consumes one argument and produces >> + * a non-void result, then {@code collectArguments(mh, N, coll)} >> + * is equivalent to {@code filterArguments(mh, N, coll)}. > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From jonathan.gibbons at oracle.com Fri Oct 4 21:47:36 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 21:47:36 +0000 Subject: hg: jdk8/tl/langtools: 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Message-ID: <20131004214739.29BA162D99@hg.openjdk.java.net> Changeset: 515d54c1b063 Author: jjg Date: 2013-10-04 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/515d54c1b063 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/javax/tools/Diagnostic.java From christian.thalinger at oracle.com Fri Oct 4 21:53:27 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 14:53:27 -0700 Subject: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector In-Reply-To: References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com> <6E7049C7-4D88-41D1-BDE4-1B196D95CF67@oracle.com> <26A418FC-AE86-416D-86CC-F9C95BFFB8CF@oracle.com> Message-ID: <498B0E56-0DD9-4B4B-9A0C-6D877421E8C2@oracle.com> On Oct 4, 2013, at 2:40 PM, John Rose wrote: > Actually it's OK: The name "coll" is defined a couple lines up by the "A collection adapter {@code collectArguments(mh, 0, coll)} ...", and the term "filter" is persistently applied to it. So I think it is intelligible as posted. ? John I'm fine with that. > > On Oct 4, 2013, at 11:34 AM, John Rose wrote: > >> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param also. ? John >> >> On Oct 4, 2013, at 11:17 AM, Christian Thalinger wrote: >> >>> You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.: >>> >>> + * If the filter method handle {@code coll} consumes one argument and produces >>> + * a non-void result, then {@code collectArguments(mh, N, coll)} >>> + * is equivalent to {@code filterArguments(mh, N, coll)}. >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From jonathan.gibbons at oracle.com Fri Oct 4 22:25:52 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 22:25:52 +0000 Subject: hg: jdk8/tl/langtools: 8025970: Spurious characters in JavaCompiler Message-ID: <20131004222556.7299862D9B@hg.openjdk.java.net> Changeset: 3e3c321710be Author: jjg Date: 2013-10-04 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3e3c321710be 8025970: Spurious characters in JavaCompiler Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From bhavesh.x.patel at oracle.com Fri Oct 4 22:37:32 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 22:37:32 +0000 Subject: hg: jdk8/tl: 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Message-ID: <20131004223732.E1E0562D9C@hg.openjdk.java.net> Changeset: 6b8f5030e5ad Author: bpatel Date: 2013-10-04 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b8f5030e5ad 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk From bhavesh.x.patel at oracle.com Fri Oct 4 22:38:54 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 22:38:54 +0000 Subject: hg: jdk8/tl/jdk: 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Message-ID: <20131004223906.38C9362D9D@hg.openjdk.java.net> Changeset: 66181f7991bd Author: bpatel Date: 2013-10-04 15:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66181f7991bd 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! make/docs/Makefile From henry.jen at oracle.com Fri Oct 4 23:13:55 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 04 Oct 2013 16:13:55 -0700 Subject: RFR: 8025968: Integrate test improvements made in lambda repo Message-ID: <524F4BB3.40509@oracle.com> Hi, Please review a port from lambda repo to tl, it contains a refactoring of OpTestCase and a small addition to fill test gap. http://cr.openjdk.java.net/~henryjen/tl/8025968/0/webrev/ Cheers, Henry From kumar.x.srinivasan at oracle.com Fri Oct 4 23:16:11 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 04 Oct 2013 23:16:11 +0000 Subject: hg: jdk8/tl/langtools: 8003537: javap use internal class name when printing bound of type variable Message-ID: <20131004231614.DD5DE62D9E@hg.openjdk.java.net> Changeset: bb87db832b31 Author: ksrini Date: 2013-10-04 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb87db832b31 8003537: javap use internal class name when printing bound of type variable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/BoundsTypeVariableTest.java From joe.darcy at oracle.com Fri Oct 4 23:48:10 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 04 Oct 2013 16:48:10 -0700 Subject: Question about JDK-8023087 In-Reply-To: <524A40B7.8050201@oracle.com> References: <1207DFC8-AA5B-4A05-BD92-E69D16E8A923@oracle.com> <419997E8-9FB7-43DF-8C35-619D10A90210@oracle.com> <523B309A.2070606@oracle.com> <55D8369D-EF20-4F39-8089-7BC5BD84C203@oracle.com> <915ED0A1-393D-4EAC-96F8-23DA8FAE57A8@oracle.com> <524A35EA.60101@oracle.com> <524A40B7.8050201@oracle.com> Message-ID: <524F53BA.9000602@oracle.com> Enum constructors (as compiled by javac) have synthetic parameters; constructors of nested classes [1] can have either implicit or synthetic parameters. HTH, -Joe [1] https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top On 9/30/2013 8:25 PM, Eric Wang wrote: > Including the corelibs-dev team, so someone may help me. > > Thanks, > Eric > On 2013/10/1 10:39, Eric Wang wrote: >> Hi Alan, >> >> I'm looking at the bug >> https://bugs.openjdk.java.net/browse/JDK-8023087 which is filed for >> CCC changes https://bugs.openjdk.java.net/browse/JDK-8007405. >> >> There're 2 simple APIs isImplicit() and isSynthetic() changed in >> java.lang.reflect.Parameter, which are not covered by a test. >> >> However, based on the API desciptions below, I have no idea how to >> test them as I can't find such case, Can you please give some >> suggestion or some examples? >> >> /** >> * Returns true if this parameter is implicitly declared in source >> code; returns ode false otherwise. >> * >> * @return true if and only if this parameter is implicitly declared >> as defined by The Java Language Specification. >> */ >> public boolean isImplicit() {return >> Modifier.isMandated(getModifiers());} >> >> /** >> * Returns true if this parameter is neither implicitly nor >> explicitly declared in source code; returns false otherwise. >> * >> * @jls 13.1 The Form of a Binary >> * @return true if and only if this parameter is a synthetic >> construct as defined by The Java Language Specification. >> */ >> public boolean isSynthetic() {return >> Modifier.isSynthetic(getModifiers());} >> >> Thanks, >> Eric >> On 2013/10/1 9:05, Michel Trudeau wrote: >>> Eric, >>> >>> Any update on this bug ? We really need to close this down as soon >>> as possible. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8023087 >>> >>> Thanks, >>> Michel >>> >>> On Sep 19, 2013, at 10:18 AM, Michel Trudeau >>> wrote: >>> >>> Hopefully the right Eric this time around. >>> >>> Michel >>> >>> On Sep 19, 2013, at 10:12 AM, eric wang wrote: >>> >>> wrong Eric Wang I assume. >>> >>> Eric >>> On 9/19/2013 8:58 AM, Michel Trudeau wrote: >>>> Eric, >>>> >>>> Any update on this ? We really need to get those tests in ASAP. >>>> >>>> Thanks, >>>> Michel >>>> >>>> On Sep 12, 2013, at 10:40 AM, Michel Trudeau >>>> wrote: >>>> >>>> Eric, >>>> >>>> This bug got assigned to you yesterday. Not sure if this is >>>> really a P4, sounds like a P3 since we need those tests. >>>> >>>> Is this a top priority for you ? I would really like to get this >>>> done sooner than later. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8023087 >>>> >>>> Thanks, >>>> Michel >>>> >>>> >>> >>> >> > From kumar.x.srinivasan at oracle.com Fri Oct 4 23:45:49 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 04 Oct 2013 23:45:49 +0000 Subject: hg: jdk8/tl/langtools: 8005542: jtreg test OverrideBridge.java contains @ignore Message-ID: <20131004234552.5B5A562DA0@hg.openjdk.java.net> Changeset: 15651a673358 Author: ksrini Date: 2013-10-04 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/15651a673358 8005542: jtreg test OverrideBridge.java contains @ignore Reviewed-by: jjg Contributed-by: steve.sides at oracle.com - test/tools/javac/generics/OverrideBridge.java From cowwoc at bbs.darktech.org Sat Oct 5 02:30:37 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 04 Oct 2013 22:30:37 -0400 Subject: EnumSet and reification Message-ID: <524F79CD.6060905@bbs.darktech.org> Hi, Out of curiosity, is JDK 8's type reification improved enough so that we can replace > EnumSet EnumSet.noneOf(Class) with > EnumSet EnumSet.noneOf() and the JDK will figure out the value of E based on the expected return type? If so, can we make this API change? Thanks, Gili From chris.hegarty at oracle.com Sat Oct 5 08:05:56 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Oct 2013 08:05:56 +0000 Subject: hg: jdk8/tl/jdk: 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Message-ID: <20131005080617.2118262DBA@hg.openjdk.java.net> Changeset: 7d2112abbb1d Author: coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d2112abbb1d 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar/TestService.java + test/javax/xml/ws/clientjar/TestWsImport.java From chris.hegarty at oracle.com Sat Oct 5 07:57:24 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Oct 2013 07:57:24 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20131005075733.5131162DB7@hg.openjdk.java.net> Changeset: b0610cd08440 Author: mkos Date: 2013-10-04 16:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0610cd08440 8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035 Reviewed-by: chegar ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64EncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/binary/SchemaBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DDataPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DXMLPrinter.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DataPatternBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/GrammarBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/AnyNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/NameClassBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/SimpleNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/compact/UCode_UCodeESC_CharStream.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/xml/SchemaParser.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/xml/sax/JAXPXMLReaderCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLInput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLMessage.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLModel.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOutput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPart.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPort.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/javax/annotation/PostConstruct.java ! src/share/jaxws_classes/javax/annotation/PreDestroy.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/Marshaller.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java Changeset: e56be3a2287a Author: coffeys Date: 2013-10-05 08:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e56be3a2287a 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java From forax at univ-mlv.fr Sat Oct 5 11:15:52 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 05 Oct 2013 13:15:52 +0200 Subject: EnumSet and reification In-Reply-To: <524F79CD.6060905@bbs.darktech.org> References: <524F79CD.6060905@bbs.darktech.org> Message-ID: <524FF4E8.3040803@univ-mlv.fr> On 10/05/2013 04:30 AM, cowwoc wrote: > Hi, > > Out of curiosity, is JDK 8's type reification improved enough so > that we can replace > > > EnumSet EnumSet.noneOf(Class) > > with > > > EnumSet EnumSet.noneOf() > > and the JDK will figure out the value of E based on the expected > return type? If so, can we make this API change? > > Thanks, > Gili No, generics are not reified in Java 8 ... but lambda are reified, at least a kind of. You can not access to the type argument but the reified signature of the lambda need to be known at runtime, this is a side effect of the fact that lambda proxies are generated at runtime. R?mi From forax at univ-mlv.fr Sat Oct 5 11:49:48 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 05 Oct 2013 13:49:48 +0200 Subject: Lambda proxy class doesn't carry generics information Message-ID: <524FFCDC.9090006@univ-mlv.fr> David Gageot [1] talk to me about this issue after my presentation at ParisJUG and I totally forgot to report it. He said that he is using a framework that uses the generic information inserted by javac (and available by reflection) so he can not retrofit its code that uses inner classes to use lambdas because the generated lambda proxy doesn't carry this information. Here is a small test to see the issue: public static void main(String[] args) { Comparator c = new Comparator() { @Override public int compare(String s1, String s2) { return s1.compareTo(s2); } }; Comparator c2 = (s1, s2) -> s1.compareTo(s2); System.out.println(Arrays.toString(c.getClass().getGenericInterfaces())); // [java.util.Comparator] System.out.println(Arrays.toString(c2.getClass().getGenericInterfaces())); // [interface java.util.Comparator] } I said to him that it was not a bug, but it's less clear to me now :( cheers, R?mi From john.r.rose at oracle.com Sat Oct 5 12:31:44 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 05 Oct 2013 12:31:44 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20131005123417.A921962DBB@hg.openjdk.java.net> Changeset: 44da760eed4b Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44da760eed4b 8024761: JSR 292 improve performance of generic invocation Summary: use a per-MH one element cache for MH.asType to speed up MH.invoke; also cache enough MH constants to cache LMF.metafactory Reviewed-by: twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/InvokeGeneric.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/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java Changeset: 97d5cc1e7586 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97d5cc1e7586 8001105: findVirtual of Object[].clone produces internal error Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 91535ade7349 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91535ade7349 8019417: JSR 292 javadoc should clarify method handle arity limits Summary: clarification of erroneous reading of spec. that led to 7194534 Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/BigArityTest.java Changeset: d391e062b983 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d391e062b983 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException Summary: Document error conditions that may occur when calling a "spreader" method handle. Use IAE in all cases. Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: acdf5bf1a918 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acdf5bf1a918 8001108: an attempt to use "" as a method name should elicit NoSuchMethodException Summary: add an explicit check for leading "<", upgrade the unit tests Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: df6236da299d Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df6236da299d 8024599: JSR 292 direct method handles need to respect initialization rules for static members Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding invocation. Reviewed-by: twisti, darcy, abuckley, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/CallStaticInitOrder.java Changeset: eb3cfc69c16e Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb3cfc69c16e 8001110: method handles should have a collectArguments transform, generalizing asCollector Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: b670477bff8f Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b670477bff8f 8025112: JSR 292 spec updates for security manager and caller sensitivity Summary: align CONSTANT_MethodHandle and Lookup.find* API calls, clarify security manager & @CallerSensitive interactions Reviewed-by: mchung, twisti ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/TestPrivateMember.java Changeset: 6623c675e734 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6623c675e734 8024438: JSR 292 API specification maintenance for JDK 8 Summary: add wildcard to unreflectConstructor, various clarifications and minor edits Reviewed-by: mchung, darcy, twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RevealDirectTest.java From kustos at gmx.net Sat Oct 5 18:39:44 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sat, 05 Oct 2013 20:39:44 +0200 Subject: Possible HashSet memory improvement Message-ID: <52505CF0.4060703@gmx.net> Hi I attended Nathan Reynolds Java Memory Hogs [CON4695] talk where he talked about about memory waste in Java collections and attempts in 7u40 and later to improve the situation. One thing he mentioned was that there is a patch floating around that makes HashSet no longer use HashMap. This would allow us to remove the "value" instance variable in a table entry. My limited understanding of object layout and padding leads me to believe that this would not improve the memory consumption of HashSet right now because the table entries would still get padded to the original size. We would somehow need to save another word. Then I remembered something else he said, some instance variables of some objects are almost always null. Well the "next" instance variable of the table entry should be null most of the time (unless we have a collision). If we make different classes for the last entry and the other entries in a collision chain we can reduce for entry size from 6 to 4 words (if my understanding and calculations are correct) in most cases. This could in theory reduce HashSet memory consumption by up to 28% (with no collisions at all and 100% load factor). Is there something I missed? Is this something that has been considered? Cheers Philippe From brian.goetz at oracle.com Sat Oct 5 19:57:16 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 5 Oct 2013 20:57:16 +0100 Subject: Possible HashSet memory improvement In-Reply-To: <52505CF0.4060703@gmx.net> References: <52505CF0.4060703@gmx.net> Message-ID: > Is there something I missed? Is this something that has been considered? If memory efficiency were the only metric in the world, this would be a no-brainer. But, by having different classes for different nodes, many many paths where the VM could prove monomorphism and thereby inline through now become polymorphic and at best could be inline cached. So yes -- this would be a tradeoff of memory footprint for data access costs. From peter.levart at gmail.com Sun Oct 6 11:19:37 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 06 Oct 2013 13:19:37 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <20131004113935.633938@eggemoggin.niobe.net> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> Message-ID: <52514749.6050903@gmail.com> Hi, I agree the problem with de-allocation of native memory blocks should be studied deeply and this takes time. What I have observed so far on Linux platform (other platforms may behave differently) is the following: Deallocation of native memory with Unsafe.freeMemory(address) can take various amounts of time. It can grow to a constant amount of several milliseconds to free a 1MB block, for example, when there's already lots of blocks allocated and multiple threads are constantly allocating more. I'm not sure yet about the main reasons for that, but it could either be a contention with allocation from multiple threads, interaction with GC, or even the algorithm used in the native allocator. Deallocation is also not very parallelizable. My observation is that deallocating with 2 threads (on a 4 core CPU) does not help much. Current scheme of deallocating in ReferenceHandler thread means that a lot of "pending" Cleaner objects can accumulate and although VM has promptly processed Cleaner PhantomReferences (hooked them on the pending list), a lot of work is still to be done to actually free the native blocks. This clogs ReferenceHandler thread and affects other Reference processing. It also presents difficulties for back-off strategy for allocating native memory. The strategy has no information that would be needed to decide whether to wait more or to fail with OOME. I'm currently experimenting with approach where Cleaner and ReferenceHandler code stays as is, but the Cheaner's thunk (the Deallocator in DirectByteBuffer) is modified so that it performs some actions synchronously (announcing what will be de-allocated) and delegates the actual deallocation and unreservation to a background thread. Reservation strategy has more information to base it's back-off strategy that way. I'll let you know if I get some results from that. Regards, Peter On 10/04/2013 08:39 PM, mark.reinhold at oracle.com wrote: > 2013/10/2 15:13 -0700, alan.bateman at oracle.com: >> BTW: Is this important enough to attempt to do this late in 8? I just >> wonder about a significant change like switching to weak references and >> whether it would be more sensible to hold it back to do early in 9. > I share your concern. This is extraordinarily sensitive code. > Now is not the time to rewrite it for JDK 8. > > - Mark From kustos at gmx.net Sun Oct 6 18:09:23 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 06 Oct 2013 20:09:23 +0200 Subject: Possible HashSet memory improvement In-Reply-To: References: <52505CF0.4060703@gmx.net> Message-ID: <5251A753.2020109@gmx.net> On 05.10.2013 21:57, Brian Goetz wrote: >> Is there something I missed? Is this something that has been considered? > > If memory efficiency were the only metric in the world, this would be a no-brainer. But, by having different classes for different nodes, many many paths where the VM could prove monomorphism and thereby inline through now become polymorphic and at best could be inline cached. > > ... > Doesn't the rb-tree collision handling in HashMap already introduce different classes for different nodes (Node and TreeNode)? Or is the assumption there that this doesn't happen in production and therefore does not introduce polymorphism? Cheers Philippe From forax at univ-mlv.fr Sun Oct 6 18:18:13 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 06 Oct 2013 20:18:13 +0200 Subject: Possible HashSet memory improvement In-Reply-To: <5251A753.2020109@gmx.net> References: <52505CF0.4060703@gmx.net> <5251A753.2020109@gmx.net> Message-ID: <5251A965.7040402@univ-mlv.fr> On 10/06/2013 08:09 PM, Philippe Marschall wrote: > > > On 05.10.2013 21:57, Brian Goetz wrote: >>> Is there something I missed? Is this something that has been >>> considered? >> >> If memory efficiency were the only metric in the world, this would be >> a no-brainer. But, by having different classes for different nodes, >> many many paths where the VM could prove monomorphism and thereby >> inline through now become polymorphic and at best could be inline >> cached. >> >> ... >> > > Doesn't the rb-tree collision handling in HashMap already introduce > different classes for different nodes (Node and TreeNode)? Or is the > assumption there that this doesn't happen in production and therefore > does not introduce polymorphism? The actual code carefully introduces polymorphism only if there is an abnormal number of collisions, either because a method hashCode() is badly written or someone tries to DDOS the HashMap. > > Cheers > Philippe cheers, R?mi From Alan.Bateman at oracle.com Sun Oct 6 20:03:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 06 Oct 2013 21:03:34 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs Message-ID: <5251C216.105@oracle.com> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, I'd like to have another attempt at adding the annotation to a number of JDK specific APIs that are long standing exported, documented and supported APIs. Specifically, the following APIs: - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JConsole Plugin API (com.sun.tools.jconsole) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) (The javadoc for each of these APIs is currently generated in the build) The webrev with the proposed update is here: http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ As per the original webrev, I've added package-info.java to a number of packages that didn't have any description. In a few cases, I've had to rename the legacy package.html to package-info.java. For the review then the intention is that @jdk.Exported be added to the package-info and all public/protected types in these APIs. The only exceptions are two cases where I've added @jdk.Exported(false), specifically: - com.sun.management.OSMBeanFactory as it clearly documents to stay away - com.sun.security.auth.callback.DialogCallbackHandler as it for the chop (see JEP 162) Thanks, Alan. From peter.levart at gmail.com Sun Oct 6 22:56:13 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 07 Oct 2013 00:56:13 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <52514749.6050903@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> Message-ID: <5251EA8D.60507@gmail.com> Hi Again, The result of my experimentation is as follows: Letting ReferenceHandler thread alone to en-queue References and execute Cleaners is not enough to prevent OOMEs when allocation is performed in large number of threads even if I let Cleaners do only synchronous announcing of what will be freed (very fast), delegate the actual de-allocation to a background thread and base reservation waiting on announced free space (still wait that space is deallocated and unreserved before satisfying reservation request, but wait as long as it takes if the announced free space is enough for reservation request). ReferenceHandler thread, when it finds that it has no more pending References, parks and waits for notification from VM. The VM promptly process references (hooks them on the pending list), but with saturated CPUs, waking-up the ReferenceHandler thread and re-gaining the lock takes too much time. During that time allocating threads can reserve the whole permitted space and OOME must be thrown. So I'm back to strategy #1 - helping ReferenceHandler thread. It's not so much about helping to achieve better throughput (as I noted deallocating can not be effectively parallelized) but to overcome the latency of waking-up the ReferenceHandler thread. Here's my attempt at doing this: http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ This is much simplified from my 1st submission of similar strategy. I tried to be as undisruptive to current logic of Reference processing as possible, but of course you decide if this is still too risky for inclusion into JDK8. Cleaner is unchanged - it processes it's thunk synchronously and ReferenceHandler thread invokes it directly. ReferenceHandler logic is the same - I just factored-out the content of the loop into a private method to be able to call it from nio Bits where the bulk of change lies. The (un)reservation logic is re-implemented with atomic operations - no locks. When large number of threads are competing for reservation, locking overhead can be huge and can slow-down unreservation (which must use the same lock as reservation). The reservation re-try logic 1st tries to satisfy the reservation request while helping ReferenceHandler thread in en-queue-ing References and executing Cleaners until the list of pending references is exhausted. If this does not succeed, it triggers VM to process references (System.gc()) and then enters similar re-try loop but introducing exponentially increasing back-off delay every time the chain of pending references is exhausted, starting with 1ms sleep and doubling. This gives VM time to process the references. Maximum number of sleeps is 9, giving max. accumulated sleep time of 0.5 s. This means that a request that rightfully throws OOME will do so after 0.5 s sleep. I did the following measurement: Using LongAdders (to avoid Heisenberg) I counted various exit paths from Bits.reserveMemory() during a test that spawned 128 allocating threads on a 4-core i7 machine, allocating direct buffers randomly sized between 256KB and 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: Total of 909960 allocations were performed: - 247993 were satisfied before attempting to help ReferenceHandler thread - 660184 were satisfied while helping ReferenceHandler thread but before triggering System.gc() - 1783 were satisfied after triggering System.gc() but before doing any sleep - no sleeping has been performed The same test, just changing -XX:MaxDirectMemorySize=128m (that means 1MB per thread each allocating direct buffers randomly sized between 256KB and 1MB): Total of 579943 allocations were performed: - 131547 were satisfied before attempting to help ReferenceHandler thread - 438345 were satisfied while helping ReferenceHandler thread but before triggering System.gc() - 10016 were satisfied after triggering System.gc() but before doing any sleep - 34 were satisfied after sleep(1) - 1 was satisfied after sleep(1) followed by sleep(2) That's it. I think this is good enough for testing on large scale. I have also included a modified DirectBufferAllocTest as a unit test, but I don't know if it's suitable since it takes 60s to run. The run time could be lowered with less probability to catch OOMEs. So what do you think? Is this still too risky for JDK8? Regards, Peter On 10/06/2013 01:19 PM, Peter Levart wrote: > Hi, > > I agree the problem with de-allocation of native memory blocks should > be studied deeply and this takes time. > > What I have observed so far on Linux platform (other platforms may > behave differently) is the following: > > Deallocation of native memory with Unsafe.freeMemory(address) can take > various amounts of time. It can grow to a constant amount of several > milliseconds to free a 1MB block, for example, when there's already > lots of blocks allocated and multiple threads are constantly > allocating more. I'm not sure yet about the main reasons for that, but > it could either be a contention with allocation from multiple threads, > interaction with GC, or even the algorithm used in the native > allocator. Deallocation is also not very parallelizable. My > observation is that deallocating with 2 threads (on a 4 core CPU) does > not help much. > > Current scheme of deallocating in ReferenceHandler thread means that a > lot of "pending" Cleaner objects can accumulate and although VM has > promptly processed Cleaner PhantomReferences (hooked them on the > pending list), a lot of work is still to be done to actually free the > native blocks. This clogs ReferenceHandler thread and affects other > Reference processing. It also presents difficulties for back-off > strategy for allocating native memory. The strategy has no information > that would be needed to decide whether to wait more or to fail with OOME. > > I'm currently experimenting with approach where Cleaner and > ReferenceHandler code stays as is, but the Cheaner's thunk (the > Deallocator in DirectByteBuffer) is modified so that it performs some > actions synchronously (announcing what will be de-allocated) and > delegates the actual deallocation and unreservation to a background > thread. Reservation strategy has more information to base it's > back-off strategy that way. I'll let you know if I get some results > from that. > > Regards, Peter > > On 10/04/2013 08:39 PM, mark.reinhold at oracle.com wrote: >> 2013/10/2 15:13 -0700,alan.bateman at oracle.com: >>> BTW: Is this important enough to attempt to do this late in 8? I just >>> wonder about a significant change like switching to weak references and >>> whether it would be more sensible to hold it back to do early in 9. >> I share your concern. This is extraordinarily sensitive code. >> Now is not the time to rewrite it for JDK 8. >> >> - Mark > From chris.hegarty at oracle.com Mon Oct 7 08:23:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 07 Oct 2013 09:23:08 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52526F6C.8020202@oracle.com> Alan, I checked the httpsever and sctp changes. All look good to me. -Chris. On 10/06/2013 09:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From mandy.chung at oracle.com Mon Oct 7 08:24:34 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 01:24:34 -0700 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) Message-ID: <52526FC2.60409@oracle.com> JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy From vincent.x.ryan at oracle.com Mon Oct 7 08:33:06 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 7 Oct 2013 09:33:06 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <52526F6C.8020202@oracle.com> References: <5251C216.105@oracle.com> <52526F6C.8020202@oracle.com> Message-ID: The JAAS and JGSS changes look fine too. On 7 Oct 2013, at 09:23, Chris Hegarty wrote: > Alan, > > I checked the httpsever and sctp changes. All look good to me. > > -Chris. > > On 10/06/2013 09:03 PM, Alan Bateman wrote: >> >> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, >> I'd like to have another attempt at adding the annotation to a number of >> JDK specific APIs that are long standing exported, documented and >> supported APIs. Specifically, the following APIs: >> >> - Java Debug Interface (com.sun.jdi) >> - Attach API (com.sun.tools.attach) >> - SCTP API (com.sun.nio.sctp) >> - HTTP server API (com.sun.net.httpserver) >> - Management extensions (com.sun.management) >> - JConsole Plugin API (com.sun.tools.jconsole) >> - JDK-specific API to JAAS (com.sun.security.auth) >> - JDK-specific JGSS API (com.sun.security.jgss) >> >> (The javadoc for each of these APIs is currently generated in the build) >> >> The webrev with the proposed update is here: >> http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ >> >> As per the original webrev, I've added package-info.java to a number of >> packages that didn't have any description. In a few cases, I've had to >> rename the legacy package.html to package-info.java. >> >> For the review then the intention is that @jdk.Exported be added to the >> package-info and all public/protected types in these APIs. The only >> exceptions are two cases where I've added @jdk.Exported(false), >> specifically: >> >> - com.sun.management.OSMBeanFactory as it clearly documents to stay away >> - com.sun.security.auth.callback.DialogCallbackHandler as it for the >> chop (see JEP 162) >> >> Thanks, >> >> Alan. From forax at univ-mlv.fr Mon Oct 7 08:29:08 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 07 Oct 2013 10:29:08 +0200 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52526FC2.60409@oracle.com> References: <52526FC2.60409@oracle.com> Message-ID: <525270D4.2010007@univ-mlv.fr> On 10/07/2013 10:24 AM, Mandy Chung wrote: > JDK 8 was feature complete in June and there just isn't sufficient > time remaining to get agreement and feedback on an API to examine the > caller frames. To that end, I propose to restore the old unsupported > Reflection.getCallerClass(int) and that we will look to define a > standard API for JDK 9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ > > It remains to be an unsupported API and JDK should not use this method > and it's not annotated with @CallerSensitive. I considered detecting > if this method is called by a system class (loaded by null loader) and > throw an error. I decided to minimize the compatibility risk in case > if there is any existing code added to the bootclasspath depending on > this private API. > > Thanks > Mandy The Java side is Ok for me. cheers, R?mi From paul.sandoz at oracle.com Mon Oct 7 09:28:38 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Oct 2013 11:28:38 +0200 Subject: RFR: 8025968: Integrate test improvements made in lambda repo In-Reply-To: <524F4BB3.40509@oracle.com> References: <524F4BB3.40509@oracle.com> Message-ID: <17ECAC41-43D2-4874-871A-426C08F6E5F8@oracle.com> On Oct 5, 2013, at 1:13 AM, Henry Jen wrote: > Hi, > > Please review a port from lambda repo to tl, it contains a refactoring > of OpTestCase and a small addition to fill test gap. > > http://cr.openjdk.java.net/~henryjen/tl/8025968/0/webrev/ > Looks good. Paul. From daniel.fuchs at oracle.com Mon Oct 7 09:44:04 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 07 Oct 2013 11:44:04 +0200 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52528264.4040205@oracle.com> Hi Alan, The com.sun.management changes look good. -- daniel On 10/6/13 10:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From mandy.chung at oracle.com Mon Oct 7 10:31:08 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 03:31:08 -0700 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52528D6C.5000705@oracle.com> On 10/6/2013 1:03 PM, Alan Bateman wrote: > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > I went through the entire webrev and the change looks good. > > For the review then the intention is that @jdk.Exported be added to > the package-info and all public/protected types in these APIs. The > only exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away It's a bug. We should fix it and remove this public class (I have filed JDK-8025985 for it). > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) Good and this will be gone in jdk9. Mandy From Alan.Bateman at oracle.com Mon Oct 7 10:49:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 11:49:16 +0100 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52526FC2.60409@oracle.com> References: <52526FC2.60409@oracle.com> Message-ID: <525291AC.7030009@oracle.com> On 07/10/2013 09:24, Mandy Chung wrote: > JDK 8 was feature complete in June and there just isn't sufficient > time remaining to get agreement and feedback on an API to examine the > caller frames. To that end, I propose to restore the old unsupported > Reflection.getCallerClass(int) and that we will look to define a > standard API for JDK 9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ > > It remains to be an unsupported API and JDK should not use this method > and it's not annotated with @CallerSensitive. I considered detecting > if this method is called by a system class (loaded by null loader) and > throw an error. I decided to minimize the compatibility risk in case > if there is any existing code added to the bootclasspath depending on > this private API. I liked the direction this was going with the walkStack and firstCaller proposal but it is way too late in jdk8 to have any time to get feedback. So I agree that temporarily restoring the unsupported Reflection.getCallerClass(int) is the right thing for now. As the standard API is likely to be significant then it probably warrants a JEP. As regards the webrev then the changes looks okay. I guess you could rename one of the native methods to avoid the non-obvious name mangling but since it is only temporary then I could live with what you have. -Alan From alan.bateman at oracle.com Mon Oct 7 10:51:55 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Oct 2013 10:51:55 +0000 Subject: hg: jdk8/tl/jdk: 8025983: Typo in Javadoc of Files.isRegularFile() Message-ID: <20131007105234.A1F8362DF3@hg.openjdk.java.net> Changeset: 0ac9dc315071 Author: alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java From Alan.Bateman at oracle.com Mon Oct 7 10:56:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 11:56:26 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <52528D6C.5000705@oracle.com> References: <5251C216.105@oracle.com> <52528D6C.5000705@oracle.com> Message-ID: <5252935A.8070005@oracle.com> On 07/10/2013 11:31, Mandy Chung wrote: > : > >> >> For the review then the intention is that @jdk.Exported be added to >> the package-info and all public/protected types in these APIs. The >> only exceptions are two cases where I've added @jdk.Exported(false), >> specifically: >> >> - com.sun.management.OSMBeanFactory as it clearly documents to stay away > > It's a bug. We should fix it and remove this public class (I have > filed JDK-8025985 for it). Thanks for creating the bug, I agree it should be removed. For now, I'll leave @jdk.Exported(false), unless that issue is resolved before we push this (I hope that is okay with you). -Alan. From peter.levart at gmail.com Mon Oct 7 11:24:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 07 Oct 2013 13:24:24 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <5251EA8D.60507@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> Message-ID: <525299E8.30408@gmail.com> More test data... Running the previously mentioned measurement (allocating direct buffers randomly sized between 256KB and 1MB for 60 seconds) with a single allocating tread that presents allocation pressure which is still acceptable for original code (two threads are already too much an lead to OOME), the results, using 4-core i7 CPU and -XX:MaxDirectMemorySize=128m are: - 482403 allocations satisfied without helping ReferenceHandler - 75 allocations satisfied while helping ReferenceHandler but before System.gc() - 2373 allocations satisfied while helping ReferenceHandler, after System.gc() but before any sleeps - no sleeps avg. allocation: 0.12 ms/op (original code: 0.6 ms/op) This test may be regarded as an edge test. No current real-world application exhibits substantialy higher allocation pressure. If it did, it would throw OOME, so it would be unusable. Above numbers show that majority of allocations (99.5%) happen without helping ReferenceHandler thread. Only every 200th disturbs the ReferenceHandler thread, and it does exactly what ReferenceHandler does asynchronously and because the ReferenceHandler thread is asleep. So it actually increases the promptness of Reference enqueue-ing - not something that could hurt. We can reasonably expect that in current real-world applications helping ReferenceHandler would happen even less frequently, and could not negatively impact application behaviour. What applications will see is up to 5x improvement in throughput of allocation (a result of using atomic operations for reservation and less sleeping). For comparison, here are also the results for 2 allocating threads (higher allocation pressure than any current real-world application): - 734916 allocations satisfied without helping ReferenceHandler - 3112 allocations satisfied while helping ReferenceHandler but before System.gc() - 3817 allocations satisfied while helping ReferenceHandler, after System.gc() but before any sleeps - no sleeps avg. allocation: 0.16 ms/op (per thread) This is still 99.1% allocations without disturbing the peaceful flow of ReferenceHandler thread. Regards, Peter On 10/07/2013 12:56 AM, Peter Levart wrote: > Hi Again, > > The result of my experimentation is as follows: > > Letting ReferenceHandler thread alone to en-queue References and > execute Cleaners is not enough to prevent OOMEs when allocation is > performed in large number of threads even if I let Cleaners do only > synchronous announcing of what will be freed (very fast), delegate the > actual de-allocation to a background thread and base reservation > waiting on announced free space (still wait that space is deallocated > and unreserved before satisfying reservation request, but wait as long > as it takes if the announced free space is enough for reservation > request). > > ReferenceHandler thread, when it finds that it has no more pending > References, parks and waits for notification from VM. The VM promptly > process references (hooks them on the pending list), but with > saturated CPUs, waking-up the ReferenceHandler thread and re-gaining > the lock takes too much time. During that time allocating threads can > reserve the whole permitted space and OOME must be thrown. So I'm back > to strategy #1 - helping ReferenceHandler thread. > > It's not so much about helping to achieve better throughput (as I > noted deallocating can not be effectively parallelized) but to > overcome the latency of waking-up the ReferenceHandler thread. Here's > my attempt at doing this: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ > > This is much simplified from my 1st submission of similar strategy. I > tried to be as undisruptive to current logic of Reference processing > as possible, but of course you decide if this is still too risky for > inclusion into JDK8. Cleaner is unchanged - it processes it's thunk > synchronously and ReferenceHandler thread invokes it directly. > ReferenceHandler logic is the same - I just factored-out the content > of the loop into a private method to be able to call it from nio Bits > where the bulk of change lies. > > The (un)reservation logic is re-implemented with atomic operations - > no locks. When large number of threads are competing for reservation, > locking overhead can be huge and can slow-down unreservation (which > must use the same lock as reservation). The reservation re-try logic > 1st tries to satisfy the reservation request while helping > ReferenceHandler thread in en-queue-ing References and executing > Cleaners until the list of pending references is exhausted. If this > does not succeed, it triggers VM to process references (System.gc()) > and then enters similar re-try loop but introducing exponentially > increasing back-off delay every time the chain of pending references > is exhausted, starting with 1ms sleep and doubling. This gives VM time > to process the references. Maximum number of sleeps is 9, giving max. > accumulated sleep time of 0.5 s. This means that a request that > rightfully throws OOME will do so after 0.5 s sleep. > > I did the following measurement: Using LongAdders (to avoid > Heisenberg) I counted various exit paths from Bits.reserveMemory() > during a test that spawned 128 allocating threads on a 4-core i7 > machine, allocating direct buffers randomly sized between 256KB and > 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: > > Total of 909960 allocations were performed: > > - 247993 were satisfied before attempting to help ReferenceHandler thread > - 660184 were satisfied while helping ReferenceHandler thread but > before triggering System.gc() > - 1783 were satisfied after triggering System.gc() but before doing > any sleep > - no sleeping has been performed > > The same test, just changing -XX:MaxDirectMemorySize=128m (that means > 1MB per thread each allocating direct buffers randomly sized between > 256KB and 1MB): > > Total of 579943 allocations were performed: > > - 131547 were satisfied before attempting to help ReferenceHandler thread > - 438345 were satisfied while helping ReferenceHandler thread but > before triggering System.gc() > - 10016 were satisfied after triggering System.gc() but before doing > any sleep > - 34 were satisfied after sleep(1) > - 1 was satisfied after sleep(1) followed by sleep(2) > > > That's it. I think this is good enough for testing on large scale. I > have also included a modified DirectBufferAllocTest as a unit test, > but I don't know if it's suitable since it takes 60s to run. The run > time could be lowered with less probability to catch OOMEs. > > So what do you think? Is this still too risky for JDK8? > > > Regards, Peter > > On 10/06/2013 01:19 PM, Peter Levart wrote: >> Hi, >> >> I agree the problem with de-allocation of native memory blocks should >> be studied deeply and this takes time. >> >> What I have observed so far on Linux platform (other platforms may >> behave differently) is the following: >> >> Deallocation of native memory with Unsafe.freeMemory(address) can >> take various amounts of time. It can grow to a constant amount of >> several milliseconds to free a 1MB block, for example, when there's >> already lots of blocks allocated and multiple threads are constantly >> allocating more. I'm not sure yet about the main reasons for that, >> but it could either be a contention with allocation from multiple >> threads, interaction with GC, or even the algorithm used in the >> native allocator. Deallocation is also not very parallelizable. My >> observation is that deallocating with 2 threads (on a 4 core CPU) >> does not help much. >> >> Current scheme of deallocating in ReferenceHandler thread means that >> a lot of "pending" Cleaner objects can accumulate and although VM has >> promptly processed Cleaner PhantomReferences (hooked them on the >> pending list), a lot of work is still to be done to actually free the >> native blocks. This clogs ReferenceHandler thread and affects other >> Reference processing. It also presents difficulties for back-off >> strategy for allocating native memory. The strategy has no >> information that would be needed to decide whether to wait more or to >> fail with OOME. >> >> I'm currently experimenting with approach where Cleaner and >> ReferenceHandler code stays as is, but the Cheaner's thunk (the >> Deallocator in DirectByteBuffer) is modified so that it performs some >> actions synchronously (announcing what will be de-allocated) and >> delegates the actual deallocation and unreservation to a background >> thread. Reservation strategy has more information to base it's >> back-off strategy that way. I'll let you know if I get some results >> from that. >> >> Regards, Peter >> >> On 10/04/2013 08:39 PM, mark.reinhold at oracle.com wrote: >>> 2013/10/2 15:13 -0700,alan.bateman at oracle.com: >>>> BTW: Is this important enough to attempt to do this late in 8? I just >>>> wonder about a significant change like switching to weak references and >>>> whether it would be more sensible to hold it back to do early in 9. >>> I share your concern. This is extraordinarily sensitive code. >>> Now is not the time to rewrite it for JDK 8. >>> >>> - Mark >> > From sean.mullan at oracle.com Mon Oct 7 12:26:08 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 08:26:08 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <5252A860.4050609@oracle.com> 7 classes in com.sun.security.auth have been deprecated for several major releases now. Should they still have this annotation? --Sean On 10/06/2013 04:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From Alan.Bateman at oracle.com Mon Oct 7 12:28:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 13:28:52 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252A860.4050609@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> Message-ID: <5252A904.1070808@oracle.com> On 07/10/2013 13:26, Sean Mullan wrote: > 7 classes in com.sun.security.auth have been deprecated for several > major releases now. Should they still have this annotation? > > --Sean I know but aren't they still exported and supported? DialogCallbackHandler is the only one with its name on a bullet. -Alan. From sean.mullan at oracle.com Mon Oct 7 12:36:53 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 08:36:53 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252A904.1070808@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> Message-ID: <5252AAE5.4020806@oracle.com> On 10/07/2013 08:28 AM, Alan Bateman wrote: > On 07/10/2013 13:26, Sean Mullan wrote: >> 7 classes in com.sun.security.auth have been deprecated for several >> major releases now. Should they still have this annotation? >> >> --Sean > I know but aren't they still exported and supported? They have all had API replacements since JDK 1.4 or 1.5. There has been plenty of time to transition. > DialogCallbackHandler is the only one with its name on a bullet. We have only started removing some deprecated things in JDK, so it just was never thought about until now. Marking these as supported going forward strikes me as a bit strange, since we don't really want anyone using these anymore. --Sean From aleksey.shipilev at oracle.com Mon Oct 7 12:43:10 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 07 Oct 2013 16:43:10 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <5251EA8D.60507@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> Message-ID: <5252AC5E.9060704@oracle.com> Hi Peter, On 10/07/2013 02:56 AM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ The 1 hour run of this on my 1x2x2 i5, directMem=16m, original DirectByteBufferTest yields no failures! Oh my. Good job! Comments on the code: Bits.java: - Thread.currentThread().interrupt() only sets the interruption flag, it does not break the control flow. You can call it directly in the exception handler, sparing some boiler-plate code. - Given that you about to retry, do you think catching the interrupt during sleep should immediately return? Or, try the last time to reserve some memory, and either return or throw OOME? - Please avoid inline assignments. - I'd like to embed the comment why 9 is the magic number. Reference.java: - Please move the static initializer block back, that will be cleaner change. - Please keep the (r instanceof Cleaner) block as the separate if; makes it visually different from the common code path. DirectBufferAllocTest.java: - "for(;;)" -> "while(true)" - Can we turn the 60*1000 into the constant? - I think 10 seconds is enough for regression test. - Can we fold the relevant into Integer.getInteger("...", #const) to make them tunable, while still claiming it to be the regtest in the default mode? Put the comment which settings should be used to turn this test into the stress test. > Total of 909960 allocations were performed: > > - 247993 were satisfied before attempting to help ReferenceHandler thread > - 660184 were satisfied while helping ReferenceHandler thread but before > triggering System.gc() > - 1783 were satisfied after triggering System.gc() but before doing any > sleep > - no sleeping has been performed > > The same test, just changing -XX:MaxDirectMemorySize=128m (that means > 1MB per thread each allocating direct buffers randomly sized between > 256KB and 1MB): > > Total of 579943 allocations were performed: > > - 131547 were satisfied before attempting to help ReferenceHandler thread > - 438345 were satisfied while helping ReferenceHandler thread but before > triggering System.gc() > - 10016 were satisfied after triggering System.gc() but before doing any > sleep > - 34 were satisfied after sleep(1) > - 1 was satisfied after sleep(1) followed by sleep(2) > Thank you! I was meant to do this for my original patch. (In fact I did some debug printing on the recovery paths, only to see we almost never hit them). > So what do you think? Is this still too risky for JDK8? I think that the patch is great. We are near the JDK 8 endgame though. As much as I will be happy to have that in 8u0, this is probably something for early JDK 9, with a backport to 8u2? -Aleksey. From Alan.Bateman at oracle.com Mon Oct 7 12:58:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 13:58:17 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252AAE5.4020806@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> <5252AAE5.4020806@oracle.com> Message-ID: <5252AFE9.2040205@oracle.com> On 07/10/2013 13:36, Sean Mullan wrote: > > We have only started removing some deprecated things in JDK, so it > just was never thought about until now. Marking these as supported > going forward strikes me as a bit strange, since we don't really want > anyone using these anymore. As a guide, I think we should plan to address these anomalies for 9 so that we can export APIs on a per API package basis. I'm okay to change these to @jdk.Exported(false) if we can flag them for removal (like we did for DialogCallbackHandler). -Alan. From sean.mullan at oracle.com Mon Oct 7 13:02:35 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 09:02:35 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252AFE9.2040205@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> <5252AAE5.4020806@oracle.com> <5252AFE9.2040205@oracle.com> Message-ID: <5252B0EB.2040803@oracle.com> On 10/07/2013 08:58 AM, Alan Bateman wrote: > On 07/10/2013 13:36, Sean Mullan wrote: >> >> We have only started removing some deprecated things in JDK, so it >> just was never thought about until now. Marking these as supported >> going forward strikes me as a bit strange, since we don't really want >> anyone using these anymore. > As a guide, I think we should plan to address these anomalies for 9 so > that we can export APIs on a per API package basis. I'm okay to change > these to @jdk.Exported(false) if we can flag them for removal (like we > did for DialogCallbackHandler). Sure. I'll file a bug to have these deprecated classes removed in 9. --Sean From paul.sandoz at oracle.com Mon Oct 7 13:24:06 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Oct 2013 15:24:06 +0200 Subject: SplittableRandom update In-Reply-To: <523C57A6.2000508@cs.oswego.edu> References: <523C57A6.2000508@cs.oswego.edu> Message-ID: <2B659A74-4FC1-4EA7-8018-E19BD1222291@oracle.com> While having one last look at this Doug and I found some "oops how the heck did that happen" miscommits with the mix64/mix32/nextGamma methods that contained test code for measuring the impact of shifts: For corrections see: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/SplittableRandom.java?r1=1.23&r2=1.24 Updated patch: http://cr.openjdk.java.net/~psandoz/tl/JDK-8025136-SR-enhancements/webrev/ I will commit this tomorrow unless there are objections. Paul. On Sep 20, 2013, at 4:11 PM, Doug Lea

wrote: > > In the course of writing up a report (coming soon) that includes > discussion of SplittableRandom, we had a chance to further > analyze and test things, resulting in a few small improvements. Plus > some internal renamings to better reflect intent. > Plus now with the same initial seed mechanics > discussed a few days ago for ThreadLocalRandom. > > Thanks to Paul Sandoz for creating webrevs: > > https://bugs.openjdk.java.net/browse/JDK-8025136 > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8025136-SR-enhancements/webrev/ > > I think we need one more reviewer for it. > > -Doug From Alan.Bateman at oracle.com Mon Oct 7 13:24:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 14:24:40 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <524EDA50.5080706@oracle.com> References: <1888522.a2LG2QfRuS@trisuli> <524EDA50.5080706@oracle.com> Message-ID: <5252B618.7030606@oracle.com> On 04/10/2013 16:10, Rob McKenna wrote: > Hi Pavel, > > Thanks for sorting this out. I'm not a reviewer but hopefully Alan > will have a look when he gets a chance. Based on the bug description > this looks good to me though. > > -Rob > I looked over the weekend and it's mostly okay (thanks Pavel for taking one, we don't do enough execution of these tests with fastdebug builds so I'm sure this isn't the only issue that we have). A minor comment is that it might be a bit cleaner to throw RuntimeException rather than Error but it's not a big deal in this test. The only real comment/question is whether performB should fail if process.waitFor is interrupted, this shouldn't happen. Rob - do you plan to sponsor this for Pavel? From rob.mckenna at oracle.com Mon Oct 7 13:40:00 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 07 Oct 2013 14:40:00 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <5252B618.7030606@oracle.com> References: <1888522.a2LG2QfRuS@trisuli> <524EDA50.5080706@oracle.com> <5252B618.7030606@oracle.com> Message-ID: <5252B9B0.4080302@oracle.com> Yep. -Rob On 07/10/13 14:24, Alan Bateman wrote: > On 04/10/2013 16:10, Rob McKenna wrote: >> Hi Pavel, >> >> Thanks for sorting this out. I'm not a reviewer but hopefully Alan >> will have a look when he gets a chance. Based on the bug description >> this looks good to me though. >> >> -Rob >> > I looked over the weekend and it's mostly okay (thanks Pavel for > taking one, we don't do enough execution of these tests with fastdebug > builds so I'm sure this isn't the only issue that we have). > > A minor comment is that it might be a bit cleaner to throw > RuntimeException rather than Error but it's not a big deal in this > test. The only real comment/question is whether performB should fail > if process.waitFor is interrupted, this shouldn't happen. > > Rob - do you plan to sponsor this for Pavel? > From Alan.Bateman at oracle.com Mon Oct 7 14:10:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 15:10:49 +0100 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <5251EA8D.60507@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> Message-ID: <5252C0E9.8050804@oracle.com> On 06/10/2013 23:56, Peter Levart wrote: > : > > It's not so much about helping to achieve better throughput (as I > noted deallocating can not be effectively parallelized) but to > overcome the latency of waking-up the ReferenceHandler thread. Here's > my attempt at doing this: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ > > This is much simplified from my 1st submission of similar strategy. I > tried to be as undisruptive to current logic of Reference processing > as possible, but of course you decide if this is still too risky for > inclusion into JDK8. Cleaner is unchanged - it processes it's thunk > synchronously and ReferenceHandler thread invokes it directly. > ReferenceHandler logic is the same - I just factored-out the content > of the loop into a private method to be able to call it from nio Bits > where the bulk of change lies. > > : > > So what do you think? Is this still too risky for JDK8? > I looked at the latest webrev and I think the approach looks good. I should explain that I did look into this issue about 3-4 years ago and at the time I experimented with the allocating threads waiting until the reference handler had drained the pending list. I didn't think of doing the assist at the time, hence I was interested to see the # allocations where it helped. On the patch then I agree with Aleksey that moving the static initializer makes it less obvious that the only change is registering the shared secret (it's not a big deal of course). The back-off before retrying looks good, I just wonder if 1ms is too low to start with. On the interrupt then I think it's okay to just set the interrupt status as you are doing. I see you switched the tracking for the management interface to use AtomicLong. Are you looking to improve the concurrency or is there another reason? A minor coding convention but the break before "else" and "finally" is inconsistent in these areas. Another consistency point is that maxsleeps is a constant and so should probably be in uppercase. A related piece of work is the FileChannel map implementation where there is a gc + retry if mmap fails. This could be changed to have a similar back-off/retry. On the test then the copyright date is 2001-2007 so I assume this was copied from somewhere :-) I agree with Aleksey on the test duration, especially if you can provoke OOME in less than 10 or 20 seconds on some machines. As regards whether this should go into JDK 8 then the updated proposal is significantly less risky that the original proposal that changed the implementation to use weak references. That said, this is a 13 year old issue that hasn't come up very often (to my knowledge anyway, perhaps because those making heavy use of direct buffers are pooling buffers rather than allocating and unreferencing). In additional we are close to the end of JDK 8 (ZBB is in 2.5 weeks time) and technically we have been in ramp down (meaning P1-P3 only) since mid-July. -Alan. From cowwoc at bbs.darktech.org Mon Oct 7 15:30:02 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 07 Oct 2013 11:30:02 -0400 Subject: Debug builds Message-ID: <5252D37A.5050603@bbs.darktech.org> Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? Thanks, Gili From peter.levart at gmail.com Mon Oct 7 16:47:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 07 Oct 2013 18:47:41 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <5252AC5E.9060704@oracle.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> <5252AC5E.9060704@oracle.com> Message-ID: <5252E5AD.2000407@marand.si> On 10/07/2013 02:43 PM, Aleksey Shipilev wrote: > Hi Peter, > > On 10/07/2013 02:56 AM, Peter Levart wrote: >> http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ > The 1 hour run of this on my 1x2x2 i5, directMem=16m, original > DirectByteBufferTest yields no failures! Oh my. Good job! Thanks! > Comments on the code: > > Bits.java: > - Thread.currentThread().interrupt() only sets the interruption flag, > it does not break the control flow. You can call it directly in the > exception handler, sparing some boiler-plate code. ...then the next possible sleep() in loop will immediately throw InterruptedException again. That's why I set the flag and set the interrupted status just before returning in a finally block where all exit paths converge... > - Given that you about to retry, do you think catching the interrupt > during sleep should immediately return? Or, try the last time to reserve > some memory, and either return or throw OOME? I have a rule that when InterruptedException is caught in a method (or method invokes Thread.interrupted() which returns true), then this method must do one of the following 3 things: - throw InterruptedException or - complete normally or throw any other exception, but make sure current Thread's interrupted status is set before completing/throwing or - never complete That's the only way to not swallow interrupts. Now in this concrete example, I must not loop indefinitely, I can not throw InterruptedException, neither can I complete normally, since that would mean the memory has been reserved (which it hasn't). I could throw OOME *and* set the interrupted status of current thread, but as we have seen from the DirectBufferTest I ran, some allocations did need occasional sleep(1) or even sleep(2) before completing normally. If thread had interrupted status set in such situations, allocation would throw OOME, which feels wrong, since it would not be thrown if the thread was not interrupted. So it seems best to continue processing and pretend that InterruptedException never happened, but make sure interrupted status is set before completing. What I should correct is, that when the InterruptedException is caught during sleep, 'sleeps' counter is not incremented and 'sleepTime' is not doubled, since the wake-up was premature and should not count - 9 consecutive interrupts could theoretically provoke OOME because the loop would exit after 9 "fake" sleeps. > - Please avoid inline assignments. Doug's school ;-) You mean the following: long totalCap; while (cap <= maxMemory - (totalCap = totalCapacity.get())) { if (totalCapacity.compareAndSet(totalCap, totalCap + cap)) { ... return true; } } So how would you write this? Alternatives: a) while (true) { long totalCap = totalCapacity.get(); if (cap > maxMemory - totalCap) { break; } if (totalCapacity.compareAndSet(totalCap, totalCap + cap)) { ... return true; } } b) long totalCap = totalCapacity.get(); while (cap <= maxMemory - totalCap) { if (totalCapacity.compareAndSet(totalCap, totalCap + cap)) { ... return true; } totalCap = totalCapacity.get(); } c) for (long totalCap = totalCapacity.get(); cap <= maxMemory - totalCap; totalCap = totalCapacity.get()) { if (totalCapacity.compareAndSet(totalCap, totalCap + cap)) { ... return true; } } d) ??? > - I'd like to embed the comment why 9 is the magic number. Ok. WIll do. > Reference.java: > - Please move the static initializer block back, that will be cleaner > change. I actually haven't moved the static initializer block. It's still immediately after the ReferenceHandler class (at least syntactically). I moved the content of the for loop in ReferenceHandler#run() method out into a new method inserted after the static initializer. Sdiffs tool matches by similarity of content when aligning left and right panes. I can insert the new method between ReferenceHandler class and static initializer, thus "moving" the static initializer, and Sdiffs will show less blue text, but the hg changeset might be even more confusing to read (or merge) that way. I will try and see what happens. > - Please keep the (r instanceof Cleaner) block as the separate if; > makes it visually different from the common code path. Right. > DirectBufferAllocTest.java: > - "for(;;)" -> "while(true)" Ok. > - Can we turn the 60*1000 into the constant? Ok. > - I think 10 seconds is enough for regression test. I think too. It usually fails after few seconds. > - Can we fold the relevant into Integer.getInteger("...", #const) to > make them tunable, while still claiming it to be the regtest in the > default mode? Put the comment which settings should be used to turn this > test into the stress test. WIll do. >> Total of 909960 allocations were performed: >> >> - 247993 were satisfied before attempting to help ReferenceHandler thread >> - 660184 were satisfied while helping ReferenceHandler thread but before >> triggering System.gc() >> - 1783 were satisfied after triggering System.gc() but before doing any >> sleep >> - no sleeping has been performed >> >> The same test, just changing -XX:MaxDirectMemorySize=128m (that means >> 1MB per thread each allocating direct buffers randomly sized between >> 256KB and 1MB): >> >> Total of 579943 allocations were performed: >> >> - 131547 were satisfied before attempting to help ReferenceHandler thread >> - 438345 were satisfied while helping ReferenceHandler thread but before >> triggering System.gc() >> - 10016 were satisfied after triggering System.gc() but before doing any >> sleep >> - 34 were satisfied after sleep(1) >> - 1 was satisfied after sleep(1) followed by sleep(2) >> > Thank you! I was meant to do this for my original patch. (In fact I did > some debug printing on the recovery paths, only to see we almost never > hit them). > > >> So what do you think? Is this still too risky for JDK8? > I think that the patch is great. We are near the JDK 8 endgame though. > As much as I will be happy to have that in 8u0, this is probably > something for early JDK 9, with a backport to 8u2? I see. JDK9 and backport then. > -Aleksey. Regards, Peter From pavel.punegov at oracle.com Mon Oct 7 16:47:22 2013 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 07 Oct 2013 20:47:22 +0400 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <5252B618.7030606@oracle.com> References: <1888522.a2LG2QfRuS@trisuli> <524EDA50.5080706@oracle.com> <5252B618.7030606@oracle.com> Message-ID: <2558863.oXUMbxbUgH@trisuli> Hi Alan, On Monday 07 October 2013 14:24:40 you wrote: > On 04/10/2013 16:10, Rob McKenna wrote: > > Hi Pavel, > > > > Thanks for sorting this out. I'm not a reviewer but hopefully Alan > > will have a look when he gets a chance. Based on the bug description > > this looks good to me though. > > > > -Rob > > I looked over the weekend and it's mostly okay (thanks Pavel for taking > one, we don't do enough execution of these tests with fastdebug builds > so I'm sure this isn't the only issue that we have). Thanks for looking on this > A minor comment is that it might be a bit cleaner to throw > RuntimeException rather than Error but it's not a big deal in this test. Error throwing on InterruptedException was added to not break code style in the code that throws only Errors all over the test. If you want to I can change this Error (and other throws too) to RuntimeException. > The only real comment/question is whether performB should fail if > process.waitFor is interrupted, this shouldn't happen. Printing "B was interrupted while waiting for C" on InterruptedException could help if we had a regression and performC were looped. When this happens Jtreg hits timeout and kills/ends all processes. Messages of each processes that waited for another one will be printed to stderr. I think it will ease failure analysis in some situations like hanging, host or VM slowness. Thanks, Pavel From stevenschlansker at gmail.com Mon Oct 7 17:35:09 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 7 Oct 2013 10:35:09 -0700 Subject: Debug builds In-Reply-To: <5252D37A.5050603@bbs.darktech.org> References: <5252D37A.5050603@bbs.darktech.org> Message-ID: On Oct 7, 2013, at 8:30 AM, cowwoc wrote: > Hi, > > Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? +1 on shipping debug builds with the JDK, that would be very helpful for those of us who are stupid^Wcurious enough to step-debug into JDK classes. From brian.burkhalter at oracle.com Mon Oct 7 17:40:19 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 10:40:19 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <524E4ECB.2040007@oracle.com> References: <524E4ECB.2040007@oracle.com> Message-ID: <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> On Oct 3, 2013, at 10:14 PM, Alan Bateman wrote: > On 03/10/2013 16:17, Brian Burkhalter wrote: >> Please review and comment at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8016252 >> Webrev: http://cr.openjdk.java.net/~bpb/8016252/ >> >> Summary >> * Improve validation checks in HashSet.readObject(). >> >> Would this change imply updating the serialVersionUID? >> > I assume that capacity and loadFactor will be checked when attempting to create the HashMap so I don't think we strictly need the additional checks. > > As regards size > capacity, then won't that break things if the loadFactor is high? The size < 0 case seems to be harmless, we'll just end up with an empty Set. > > You SVUID shouldn't be updated (the serial form hasn't changed). I have posted an updated webrev here: http://cr.openjdk.java.net/~bpb/8016252.2/ I don't know whether it is the correct way to go, but this version attempts to use the capacity, load factor, and size as read in, insofar as they appear reasonable. Thanks, Brian From cowwoc at bbs.darktech.org Mon Oct 7 17:45:12 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 07 Oct 2013 13:45:12 -0400 Subject: Debug builds In-Reply-To: References: <5252D37A.5050603@bbs.darktech.org> Message-ID: <5252F328.4050505@bbs.darktech.org> On 07/10/2013 1:35 PM, Steven Schlansker wrote: > On Oct 7, 2013, at 8:30 AM, cowwoc wrote: > >> Hi, >> >> Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? > +1 on shipping debug builds with the JDK, that would be very helpful for those of us who are stupid^Wcurious enough to step-debug into JDK classes. I have personally wasted countless days/weeks/months debugging problems that would have been solved much quicker by having full debug symbols. Furthermore, as you can see at http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.html the GNU/Linux world also ships with full debug symbols by default. I'd like to take this opportunity to follow-up on http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. I am confused because this post seems to be saying that Oracle JDK 7 ships full debug symbols, but in my experience this is not the case. It would be good to get some answers from someone in the know. Thanks, Gili From valerie.peng at oracle.com Mon Oct 7 18:14:00 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 07 Oct 2013 11:14:00 -0700 Subject: Code Review Request for 8025967 "addition of -Werror broke the old build" In-Reply-To: <5252D623.4040302@oracle.com> References: <524F4030.8000906@oracle.com> <5252D623.4040302@oracle.com> Message-ID: <5252F9E8.30905@oracle.com> Thanks Vinnie for the review~ Forwarding this request to core-libs-dev per Sean's suggestion. Changes are for getting rid of compiler warnings in order for JCE provider build (still using the old build process) to complete successfully - either add the annotation to suppress rawtype warnings or change local declarations from Class[] to Class[]. If there are concerns, please let me know by EOB today as I have to get JCE changes integrated before leaving for vacation. Thanks, Valerie On 10/07/13 08:41, Sean Mullan wrote: > I would also send this to core-libs-dev for someone to look over the > non-security component changes. > > --Sean > > On 10/04/2013 06:24 PM, Valerie (Yu-Ching) Peng wrote: >> >> Well, can someone please review the following trivial fix today or early >> Monday? >> 8025967: addition of -Werror broke the old build >> >> JCE is still using the legacy build and as a result, I have to fix build >> warnings in other components in order for the whole build to succeed. >> The changes are all about addressing the javac raw type warnings. >> I want to keep changes to a minimum, thus I only changed the >> private/implementation related ones and used annotation to disable the >> warnings in all public APIs and some private ones where there are >> dependencies, e.g. JNI. >> >> Webrev can be found at: http://cr.openjdk.java.net/~valeriep/8025967/ >> >> Thanks! >> Valerie >> > From henry.jen at oracle.com Mon Oct 7 18:32:58 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Mon, 07 Oct 2013 18:32:58 +0000 Subject: hg: jdk8/tl/jdk: 8025968: Integrate test improvements made in lambda repo Message-ID: <20131007183325.BD04D62E0B@hg.openjdk.java.net> Changeset: f0ad3e2918b4 Author: henryjen Date: 2013-10-07 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ad3e2918b4 8025968: Integrate test improvements made in lambda repo Reviewed-by: psandoz ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java From christian.thalinger at oracle.com Mon Oct 7 18:34:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Oct 2013 11:34:45 -0700 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52526FC2.60409@oracle.com> References: <52526FC2.60409@oracle.com> Message-ID: <76937102-C812-4B63-AAB5-21867DDE8191@oracle.com> Unfortunate but I understand. It might be a good idea to add a getCallerClass(-1) call to the test case. On Oct 7, 2013, at 1:24 AM, Mandy Chung wrote: > JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ > > It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. > > Thanks > Mandy From Alan.Bateman at oracle.com Mon Oct 7 20:31:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 21:31:30 +0100 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> Message-ID: <52531A22.1070803@oracle.com> On 07/10/2013 18:40, Brian Burkhalter wrote: > : > I have posted an updated webrev here: > > http://cr.openjdk.java.net/~bpb/8016252.2/ > > I don't know whether it is the correct way to go, but this version attempts to use the capacity, load factor, and size as read in, insofar as they appear reasonable. > This looks better. The checks on loadFactor look okay. I'm not so sure about capacity, a simple check if it is negative should be sufficient. For size then I don't think the Math.max has any real effect because the loop don't do anything if size is negative You could just throw IllegalObjectException if it is negative (as per the first patch) if you really wanted to. -Alan. From brian.burkhalter at oracle.com Mon Oct 7 20:35:17 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 13:35:17 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <52531A22.1070803@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> Message-ID: <195C09DF-FA49-47C6-850E-347961E334BD@oracle.com> On Oct 7, 2013, at 1:31 PM, Alan Bateman wrote: > I'm not so sure about capacity, a simple check if it is negative should be sufficient. The idea was to try to use the value if it appears reasonable, which is assured by the clamping. > For size then I don't think the Math.max has any real effect because the loop don't do anything if size is negative You could just throw IllegalObjectException if it is negative (as per the first patch) if you really wanted to. It has an effect as size is used on clamping the capacity value. Brian From peter.levart at gmail.com Mon Oct 7 20:36:36 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 07 Oct 2013 22:36:36 +0200 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <5252C0E9.8050804@oracle.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> <5252C0E9.8050804@oracle.com> Message-ID: <52531B54.1000802@gmail.com> On 10/07/2013 04:10 PM, Alan Bateman wrote: > On 06/10/2013 23:56, Peter Levart wrote: >> : >> >> It's not so much about helping to achieve better throughput (as I >> noted deallocating can not be effectively parallelized) but to >> overcome the latency of waking-up the ReferenceHandler thread. Here's >> my attempt at doing this: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ >> >> This is much simplified from my 1st submission of similar strategy. I >> tried to be as undisruptive to current logic of Reference processing >> as possible, but of course you decide if this is still too risky for >> inclusion into JDK8. Cleaner is unchanged - it processes it's thunk >> synchronously and ReferenceHandler thread invokes it directly. >> ReferenceHandler logic is the same - I just factored-out the content >> of the loop into a private method to be able to call it from nio Bits >> where the bulk of change lies. >> >> : >> >> So what do you think? Is this still too risky for JDK8? >> > I looked at the latest webrev and I think the approach looks good. > > I should explain that I did look into this issue about 3-4 years ago > and at the time I experimented with the allocating threads waiting > until the reference handler had drained the pending list. I didn't > think of doing the assist at the time, hence I was interested to see > the # allocations where it helped. Ask not what reference handler can do for you, ask what you can do for reference handler! ;-) I first saw the idea in Clif Click's lock-free hash table. Then recently, in the new Doug Lea's ConcurrentHashMap. This last one was fresh and got me thinking... > > On the patch then I agree with Aleksey that moving the static > initializer makes it less obvious that the only change is registering > the shared secret (it's not a big deal of course). I'll try to make Sdiff not "move" it. (See the answer to Aleksey) > > The back-off before retrying looks good, I just wonder if 1ms is too > low to start with. The tests show that in majority of calls (at least on fast CPUs), thread does not sleep at all and if it really must sleep, a single sleep(1) is usually enough. So why sleep more? We have exponential back-off, so on slower CPUs, where longer sleeps might be needed, a couple of iterations more will be enough to reach the right point in time. I'll try the measurement on Raspberry PI. I wonder how it behaves there... Somewhere I read that the resolution of Thread.sleep() is not 1 ms, but much more. In that case Thread.sleep(1) sleeps much more. That must have been some time ago or on some other platform, because if I run this on current JDK8/Linux: for (long d = 1; d < 100; d++) { long t0 = System.nanoTime(); Thread.sleep(d); long t1 = System.nanoTime(); System.out.println("sleep(" + d + ") takes " + (t1-t0) + " ns"); } I get: sleep(1) takes 1079078 ns sleep(2) takes 2058245 ns sleep(3) takes 3060258 ns sleep(4) takes 4060121 ns sleep(5) takes 5061263 ns sleep(6) takes 6063189 ns sleep(7) takes 7075132 ns sleep(8) takes 8071381 ns sleep(9) takes 9062244 ns ... ...which seems pretty accurate. > > On the interrupt then I think it's okay to just set the interrupt > status as you are doing. I think too. > > I see you switched the tracking for the management interface to use > AtomicLong. Are you looking to improve the concurrency or is there > another reason? With looping over tryReserveMemory and helping ReferenceHandler which calls unreserveMemory from other threads too, the number of monitor acquire/releases per allocation request would increase significantly if we kept synchronized blocks. And with multiple contended threads the overhead would increase too. So I got rid of locks, because it could be done: There's a single accumulator used for regulating reserve/unreserve (totalCapacity) and this can be maintained with READ-CAS-RETRY on reserve and ATOMIC ADD on unreserve. Other values are just for management interface, which doesn't require a "snapshot" view, so they can each be maintained with ATOMIC ADD independently. > A minor coding convention but the break before "else" and "finally" is > inconsistent in these areas. Another consistency point is that > maxsleeps is a constant and so should probably be in uppercase. I should've set-up the IDEA's Code Style correctly. Will correct this. > > A related piece of work is the FileChannel map implementation where > there is a gc + retry if mmap fails. This could be changed to have a > similar back-off/retry. > I see. Would it make sense to do it in same patch or separately. This too, will need JavaLangRefAccess.tryHandlePendingReference(), I think, since it similarly ties unmap0 to a Cleaner referencing MappedByteBuffer. The tryMap0 would just be a call to map0 with catching of OOME and returning true/false, right? Do you happen to know what defines the limit of how many bytes or blocks can be mapped at one time? Is this some parameter for VM or is this just plain OS limit? > On the test then the copyright date is 2001-2007 so I assume this was > copied from somewhere :-) I agree with Aleksey on the test duration, > especially if you can provoke OOME in less than 10 or 20 seconds on > some machines. Right. > > As regards whether this should go into JDK 8 then the updated proposal > is significantly less risky that the original proposal that changed > the implementation to use weak references. > > That said, this is a 13 year old issue that hasn't come up very often > (to my knowledge anyway, perhaps because those making heavy use of > direct buffers are pooling buffers rather than allocating and > unreferencing). In additional we are close to the end of JDK 8 (ZBB is > in 2.5 weeks time) and technically we have been in ramp down (meaning > P1-P3 only) since mid-July. Ok then, I'll finish this nevertheless and then it can sit and wait for JDK9. Regards, Peter > > -Alan. > > > > From brian.burkhalter at oracle.com Mon Oct 7 20:43:42 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 13:43:42 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <52531A22.1070803@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> Message-ID: <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> On Oct 7, 2013, at 1:31 PM, Alan Bateman wrote: > For size then I don't think the Math.max has any real effect because the loop don't do anything if size is negative You could just throw IllegalObjectException if it is negative (as per the first patch) if you really wanted to. On second thought an exception really should be thrown on negative size; will update. Brian From brian.burkhalter at oracle.com Mon Oct 7 21:03:35 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 14:03:35 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> Message-ID: <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> On Oct 7, 2013, at 1:43 PM, Brian Burkhalter wrote: > On second thought an exception really should be thrown on negative size; will update. http://cr.openjdk.java.net/~bpb/8016252.2/ updated including a not-very-exciting and perhaps unnecessary test. Brian From mike.duigou at oracle.com Mon Oct 7 21:47:55 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Oct 2013 14:47:55 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> Message-ID: <99C5F89B-90D7-4EB1-BA44-132CDA2558CF@oracle.com> On Oct 4 2013, at 13:58 , Brian Burkhalter wrote: > On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: > >> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: >> >>> On 03/10/2013 16:10, Brian Burkhalter wrote: >>>> Please review and comment at your convenience. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ > > An updated webrev which I hope adequately addresses the expressed concerns may be found at: > > http://cr.openjdk.java.net/~bpb/7179567.2/ Looks good to me. Does the addition of "If {@code codesource} is {@code null} the returned {@code PermissionCollection} is empty." constitute a spec change or just a clarification? I see the URClassLoader change @@ -625,10 +661,14 @@ but am unsure. Mike > >> >>> Will you be adding tests for these cases to the webrev? >> >> As needed once the concept in general is accepted. > > The foregoing webrev includes a test of the affected public methods. > > Thanks, > > Brian From joe.darcy at oracle.com Mon Oct 7 22:02:15 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 07 Oct 2013 15:02:15 -0700 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52532F67.4070408@oracle.com> Hello, I skimmed the patch and it looked fine. More generally, we want every package and top-level class in the com.sun.* namespace to be either explicitly exported or not. Cheers, -Joe On 10/6/2013 1:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number > of JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number > of packages that didn't have any description. In a few cases, I've had > to rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to > the package-info and all public/protected types in these APIs. The > only exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From henry.jen at oracle.com Mon Oct 7 21:56:01 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 07 Oct 2013 14:56:01 -0700 Subject: RFR: 8026009: Changes for 8025968 break all stream tests Message-ID: <52532DF1.5030705@oracle.com> Hi, May I have a quick review on this left-out change to fix broken test? Apology for the inconvenience. http://cr.openjdk.java.net/~henryjen/tl/8026009/0/webrev/ Following is all it is, > diff --git a/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java b/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java > --- a/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java > +++ b/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java > @@ -591,10 +591,10 @@ > > // Test data > > - private class ShortCircuitOp implements StatelessTestOp { > + static class ShortCircuitOp implements StatelessTestOp { > private final StreamShape shape; > > - private ShortCircuitOp(StreamShape shape) { > + ShortCircuitOp(StreamShape shape) { > this.shape = shape; > } > Cheers, Henry From mike.duigou at oracle.com Mon Oct 7 22:06:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Oct 2013 15:06:16 -0700 Subject: RFR: 8026009: Changes for 8025968 break all stream tests In-Reply-To: <52532DF1.5030705@oracle.com> References: <52532DF1.5030705@oracle.com> Message-ID: <2FD36F6F-8849-4A15-9A4C-7CC2E36132A5@oracle.com> Looks good to me but I haven't completed a full build/test with this change (yet). Mike On Oct 7 2013, at 14:56 , Henry Jen wrote: > Hi, > > May I have a quick review on this left-out change to fix broken test? > Apology for the inconvenience. > > http://cr.openjdk.java.net/~henryjen/tl/8026009/0/webrev/ > > Following is all it is, > >> diff --git a/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java b/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java >> --- a/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java >> +++ b/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java >> @@ -591,10 +591,10 @@ >> >> // Test data >> >> - private class ShortCircuitOp implements StatelessTestOp { >> + static class ShortCircuitOp implements StatelessTestOp { >> private final StreamShape shape; >> >> - private ShortCircuitOp(StreamShape shape) { >> + ShortCircuitOp(StreamShape shape) { >> this.shape = shape; >> } >> > > Cheers, > Henry > From joe.darcy at oracle.com Mon Oct 7 22:26:28 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 07 Oct 2013 15:26:28 -0700 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> Message-ID: <52533514.8000100@oracle.com> Without comments on the contents of the patch, a change in documented behavior would require a ccc request. Cheers, -Joe On 10/3/2013 5:58 PM, Brian Burkhalter wrote: > I have reviewed this proposed change a couple of times in its current form and it looks good to me. > > It would be good to see some comments about the general concept from BigInt cognoscenti, and from (a) Reviewer(s) as concerns the @implNote addition as well as the new ArithmeticExceptions added at several points in the javadoc. With respect to these latter, in the event the patch were to be approved, would a CCC request be in order? > > Brian > > On Oct 1, 2013, at 7:50 PM, cowwoc wrote: > >> Sounds good. Thanks for the clarification. >> >> Gili >> >> On 01/10/2013 9:25 PM, Dmitry Nadezhin wrote: >>> I see that I misused the word "to clamp" in this discussion. >>> I guess that addition with "clumping" means: >>> return x + y < MIN_VALUE ? MIN_VALUE : x + y > MAX_VALUE ? MAX_VALUE : x + >>> y; >>> >>> The patch actually throws ArithmeticException on overflow: >>> if (x + y < MIN_VALUE || x + y > MAX_VALUE) throw new ArithmetiException(); >>> else return x + y; >>> >>> The word "clamp" appeared in the discussion only. >>> Comments in the patch don't contain it. They say: >>> >>> BigInteger constructors and operations throw {@code >>> ArithmeticException} whenthe result is out of the supported range. >>> >>> On Tue, Oct 1, 2013 at 11:45 PM, cowwoc wrote: >>> >>>> I prefer throwing exceptions on unusual conditions (e.g. overflow) and >>>> letting the user clamp the value if they so wish. Clamping will lead to >>>> unexpected behavior once values fall outside this range. Yes, it will be >>>> documented, but I daresay most applications won't ever check for it and >>>> produce incorrect results as a consequence. >>>> >>>> Gili >>>> >>>> >>>> On 01/10/2013 2:19 PM, Dmitry Nadezhin wrote: >>>> >>>>> Dear BigInteger experts, >>>>> Do you have comments to my previous message ? >>>>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** >>>>> September/021264.html From brian.burkhalter at Oracle.COM Mon Oct 7 22:40:15 2013 From: brian.burkhalter at Oracle.COM (Brian Burkhalter) Date: Mon, 7 Oct 2013 15:40:15 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <99C5F89B-90D7-4EB1-BA44-132CDA2558CF@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <99C5F89B-90D7-4EB1-BA44-132CDA2558CF@oracle.com> Message-ID: <65384A74-79D3-4AF1-887D-F7FE35B3589F@Oracle.COM> On Oct 7, 2013, at 2:47 PM, Mike Duigou wrote: >> An updated webrev which I hope adequately addresses the expressed concerns may be found at: >> >> http://cr.openjdk.java.net/~bpb/7179567.2/ > > Looks good to me. > > Does the addition of "If {@code codesource} is {@code null} the returned {@code PermissionCollection} is empty." constitute a spec change or just a clarification? I see the URClassLoader change @@ -625,10 +661,14 @@ but am unsure. To me it's a clarification but it would be helpful for someone else to weight in on the question. Thanks, Brian From brian.burkhalter at oracle.com Mon Oct 7 22:42:02 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 15:42:02 -0700 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <52533514.8000100@oracle.com> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> <52533514.8000100@oracle.com> Message-ID: I would expect as much, but that's an exercise I'd prefer to avoid at this time if the content does not appear likely to be acceptable. Thanks, Brian On Oct 7, 2013, at 3:26 PM, Joseph Darcy wrote: > Without comments on the contents of the patch, a change in documented behavior would require a ccc request. From brian.burkhalter at oracle.com Mon Oct 7 23:00:53 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Oct 2013 16:00:53 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: Resuming this discussion ? Thanks for the previous comments. My feeling at this point is to do one of two things: A) defer to something after JDK 8, or B) on EAI_AGAIN do not retry but set the cause of the UAE to "new SomeException(gai_strerror(error))" where SomeException could be for example Exception, RuntimeException, or IOException. Comments? Thanks, Brian From henry.jen at oracle.com Mon Oct 7 23:50:27 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Mon, 07 Oct 2013 23:50:27 +0000 Subject: hg: jdk8/tl/jdk: 8026009: Changes for 8025968 break all stream tests Message-ID: <20131007235048.ABE8762E19@hg.openjdk.java.net> Changeset: 0cffe1dab0bf Author: henryjen Date: 2013-10-07 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cffe1dab0bf 8026009: Changes for 8025968 break all stream tests Reviewed-by: mduigou ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java From joe.darcy at oracle.com Mon Oct 7 23:52:13 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 07 Oct 2013 23:52:13 +0000 Subject: hg: jdk8/tl/langtools: 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Message-ID: <20131007235219.1698962E1A@hg.openjdk.java.net> Changeset: 4dd7ffbf01fb Author: darcy Date: 2013-10-07 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dd7ffbf01fb 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java From mandy.chung at oracle.com Tue Oct 8 00:28:41 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 17:28:41 -0700 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <525291AC.7030009@oracle.com> References: <52526FC2.60409@oracle.com> <525291AC.7030009@oracle.com> Message-ID: <525351B9.7010309@oracle.com> On 10/7/2013 3:49 AM, Alan Bateman wrote: > On 07/10/2013 09:24, Mandy Chung wrote: >> JDK 8 was feature complete in June and there just isn't sufficient >> time remaining to get agreement and feedback on an API to examine the >> caller frames. To that end, I propose to restore the old unsupported >> Reflection.getCallerClass(int) and that we will look to define a >> standard API for JDK 9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >> >> It remains to be an unsupported API and JDK should not use this >> method and it's not annotated with @CallerSensitive. I considered >> detecting if this method is called by a system class (loaded by null >> loader) and throw an error. I decided to minimize the compatibility >> risk in case if there is any existing code added to the bootclasspath >> depending on this private API. > I liked the direction this was going with the walkStack and > firstCaller proposal but it is way too late in jdk8 to have any time > to get feedback. So I agree that temporarily restoring the unsupported > Reflection.getCallerClass(int) is the right thing for now. As the > standard API is likely to be significant then it probably warrants a JEP. > I agree and I meant to mention that too. I will submit a JEP and target it for JDK 9. > As regards the webrev then the changes looks okay. I guess you could > rename one of the native methods to avoid the non-obvious name > mangling but since it is only temporary then I could live with what > you have. As it's temporary, I will leave it as it is. Thanks Mandy From mandy.chung at oracle.com Tue Oct 8 00:44:18 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 17:44:18 -0700 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <76937102-C812-4B63-AAB5-21867DDE8191@oracle.com> References: <52526FC2.60409@oracle.com> <76937102-C812-4B63-AAB5-21867DDE8191@oracle.com> Message-ID: <52535562.2070907@oracle.com> On 10/7/2013 11:34 AM, Christian Thalinger wrote: > Unfortunate but I understand. It might be a good idea to add a getCallerClass(-1) call to the test case. The VM should throw an exception if JVM_GetCallerClass is called by any method other than Reflection.getCallerClass(). It's a good idea to add such test case. thanks Mandy > On Oct 7, 2013, at 1:24 AM, Mandy Chung wrote: > >> JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >> >> It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. >> >> Thanks >> Mandy From mike.duigou at oracle.com Tue Oct 8 00:51:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Oct 2013 17:51:49 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <524E4F0C.9060101@oracle.com> References: <524E4F0C.9060101@oracle.com> Message-ID: On Oct 3 2013, at 22:15 , David Holmes wrote: > On 4/10/2013 1:35 PM, Mike Duigou wrote: >> Hello all; >> >> This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. > > It isn't at all clear to me what specification you are using to define the expected behaviour here. Most of the new Map methods provide only limited support for null values. This is not due to null-hostility but generally a consequence of trying to avoid the additional overhead of disambiguating between value absent and null value. This includes the result of get() and null returns are also used from the functions to provide special behaviour (usually removal). The merge() spec is typical in that it promises to treat null and absent values the same. Some might suggest this is a cunning plot by Doug to discourage use of null values. Perhaps. ;-) The utility of being able to use null values as sentinels, whether from get() or the use function is primary reason for this behaviour. Making the behaviour of the Map defaults and core collections "not horrible" and "not astonishing" in the presence null values has been a fun challenge. :-) It's sometimes necessitated providing alternative defaults for ConcurrentMap. I believe that the defaults in Map and ConcurrentMap could further diverge over time if it turns out to be a problem that the current Map defaults don't look aggressively enough for concurrent modification. > I would have thought that anyone supplying a remapping function needs to be aware of whether the target map supports nulls or not, and that the remapping function should then do the right thing if null is encountered. Instead you are making the decision to bypass the remapping function if you encounter a null. Bypassing the function is what merge() does when there's no existing values. This behaviour is not specific to my changes. Here's the logic table I used to construct the tests: current value merged put/rem returned ======= ===== ====== ======= ======== absent null n/a remove null absent newval n/a newval newval null null n/a remove null null newval n/a newval newval oldval null null remove null oldval null result result result oldval newval null remove null oldval newval result result result Alternatively, compute() offers the more general behaviour of always calling the remapping function though it does not offer the opportunity to directly provide a "newValue" (capture by the lambda is the alternative). If I had designed the API I would have had only a single method that provided newValue and unconditionally called the function. This is probably would have been naive--I don't know Doug's reasons behind choosing this behaviour for merge() and compute() though I am certainly curious about why it is done the way it is. Mike > > David > >> The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ >> >> Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. >> >> Mike >> From xuelei.fan at oracle.com Tue Oct 8 01:47:30 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 08 Oct 2013 01:47:30 +0000 Subject: hg: jdk8/tl/jdk: 6956398: make ephemeral DH key match the length of the certificate key Message-ID: <20131008014817.94FEF62E1D@hg.openjdk.java.net> Changeset: 0d5f4f1782e8 Author: xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java From david.holmes at oracle.com Tue Oct 8 04:28:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 14:28:13 +1000 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> Message-ID: <525389DD.8000608@oracle.com> Hi Brian, Aside: I'm confused about the relationship of this bug and JDK-6445180 - are they not duplicates? Seems to me this one should have been closed as a dup when it was reported. On 5/10/2013 6:58 AM, Brian Burkhalter wrote: > On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: > >> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: >> >>> On 03/10/2013 16:10, Brian Burkhalter wrote: >>>> Please review and comment at your convenience. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ > > An updated webrev which I hope adequately addresses the expressed concerns may be found at: > > http://cr.openjdk.java.net/~bpb/7179567.2/ URLClassLoader.java: please delete the commented out line: + //Objects.requireNonNull(urls); SecureClassLoader.java: 186 * @throws SecurityException if the {@code ClassLoader} instance is not 187 * initialized. should read "this classloader instance" as it refers to the current instance. Also this may be bringing the spec into line with the implementation but "initialization" here is purely an implementation detail not part of the specification for this class so it should not be mentioned explicitly - and this change still needs a CCC (which might help determine exactly what should be said here - I'm unclear how you can try to call getPermissions if this is uninitialized as it would need 'this' to escape from the constructor - which perhaps it can do via a third-party security manager?). NoCallStackClassLoader.java: the comment is far too verbose, we don't write such explanatory kinds of comments for this kind of thing (else the code would be overrun with commentary!). Aside: if you are a JDK Author you don't need a Contributed-by line in the commit comments. David ----- >> >>> Will you be adding tests for these cases to the webrev? >> >> As needed once the concept in general is accepted. > > The foregoing webrev includes a test of the affected public methods. > > Thanks, > > Brian > From david.holmes at oracle.com Tue Oct 8 04:45:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 14:45:16 +1000 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52526FC2.60409@oracle.com> References: <52526FC2.60409@oracle.com> Message-ID: <52538DDC.6020000@oracle.com> Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. David On 7/10/2013 6:24 PM, Mandy Chung wrote: > JDK 8 was feature complete in June and there just isn't sufficient time > remaining to get agreement and feedback on an API to examine the caller > frames. To that end, I propose to restore the old unsupported > Reflection.getCallerClass(int) and that we will look to define a > standard API for JDK 9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ > > It remains to be an unsupported API and JDK should not use this method > and it's not annotated with @CallerSensitive. I considered detecting if > this method is called by a system class (loaded by null loader) and > throw an error. I decided to minimize the compatibility risk in case if > there is any existing code added to the bootclasspath depending on this > private API. > > Thanks > Mandy From mandy.chung at oracle.com Tue Oct 8 05:04:55 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 22:04:55 -0700 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52538DDC.6020000@oracle.com> References: <52526FC2.60409@oracle.com> <52538DDC.6020000@oracle.com> Message-ID: <52539277.9010101@oracle.com> On 10/7/2013 9:45 PM, David Holmes wrote: > Hi Mandy, > > Note that unless you push both hotspot and jdk changes through the > same forest you will need separate bugs for each part. You will also > need a HSX committer to do the hotspot push. > I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? Mandy > David > > On 7/10/2013 6:24 PM, Mandy Chung wrote: >> JDK 8 was feature complete in June and there just isn't sufficient time >> remaining to get agreement and feedback on an API to examine the caller >> frames. To that end, I propose to restore the old unsupported >> Reflection.getCallerClass(int) and that we will look to define a >> standard API for JDK 9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >> >> It remains to be an unsupported API and JDK should not use this method >> and it's not annotated with @CallerSensitive. I considered detecting if >> this method is called by a system class (loaded by null loader) and >> throw an error. I decided to minimize the compatibility risk in case if >> there is any existing code added to the bootclasspath depending on this >> private API. >> >> Thanks >> Mandy From david.holmes at oracle.com Tue Oct 8 05:42:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 15:42:29 +1000 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <52531B54.1000802@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> <5252C0E9.8050804@oracle.com> <52531B54.1000802@gmail.com> Message-ID: <52539B45.3040509@oracle.com> On 8/10/2013 6:36 AM, Peter Levart wrote: > Somewhere I read that the resolution of Thread.sleep() is not 1 ms, but > much more. In that case Thread.sleep(1) sleeps much more. That must have > been some time ago or on some other platform, because if I run this on > current JDK8/Linux: > > for (long d = 1; d < 100; d++) { > long t0 = System.nanoTime(); > Thread.sleep(d); > long t1 = System.nanoTime(); > System.out.println("sleep(" + d + ") takes " + (t1-t0) + " > ns"); > } > > I get: > > sleep(1) takes 1079078 ns > sleep(2) takes 2058245 ns > sleep(3) takes 3060258 ns > sleep(4) takes 4060121 ns > sleep(5) takes 5061263 ns > sleep(6) takes 6063189 ns > sleep(7) takes 7075132 ns > sleep(8) takes 8071381 ns > sleep(9) takes 9062244 ns > ... > > ...which seems pretty accurate. It is platform specific. Solaris 10 will give 10ms by default. Windows will give anywhere from 5 to 60ms on my laptop :) and is Windows version specific. Even Linux may depend on system config and what clocksource is used. David > >> >> On the interrupt then I think it's okay to just set the interrupt >> status as you are doing. > > I think too. > >> >> I see you switched the tracking for the management interface to use >> AtomicLong. Are you looking to improve the concurrency or is there >> another reason? > > With looping over tryReserveMemory and helping ReferenceHandler which > calls unreserveMemory from other threads too, the number of monitor > acquire/releases per allocation request would increase significantly if > we kept synchronized blocks. And with multiple contended threads the > overhead would increase too. So I got rid of locks, because it could be > done: There's a single accumulator used for regulating reserve/unreserve > (totalCapacity) and this can be maintained with READ-CAS-RETRY on > reserve and ATOMIC ADD on unreserve. Other values are just for > management interface, which doesn't require a "snapshot" view, so they > can each be maintained with ATOMIC ADD independently. > >> A minor coding convention but the break before "else" and "finally" is >> inconsistent in these areas. Another consistency point is that >> maxsleeps is a constant and so should probably be in uppercase. > > I should've set-up the IDEA's Code Style correctly. Will correct this. > >> >> A related piece of work is the FileChannel map implementation where >> there is a gc + retry if mmap fails. This could be changed to have a >> similar back-off/retry. >> > > I see. Would it make sense to do it in same patch or separately. This > too, will need JavaLangRefAccess.tryHandlePendingReference(), I think, > since it similarly ties unmap0 to a Cleaner referencing > MappedByteBuffer. The tryMap0 would just be a call to map0 with catching > of OOME and returning true/false, right? > > Do you happen to know what defines the limit of how many bytes or blocks > can be mapped at one time? Is this some parameter for VM or is this just > plain OS limit? > >> On the test then the copyright date is 2001-2007 so I assume this was >> copied from somewhere :-) I agree with Aleksey on the test duration, >> especially if you can provoke OOME in less than 10 or 20 seconds on >> some machines. > > Right. > >> >> As regards whether this should go into JDK 8 then the updated proposal >> is significantly less risky that the original proposal that changed >> the implementation to use weak references. >> >> That said, this is a 13 year old issue that hasn't come up very often >> (to my knowledge anyway, perhaps because those making heavy use of >> direct buffers are pooling buffers rather than allocating and >> unreferencing). In additional we are close to the end of JDK 8 (ZBB is >> in 2.5 weeks time) and technically we have been in ramp down (meaning >> P1-P3 only) since mid-July. > > Ok then, I'll finish this nevertheless and then it can sit and wait for > JDK9. > > Regards, Peter > >> >> -Alan. >> >> >> >> > From paul.sandoz at oracle.com Tue Oct 8 08:27:29 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Oct 2013 10:27:29 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: References: Message-ID: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> Hi Mike, I am probably going over old ground here... Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry, or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? The defaults on Map could state they are not suitable for maps that can be concurrently modified, if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? Paul. On Oct 4, 2013, at 5:35 AM, Mike Duigou wrote: > Hello all; > > This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. > > The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. > > http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ > > Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. > > Mike From chris.hegarty at oracle.com Tue Oct 8 08:51:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Oct 2013 09:51:13 +0100 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> Message-ID: <5253C781.5070600@oracle.com> On 10/07/2013 10:03 PM, Brian Burkhalter wrote: > On Oct 7, 2013, at 1:43 PM, Brian Burkhalter wrote: > >> On second thought an exception really should be thrown on negative size; will update. > > http://cr.openjdk.java.net/~bpb/8016252.2/ updated including a not-very-exciting and perhaps unnecessary test. This looks much better. loadfactor and size validation look good, and in line with the original suggestion in the bug. For the initial capacity what was originally suggested was to use a similar technique to that of HashMap.readObject ( to ensure that the table never needs to be rehashed during load, and ends up being at least 25% full). Snippet from the bug: int capacity = (int)Math.min(size * Math.min(1 / loadFactor, 4.0f), HashMap.MAXIMUM_CAPACITY); I'm curious why you have not taken that suggestion? What you have looks ok, but it does reply on reasonable capacity and loadfactor values. I have not looked in any detail at the test, but the file should start with the copyright/header, and not the import statements. -Chris. > > Brian > From Alan.Bateman at oracle.com Tue Oct 8 09:14:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 10:14:21 +0100 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> Message-ID: <5253CCED.8010504@oracle.com> On 07/10/2013 22:03, Brian Burkhalter wrote: > On Oct 7, 2013, at 1:43 PM, Brian Burkhalter wrote: > >> On second thought an exception really should be thrown on negative size; will update. > http://cr.openjdk.java.net/~bpb/8016252.2/ updated including a not-very-exciting and perhaps unnecessary test. > > Brian This looks better, the checks on loadFactor and size look okay. I don't know all the history on this bug but it looks like the goal was partly to avoid resizing when deserializing. This means the capacity could match HashMap. To be consistent with the size check then we could throw an exception if the capacity is negative (interesting case for tests and malware only). I skimmed over the test but it doesn't appear to exercise anything new. If you want to exercise the checks then it would require deserializing from a byte stream that results in bad loadFactor, size and capacity values. It might not be worth it of course. -Alan From chris.hegarty at oracle.com Tue Oct 8 09:18:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Oct 2013 10:18:36 +0100 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52539277.9010101@oracle.com> References: <52526FC2.60409@oracle.com> <52538DDC.6020000@oracle.com> <52539277.9010101@oracle.com> Message-ID: <5253CDEC.4040409@oracle.com> On 10/08/2013 06:04 AM, Mandy Chung wrote: > On 10/7/2013 9:45 PM, David Holmes wrote: >> Hi Mandy, >> >> Note that unless you push both hotspot and jdk changes through the >> same forest you will need separate bugs for each part. You will also >> need a HSX committer to do the hotspot push. >> > > I do plan to push them separately meaning that the jdk change will wait > until the hotspot change is integrated. I think the hotspot integration > is weekly. > > I am not a HSX committer :( Since I have your attention, can you > sponsor my hotspot change? For such small hotspot changes it seems overly restrictive to have to push then through a hotspot integration forest. We have a perfectly good hotspot repo in tl, why not use it? -Chris. > > Mandy > >> David >> >> On 7/10/2013 6:24 PM, Mandy Chung wrote: >>> JDK 8 was feature complete in June and there just isn't sufficient time >>> remaining to get agreement and feedback on an API to examine the caller >>> frames. To that end, I propose to restore the old unsupported >>> Reflection.getCallerClass(int) and that we will look to define a >>> standard API for JDK 9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >>> >>> It remains to be an unsupported API and JDK should not use this method >>> and it's not annotated with @CallerSensitive. I considered detecting if >>> this method is called by a system class (loaded by null loader) and >>> throw an error. I decided to minimize the compatibility risk in case if >>> there is any existing code added to the bootclasspath depending on this >>> private API. >>> >>> Thanks >>> Mandy > From david.holmes at oracle.com Tue Oct 8 09:29:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 19:29:24 +1000 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <52539277.9010101@oracle.com> References: <52526FC2.60409@oracle.com> <52538DDC.6020000@oracle.com> <52539277.9010101@oracle.com> Message-ID: <5253D074.1000902@oracle.com> On 8/10/2013 3:04 PM, Mandy Chung wrote: > On 10/7/2013 9:45 PM, David Holmes wrote: >> Hi Mandy, >> >> Note that unless you push both hotspot and jdk changes through the >> same forest you will need separate bugs for each part. You will also >> need a HSX committer to do the hotspot push. >> > > I do plan to push them separately meaning that the jdk change will wait > until the hotspot change is integrated. I think the hotspot integration > is weekly. > > I am not a HSX committer :( Since I have your attention, can you > sponsor my hotspot change? Sure. Hotspot change is now tracked under 8026025 and being pushed to hotspot-rt. David ----- > Mandy > >> David >> >> On 7/10/2013 6:24 PM, Mandy Chung wrote: >>> JDK 8 was feature complete in June and there just isn't sufficient time >>> remaining to get agreement and feedback on an API to examine the caller >>> frames. To that end, I propose to restore the old unsupported >>> Reflection.getCallerClass(int) and that we will look to define a >>> standard API for JDK 9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >>> >>> It remains to be an unsupported API and JDK should not use this method >>> and it's not annotated with @CallerSensitive. I considered detecting if >>> this method is called by a system class (loaded by null loader) and >>> throw an error. I decided to minimize the compatibility risk in case if >>> there is any existing code added to the bootclasspath depending on this >>> private API. >>> >>> Thanks >>> Mandy > From david.holmes at oracle.com Tue Oct 8 09:35:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 19:35:10 +1000 Subject: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int) In-Reply-To: <5253CDEC.4040409@oracle.com> References: <52526FC2.60409@oracle.com> <52538DDC.6020000@oracle.com> <52539277.9010101@oracle.com> <5253CDEC.4040409@oracle.com> Message-ID: <5253D1CE.709@oracle.com> On 8/10/2013 7:18 PM, Chris Hegarty wrote: > On 10/08/2013 06:04 AM, Mandy Chung wrote: >> On 10/7/2013 9:45 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> Note that unless you push both hotspot and jdk changes through the >>> same forest you will need separate bugs for each part. You will also >>> need a HSX committer to do the hotspot push. >>> >> >> I do plan to push them separately meaning that the jdk change will wait >> until the hotspot change is integrated. I think the hotspot integration >> is weekly. >> >> I am not a HSX committer :( Since I have your attention, can you >> sponsor my hotspot change? > > For such small hotspot changes it seems overly restrictive to have to > push then through a hotspot integration forest. We have a perfectly good > hotspot repo in tl, why not use it? Even if tl forest was used it still has to be pushed by a hsx committer and via JPRT. Until we have some definitive processes in place (current ones are ad-hoc) pushing the hotspot changes first is a simple but un-timely approach. Otherwise additional coordination is needed regardless of whether you use hsx forest or tl forest to push from. David ----- > -Chris. > >> >> Mandy >> >>> David >>> >>> On 7/10/2013 6:24 PM, Mandy Chung wrote: >>>> JDK 8 was feature complete in June and there just isn't sufficient time >>>> remaining to get agreement and feedback on an API to examine the caller >>>> frames. To that end, I propose to restore the old unsupported >>>> Reflection.getCallerClass(int) and that we will look to define a >>>> standard API for JDK 9. >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ >>>> >>>> It remains to be an unsupported API and JDK should not use this method >>>> and it's not annotated with @CallerSensitive. I considered >>>> detecting if >>>> this method is called by a system class (loaded by null loader) and >>>> throw an error. I decided to minimize the compatibility risk in >>>> case if >>>> there is any existing code added to the bootclasspath depending on this >>>> private API. >>>> >>>> Thanks >>>> Mandy >> From Alan.Bateman at oracle.com Tue Oct 8 09:43:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 10:43:30 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> Message-ID: <5253D3C2.3080509@oracle.com> On 08/10/2013 00:00, Brian Burkhalter wrote: > Resuming this discussion ? > > Thanks for the previous comments. My feeling at this point is to do one of two things: > > A) defer to something after JDK 8, or > B) on EAI_AGAIN do not retry but set the cause of the UAE to "new SomeException(gai_strerror(error))" where SomeException could be for example Exception, RuntimeException, or IOException. > > Comments? > Throwing UHE with a useful message or cause would be best, so option B. However, I don't think it is critical for jdk8 as it's not a new issue (at least I think UHE has always been thrown with just the hostname, never the reason if it is known). So if there isn't time to be confident with the patch then it should be okay to move this out to 9. -Alan. From volker.simonis at gmail.com Tue Oct 8 10:03:51 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Oct 2013 12:03:51 +0200 Subject: Debug builds In-Reply-To: <5252F328.4050505@bbs.darktech.org> References: <5252D37A.5050603@bbs.darktech.org> <5252F328.4050505@bbs.darktech.org> Message-ID: Hi Gili, the mail threads you mention in your mail refer to debugging symbols in the native VM implementation (i.e. libjvm.so) and not to debug symbols in the java classes in rt.jar. Regards, Volker On Mon, Oct 7, 2013 at 7:45 PM, cowwoc wrote: > On 07/10/2013 1:35 PM, Steven Schlansker wrote: > >> On Oct 7, 2013, at 8:30 AM, cowwoc wrote: >> >> Hi, >>> >>> Where did the old debug builds of rt.jar go (meaning, rt.jar with >>> full debug symbols, even for local variables)? I scanned the mailing list >>> for a related discussion but couldn't find anything. It looks like >>> somewhere down the line a decision was made to remove these builds, but >>> it's not clear why that was. Also, out of curiosity, what is the overhead >>> of the full debug symbols (versus what we ship now)? Couldn't we ship a >>> full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? >>> >> +1 on shipping debug builds with the JDK, that would be very helpful for >> those of us who are stupid^Wcurious enough to step-debug into JDK classes. >> > > I have personally wasted countless days/weeks/months debugging > problems that would have been solved much quicker by having full debug > symbols. Furthermore, as you can see at http://mail.openjdk.java.net/** > pipermail/build-dev/2012-**October/006892.htmlthe GNU/Linux world also ships with full debug symbols by default. > > I'd like to take this opportunity to follow-up on > http://mail.openjdk.java.net/**pipermail/build-dev/2012-** > October/006881.html. > I am confused because this post seems to be saying that Oracle JDK 7 ships > full debug symbols, but in my experience this is not the case. It would be > good to get some answers from someone in the know. > > Thanks, > Gili > From paul.sandoz at oracle.com Tue Oct 8 09:49:05 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 08 Oct 2013 09:49:05 +0000 Subject: hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements Message-ID: <20131008095033.9061F62E23@hg.openjdk.java.net> Changeset: b90dcd1a71bf Author: psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea
, Guy Steele ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From scolebourne at joda.org Tue Oct 8 10:24:25 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 8 Oct 2013 11:24:25 +0100 Subject: Deflater enhancements Message-ID: I've been trying to use Deflater today and found it rather tricky. Two thoughts... 1) The class level Javadoc specifies a fixed size byte array of 100. http://download.java.net/jdk8/docs/api/java/util/zip/Deflater.html >From what I can tell from other searching and basic common sense, this cannot be right as the output size could well be bigger than 100. However, there is no real information in the Deflater class as to how the class is supposed to be used. I don't believe that kind of broken example is helpful. The best I found was http://java.dzone.com/articles/how-compress-and-uncompress which proposed a loop: Deflater deflater = new Deflater(); deflater.setInput(data); ByteArrayOutputStream outputStream = new ByteArrayOutputStream(data.length); deflater.finish(); byte[] buffer = new byte[1024]; while (!deflater.finished()) { int count = deflater.deflate(buffer); // returns the generated code... index outputStream.write(buffer, 0, count); } outputStream.close(); byte[] output = outputStream.toByteArray(); Neither example call deflater.end(), which I believe to be a mistake as well. Is my analysis correct? Should I raise a bug for better documentation? (this appears to affect Inflater as well) 2) Even with the Javadoc change, the API is still far too complex. As a user, all I want is something like: byte[] compressed = Deflater.deflate(input, options...) and similar for Inflater. (I actually want to compress a String, and an override to handle that would be useful as well) Any thoughts on adding a convenience method to make the API a lot easier? Can I raise a bug for that? Stephen From Alan.Bateman at oracle.com Tue Oct 8 11:08:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 12:08:56 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> Message-ID: <5253E7C8.3030707@oracle.com> On 04/10/2013 21:58, Brian Burkhalter wrote: > : > An updated webrev which I hope adequately addresses the expressed concerns may be found at: > > http://cr.openjdk.java.net/~bpb/7179567.2/ > This looks much better. If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. My previous comment on @throws vs. @exception was just to keep things consistent as this is old code and would look odd for a method to use both. Our preference is to switch to @throws whenever the opportunity arises. The comment was also on the alignment/style. Take URLCLassLoader(URL[], ClassLoader) for example, the existing SecurityException has its description aligned under SecurityException whereas the new NullPointerException wraps around. So my overall comment here was to avoid mixing styles (it doesn't matter too much which style is used, just keep it consistent for future maintainers). In the test then it might be better to change the @summary line to only include the second paragraph (the bug summary is not interesting, especially when it references a test that is not in OpenJDK). -Alan. From alan.bateman at oracle.com Tue Oct 8 11:13:29 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Oct 2013 11:13:29 +0000 Subject: hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Message-ID: <20131008111357.0B8C962E2C@hg.openjdk.java.net> Changeset: 95bb56c61276 Author: alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java From ivan.gerasimov at oracle.com Tue Oct 8 11:40:58 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Oct 2013 15:40:58 +0400 Subject: [7u-dev] Request for review of backport 7147084 In-Reply-To: <5242EA3F.7040307@oracle.com> References: <52415B60.5050608@oracle.com> <5242EA3F.7040307@oracle.com> Message-ID: <5253EF4A.9080208@oracle.com> Alan, Rob, Martin, Would you please help review the backport? I see you were the reviewers for the master fix. I need a review for the backport, since the patch couldn't get applied cleanly. Here are the changes I had to make: - I had to manually replace Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle it automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Thanks in advance, Ivan On 25.09.2013 17:50, Ivan Gerasimov wrote: > Hello! > > May I please have a review for a backport of the fix for 7147084 to > jdk7u-dev? > > This webrev does not include fix 8007454 anymore, as it has already > been pushed. > http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/ > > Thanks in advance, > Ivan Gerasimov > > > -------- Original Message -------- > Subject: Re: [7u-dev] Request for approval for CRs 8007454, 7147084 > Date: Tue, 24 Sep 2013 10:29:04 +0100 > From: Se?n Coffey > To: Ivan Gerasimov > CC: jdk7u-dev at openjdk.java.net > > > > On 24/09/2013 10:25, Ivan Gerasimov wrote: >> Thanks Se?n! >> >> Then I'll ask for an approval to backport 8007454, which is applied >> cleanly. > Consider both bugs fixes approved. You could use this mail thread to > review the 7147084 changes if you want. They're innocent enough. Alan or > someone else should be able to review. > > regards, > Sean. >> And once it is pushed, I'll initiate a review for 7147084 with >> adjustments. >> >> Sincerely, >> Ivan >> >> On 24.09.2013 12:59, Se?n Coffey wrote: >>> Approved for jdk7u-dev but you'll need a review first due to the >>> adjustments needed in the backport. >>> >>> Hopefully, you'll be resolving these issues with 2 different >>> changesets. It's been the trend in the past and helps keep changesets >>> more aligned to those in JDK 8. >>> >>> regards, >>> Sean. >>> >>> On 24/09/2013 09:08, Ivan Gerasimov wrote: >>>> Sending to the correct ML >>>> >>>> -------------- >>>> >>>> Hello! >>>> >>>> We have a request to backport fix for 7147084. >>>> >>>> First, it depends on the fix for 8007454, so the webrev includes it >>>> too. >>>> Second, the fix had to be adjusted a bit. >>>> - I had to manually replaced Java_java_lang_ProcessImpl_create() >>>> function body with the new version, as 'hg patch' could not handle >>>> automatically. >>>> - I had to replace wide-char strings to regular char*, in all the >>>> calls to win32Error() function. >>>> >>>> Combined webrev: >>>> http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/ >>>> >>>> BUGS: >>>> http://bugs.sun.com/view_bug.do?bug_id=7147084 >>>> http://bugs.sun.com/view_bug.do?bug_id=8007454 >>>> >>>> JDK8 Changesets: >>>> 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa >>>> 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d >>>> >>>> Reviews for jdk8 fix: >>>> >>>> 7147084: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html >>>> >>>> 8007454: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html >>>> >>>> >>>> I had set up a JPRT job, which completed successfully. >>>> All the .*jdk_lang.* test passed. >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>> >>> >>> >> > > > > > > > From paul.sandoz at oracle.com Tue Oct 8 11:42:43 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Oct 2013 13:42:43 +0200 Subject: RFR 8020061: Clarify reporting characteristics between splits Message-ID: Hi, The following patch is a minor clarification to the documentation of Spliterator.characteristics(): http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169 Paul. --- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04 2013 +0200 +++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27 2013 +0200 @@ -414,12 +414,18 @@ public interface Spliterator { * #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED}, * {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT}, * {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on - * a given spliterator should always return the same result. + * a given spliterator, prior to or in-between calls to {@code trySplit}, + * should always return the same result. * *

If a Spliterator reports an inconsistent set of * characteristics (either those returned from a single invocation * or across multiple invocations), no guarantees can be made * about any computation using this Spliterator. + * + * @apiNote The characteristics of a given spliterator before splitting + * may differ from the characteristics after splitting. For specific + * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED} + * and {@link #CONCURRENT}. * * @return a representation of characteristics */ From Alan.Bateman at oracle.com Tue Oct 8 12:42:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 13:42:23 +0100 Subject: RFR 8020061: Clarify reporting characteristics between splits In-Reply-To: References: Message-ID: <5253FDAF.1090801@oracle.com> On 08/10/2013 12:42, Paul Sandoz wrote: > Hi, > > The following patch is a minor clarification to the documentation of Spliterator.characteristics(): > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169 > > Paul. > This looks okay to me. -Alan. From chris.hegarty at oracle.com Tue Oct 8 13:02:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Oct 2013 14:02:51 +0100 Subject: RFR 8020061: Clarify reporting characteristics between splits In-Reply-To: References: Message-ID: <5254027B.2000607@oracle.com> Sorry Paul, I know the apiNote says "for examples see ..." but would you mind providing an example. I'm scratching my head. -Chris. On 10/08/2013 12:42 PM, Paul Sandoz wrote: > Hi, > > The following patch is a minor clarification to the documentation of Spliterator.characteristics(): > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169 > > Paul. > > --- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04 2013 +0200 > +++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27 2013 +0200 > @@ -414,12 +414,18 @@ public interface Spliterator { > * #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED}, > * {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT}, > * {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on > - * a given spliterator should always return the same result. > + * a given spliterator, prior to or in-between calls to {@code trySplit}, > + * should always return the same result. > * > *

If a Spliterator reports an inconsistent set of > * characteristics (either those returned from a single invocation > * or across multiple invocations), no guarantees can be made > * about any computation using this Spliterator. > + * > + * @apiNote The characteristics of a given spliterator before splitting > + * may differ from the characteristics after splitting. For specific > + * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED} > + * and {@link #CONCURRENT}. > * > * @return a representation of characteristics > */ > From paul.sandoz at oracle.com Tue Oct 8 13:10:02 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Oct 2013 15:10:02 +0200 Subject: RFR 8020061: Clarify reporting characteristics between splits In-Reply-To: <5254027B.2000607@oracle.com> References: <5254027B.2000607@oracle.com> Message-ID: <76EE1C20-EE62-4377-AACC-2523AC501CB3@oracle.com> On Oct 8, 2013, at 3:02 PM, Chris Hegarty wrote: > Sorry Paul, I know the apiNote says "for examples see ..." but would you mind providing an example. I'm scratching my head. > * @apiNote Most Spliterators for Collections, that cover all elements of a * {@code Collection} report this characteristic. Sub-spliterators, such as * those for {@link HashSet}, that cover a sub-set of elements and * approximate their reported size do not. */ public static final int SIZED = 0x00000040; Set s = new HashSet<>(Arrays.asList(1, 2, 3, 4)); Spliterator split1 = s.spliterator(); System.out.println(split1.hasCharacteristics(Spliterator.SIZED)); Spliterator split2 = split1.trySplit(); System.out.println(split1.hasCharacteristics(Spliterator.SIZED)); System.out.println(split2.hasCharacteristics(Spliterator.SIZED)); Paul. > -Chris. > > On 10/08/2013 12:42 PM, Paul Sandoz wrote: >> Hi, >> >> The following patch is a minor clarification to the documentation of Spliterator.characteristics(): >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169 >> >> Paul. >> >> --- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04 2013 +0200 >> +++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27 2013 +0200 >> @@ -414,12 +414,18 @@ public interface Spliterator { >> * #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED}, >> * {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT}, >> * {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on >> - * a given spliterator should always return the same result. >> + * a given spliterator, prior to or in-between calls to {@code trySplit}, >> + * should always return the same result. >> * >> *

If a Spliterator reports an inconsistent set of >> * characteristics (either those returned from a single invocation >> * or across multiple invocations), no guarantees can be made >> * about any computation using this Spliterator. >> + * >> + * @apiNote The characteristics of a given spliterator before splitting >> + * may differ from the characteristics after splitting. For specific >> + * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED} >> + * and {@link #CONCURRENT}. >> * >> * @return a representation of characteristics >> */ >> From jan.lahoda at oracle.com Tue Oct 8 13:14:29 2013 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 08 Oct 2013 15:14:29 +0200 Subject: RFR JDK-7183985: (ann) Class.getAnnotation() throws an ArrayStoreException when the annotation class not present Message-ID: <52540535.7040700@oracle.com> Hi, Please review the fix for bug JDK-7183985, bug: https://bugs.openjdk.java.net/browse/JDK-7183985 webrev: http://cr.openjdk.java.net/~jlahoda/7183985/webrev.00/ The problem, as I understand it, is as follows. Consider this code: ----- @WithArray({E.class}) class O { } @Retention(RetentionPolicy.RUNTIME) @interface WithArray { Class[] value(); } class E { } ----- The code is compiled and is being inspected by reflection at runtime. Assume the type "E" is not available at that time. At that point calling: O.class.getAnnotations(); or: O.class.getAnnotation(WithArray.class); will lead to: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy The proposed fix is to throw TypeNotPresentException only when the WithArray.value() method is invoked on the instance of the annotation returned from O.class.getAnnotation(WithArray.class). Something similar happens for enum constants missing at runtime (will throw EnumConstantNotPresentException after the patch when queried). There is also a somewhat related case when an annotation type is missing: ----- @WithArray({@E}) class O { } @Retention(RetentionPolicy.RUNTIME) @interface WithArray { Class[] value(); } @interface E { } ----- If "E" is missing at runtime, calling O.getAnnotations() leads to: java.lang.NoClassDefFoundError: [Ltest/E; After this fix, the O.getAnnotations() won't throw the exception, and the resulting array won't contain the WithArray annotation. Does this sound like a reasonable direction/patch? Thanks, Jan From aleksey.shipilev at oracle.com Tue Oct 8 14:31:05 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 08 Oct 2013 18:31:05 +0400 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <52531B54.1000802@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> <5252C0E9.8050804@oracle.com> <52531B54.1000802@gmail.com> Message-ID: <52541729.5080804@oracle.com> On 10/08/2013 12:36 AM, Peter Levart wrote: >> That said, this is a 13 year old issue that hasn't come up very often >> (to my knowledge anyway, perhaps because those making heavy use of >> direct buffers are pooling buffers rather than allocating and >> unreferencing). In additional we are close to the end of JDK 8 (ZBB is >> in 2.5 weeks time) and technically we have been in ramp down (meaning >> P1-P3 only) since mid-July. > > Ok then, I'll finish this nevertheless and then it can sit and wait for > JDK9. Sounds like a good plan, with the backport to JDK 8 update. Thanks for taking this over, Peter. I reassigned the JDK-6857566 to you. Once you ready with the final patch, put the link here, I have two guys (Hazelcast and Netty) who are up to assist us with reviews and testing. This issue seems to grind their gears. ;) -Aleksey. From cowwoc at bbs.darktech.org Tue Oct 8 14:52:31 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 08 Oct 2013 10:52:31 -0400 Subject: Debug builds In-Reply-To: References: <5252D37A.5050603@bbs.darktech.org> <5252F328.4050505@bbs.darktech.org> Message-ID: <52541C2F.20108@bbs.darktech.org> Hi Volker, Thanks for the clarification. I have been able to ascertain that adding full debug symbols to rt.jar would grow the file by 12MB (uncompressed, probably much smaller after you run PACK200). The debugging symbols for native code probably cost a lot more than that. Any idea on why rt.jar does not contain full debug symbols in the JDK? If I open a bug report for this, is anyone willing to push this through the system? Thanks, Gili On 08/10/2013 6:03 AM, Volker Simonis wrote: > Hi Gili, > > the mail threads you mention in your mail refer to debugging symbols > in the native VM implementation (i.e. libjvm.so) and not to debug > symbols in the java classes in rt.jar. > > Regards, > Volker > > > > On Mon, Oct 7, 2013 at 7:45 PM, cowwoc > wrote: > > On 07/10/2013 1:35 PM, Steven Schlansker wrote: > > On Oct 7, 2013, at 8:30 AM, cowwoc > wrote: > > Hi, > > Where did the old debug builds of rt.jar go (meaning, > rt.jar with full debug symbols, even for local variables)? > I scanned the mailing list for a related discussion but > couldn't find anything. It looks like somewhere down the > line a decision was made to remove these builds, but it's > not clear why that was. Also, out of curiosity, what is > the overhead of the full debug symbols (versus what we > ship now)? Couldn't we ship a full-debug rt.jar with the > JDK and ship the smaller rt.jar with the JRE? > > +1 on shipping debug builds with the JDK, that would be very > helpful for those of us who are stupid^Wcurious enough to > step-debug into JDK classes. > > > I have personally wasted countless days/weeks/months debugging > problems that would have been solved much quicker by having full > debug symbols. Furthermore, as you can see at > http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.html > the GNU/Linux world also ships with full debug symbols by default. > > I'd like to take this opportunity to follow-up on > http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. > I am confused because this post seems to be saying that Oracle JDK > 7 ships full debug symbols, but in my experience this is not the > case. It would be good to get some answers from someone in the know. > > Thanks, > Gili > > From chris.hegarty at oracle.com Tue Oct 8 14:53:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Oct 2013 15:53:41 +0100 Subject: RFR 8020061: Clarify reporting characteristics between splits In-Reply-To: <76EE1C20-EE62-4377-AACC-2523AC501CB3@oracle.com> References: <5254027B.2000607@oracle.com> <76EE1C20-EE62-4377-AACC-2523AC501CB3@oracle.com> Message-ID: <52541C75.5060200@oracle.com> Thanks Paul. In which case, the spec clarifications seem fine. -Chris. On 10/08/2013 02:10 PM, Paul Sandoz wrote: > > On Oct 8, 2013, at 3:02 PM, Chris Hegarty wrote: > >> Sorry Paul, I know the apiNote says "for examples see ..." but would you mind providing an example. I'm scratching my head. >> > > * @apiNote Most Spliterators for Collections, that cover all elements of a > * {@code Collection} report this characteristic. Sub-spliterators, such as > * those for {@link HashSet}, that cover a sub-set of elements and > * approximate their reported size do not. > */ > public static final int SIZED = 0x00000040; > > Set s = new HashSet<>(Arrays.asList(1, 2, 3, 4)); > > Spliterator split1 = s.spliterator(); > System.out.println(split1.hasCharacteristics(Spliterator.SIZED)); > > Spliterator split2 = split1.trySplit(); > System.out.println(split1.hasCharacteristics(Spliterator.SIZED)); > System.out.println(split2.hasCharacteristics(Spliterator.SIZED)); > > Paul. > > >> -Chris. >> >> On 10/08/2013 12:42 PM, Paul Sandoz wrote: >>> Hi, >>> >>> The following patch is a minor clarification to the documentation of Spliterator.characteristics(): >>> >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169 >>> >>> Paul. >>> >>> --- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04 2013 +0200 >>> +++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27 2013 +0200 >>> @@ -414,12 +414,18 @@ public interface Spliterator { >>> * #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED}, >>> * {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT}, >>> * {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on >>> - * a given spliterator should always return the same result. >>> + * a given spliterator, prior to or in-between calls to {@code trySplit}, >>> + * should always return the same result. >>> * >>> *

If a Spliterator reports an inconsistent set of >>> * characteristics (either those returned from a single invocation >>> * or across multiple invocations), no guarantees can be made >>> * about any computation using this Spliterator. >>> + * >>> + * @apiNote The characteristics of a given spliterator before splitting >>> + * may differ from the characteristics after splitting. For specific >>> + * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED} >>> + * and {@link #CONCURRENT}. >>> * >>> * @return a representation of characteristics >>> */ >>> > From sundararajan.athijegannathan at oracle.com Tue Oct 8 15:26:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Oct 2013 15:26:34 +0000 Subject: hg: jdk8/tl/nashorn: 6 new changesets Message-ID: <20131008152640.B367362E44@hg.openjdk.java.net> Changeset: 6345d08fd5de Author: hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025213.js + test/script/basic/JDK-8025213.js.EXPECTED Changeset: 8c326f8c6799 Author: sundar Date: 2013-10-08 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c326f8c6799 8026033: Switch should load expression even when there are no cases in it Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026033.js + test/script/basic/JDK-8026033.js.EXPECTED Changeset: 025e2ff9e91b Author: hannesw Date: 2013-10-08 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/025e2ff9e91b 8025965: Specialized functions with same weight replace each other in TreeSet Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 19dba6637f20 Author: sundar Date: 2013-10-08 14:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/19dba6637f20 8026039: future strict names are allowed as function name and argument name of a strict function Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/error/JDK-8026039.js + test/script/error/JDK-8026039.js.EXPECTED Changeset: c9921761903b Author: hannesw Date: 2013-10-08 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c9921761903b 8026042: FoldConstants need to guard against ArrayLiteralNode Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8026042.js + test/script/basic/JDK-8026042.js.EXPECTED Changeset: 346ba5b8a488 Author: sundar Date: 2013-10-08 16:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/346ba5b8a488 8026048: Function constructor should convert arguments to String before performing any syntax checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8026048.js From chris.hegarty at oracle.com Tue Oct 8 15:53:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Oct 2013 16:53:21 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <5253E7C8.3030707@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> Message-ID: <52542A71.2020208@oracle.com> On 10/08/2013 12:08 PM, Alan Bateman wrote: > On 04/10/2013 21:58, Brian Burkhalter wrote: >> : >> An updated webrev which I hope adequately addresses the expressed >> concerns may be found at: >> >> http://cr.openjdk.java.net/~bpb/7179567.2/ >> > This looks much better. Yes, this is much nicer. I'd be tempted to write another private constructor, taking all args, and checking params with checkForNullURLs before invoking, similar to ThreadGroup [1] L117, for example. But that is just clean up to remove some duplication. No need to do this. > If I read the code correctly then the long standing behavior of > URLClassLoader.getPermissions(null) was to throw a NPE, now it is > changed to return the empty collection in order to match the super type > (SecureClassLoader). I can't think of anything that would break so this > is probably okay, just maybe a bit surprising. Agreed. > My previous comment on @throws vs. @exception was just to keep things > consistent as this is old code and would look odd for a method to use > both. Our preference is to switch to @throws whenever the opportunity > arises. The comment was also on the alignment/style. Take > URLCLassLoader(URL[], ClassLoader) for example, the existing > SecurityException has its description aligned under SecurityException > whereas the new NullPointerException wraps around. So my overall comment > here was to avoid mixing styles (it doesn't matter too much which style > is used, just keep it consistent for future maintainers). Right, these classes are prime for stylistic clean up early in 9. For now, keep things locally consistent ( even if that is old style ). -Chris. [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9f57d2774603/src/share/classes/java/lang/ThreadGroup.java > > In the test then it might be better to change the @summary line to only > include the second paragraph (the bug summary is not interesting, > especially when it references a test that is not in OpenJDK). > > -Alan. > From michael.fang at oracle.com Tue Oct 8 16:44:00 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 08 Oct 2013 16:44:00 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20131008164405.D673462E49@hg.openjdk.java.net> Changeset: dbecbb685503 Author: mfang Date: 2013-10-08 09:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbecbb685503 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java Changeset: 1c074a0c2b97 Author: mfang Date: 2013-10-08 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c074a0c2b97 Merge From daniel.fuchs at oracle.com Tue Oct 8 17:19:00 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 08 Oct 2013 19:19:00 +0200 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Message-ID: <52543E84.5050109@oracle.com> Hi, Please find below a fix for: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. This is a clarification of the implementation of the ServiceLoader.iterator() method, as well as non normative advice for ClassLoader subclasses overriding getResource() or getResources() to consider overriding the other method in order to keep them consistent with each other. best regards, -- daniel From cowwoc at bbs.darktech.org Tue Oct 8 18:17:07 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 08 Oct 2013 14:17:07 -0400 Subject: Debug builds In-Reply-To: <52543C37.3090104@gmail.com> References: <52543C37.3090104@gmail.com> Message-ID: <52544C23.2040509@bbs.darktech.org> Alex clarified the difference between FULL_DEBUG_SYMBOLS and DEBUG_CLASSFILES below (thank you!) Based upon this, I am asking Oracle to ship DEBUG_CLASSFILES=true as part of the public JDK. Can someone from Oracle please comment on this? Thanks, Gili -------- Original Message -------- Subject: Re: Debug builds Date: Tue, 08 Oct 2013 21:09:11 +0400 From: Alex Kasko To: cowwoc Hi, I wrote email to the list but decided to send it to you offlist instead (because it's your thread about debug).Feel free to forward it (or its parts) to the list if you want. On 10/08/2013 06:52 PM, cowwoc wrote: > Hi Volker, > > Thanks for the clarification. I have been able to ascertain that > adding full debug symbols to rt.jar would grow the file by 12MB > (uncompressed, probably much smaller after you run PACK200). I'll try to clarify the question concerning debugging terminology. Please correct me if I am wrong. This is all about jdk7. "Full debug symbols" build switch: FULL_DEBUG_SYMBOLS=1 It adds '.diz' files with zipped debug symbols for all native binaries. "Classfiles' debug symbols" build switch: DEBUG_CLASSFILES=true It adds debug symbols to compiled java classes in rt.jar and others. "Full debug symbols" and "classfiles' debug symbols" are completely independent of each other. Information about full debug symbols in Oracle builds is not clear because of this email - http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html According to it "promoted" builds must have FDS. At the same time openjdk7 build that was released on java.net on the "promoted" url - http://download.java.net/openjdk/jdk7/promoted/b146/jcp_bcl/ does not have FDS. Builds on java.com do not have FDS too but they are not the part of OpenJDK so maybe it's incorrect to ask about them here. I think initial question was about "classfiles' debug symbols". > The > debugging symbols for native code probably cost a lot more than that. > > Any idea on why rt.jar does not contain full debug symbols in the > JDK? If I open a bug report for this, is anyone willing to push this > through the system? > > Thanks, > Gili > > On 08/10/2013 6:03 AM, Volker Simonis wrote: >> Hi Gili, >> >> the mail threads you mention in your mail refer to debugging symbols >> in the native VM implementation (i.e. libjvm.so) and not to debug >> symbols in the java classes in rt.jar. >> >> Regards, >> Volker >> >> >> >> On Mon, Oct 7, 2013 at 7:45 PM, cowwoc > > wrote: >> >> On 07/10/2013 1:35 PM, Steven Schlansker wrote: >> >> On Oct 7, 2013, at 8:30 AM, cowwoc > > wrote: >> >> Hi, >> >> Where did the old debug builds of rt.jar go (meaning, >> rt.jar with full debug symbols, even for local variables)? >> I scanned the mailing list for a related discussion but >> couldn't find anything. It looks like somewhere down the >> line a decision was made to remove these builds, but it's >> not clear why that was. Also, out of curiosity, what is >> the overhead of the full debug symbols (versus what we >> ship now)? Couldn't we ship a full-debug rt.jar with the >> JDK and ship the smaller rt.jar with the JRE? >> >> +1 on shipping debug builds with the JDK, that would be very >> helpful for those of us who are stupid^Wcurious enough to >> step-debug into JDK classes. >> >> >> I have personally wasted countless days/weeks/months debugging >> problems that would have been solved much quicker by having full >> debug symbols. Furthermore, as you can see at >> >> http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.html >> the GNU/Linux world also ships with full debug symbols by default. >> >> I'd like to take this opportunity to follow-up on >> >> http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. >> >> I am confused because this post seems to be saying that Oracle JDK >> 7 ships full debug symbols, but in my experience this is not the >> case. It would be good to get some answers from someone in the know. >> >> Thanks, >> Gili >> >> > -- Regards, Alex Kasko From dan.xu at oracle.com Tue Oct 8 18:24:30 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 08 Oct 2013 11:24:30 -0700 Subject: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path Message-ID: <52544DDE.8080703@oracle.com> Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan From dalibor.topic at oracle.com Tue Oct 8 18:30:58 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 08 Oct 2013 20:30:58 +0200 Subject: Debug builds In-Reply-To: <52544C23.2040509@bbs.darktech.org> References: <52543C37.3090104@gmail.com> <52544C23.2040509@bbs.darktech.org> Message-ID: <52544F62.9040908@oracle.com> On 10/8/13 8:17 PM, cowwoc wrote: > > Alex clarified the difference between FULL_DEBUG_SYMBOLS and DEBUG_CLASSFILES below (thank you!) > > Based upon this, I am asking Oracle to ship DEBUG_CLASSFILES=true as part of the public JDK. Can someone from Oracle please comment on this? Not an OpenJDK issue - forums.oracle.com may be a better place for that. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From cowwoc at bbs.darktech.org Tue Oct 8 19:33:28 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 08 Oct 2013 15:33:28 -0400 Subject: Debug builds In-Reply-To: <52545C27.9040507@oracle.com> References: <52543C37.3090104@gmail.com> <52544C23.2040509@bbs.darktech.org> <52544F62.9040908@oracle.com> <5254547F.8090408@bbs.darktech.org> <52545C27.9040507@oracle.com> Message-ID: <52545E08.3090502@bbs.darktech.org> On 08/10/2013 3:25 PM, Dalibor Topic wrote: > On 10/8/13 8:52 PM, cowwoc wrote: >> Dalibor, >> >> I don't think anyone from Oracle reads those forums or has the authority to make this change. Isn't there a better way for me to bring this up? > Well, you could file a bug report instead, if you believe that to be a defect. But keep in mind that https://bugs.openjdk.java.net/browse/JDK-7133254 already exists, so unless you have a different angle on it, it may be better to just track this bug for changes, if any. > > cheers, > dalibor topic > Ah! I didn't know this issue existed. Okay, I'll keep my eye open for changes. (I wish the bug tracker was open to the public because I can't "Watch" the issue without an account). Thanks, Gili From ivan.gerasimov at oracle.com Tue Oct 8 19:43:07 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 08 Oct 2013 23:43:07 +0400 Subject: [7u-dev] Request for review of backport 7147084 In-Reply-To: <5242EA3F.7040307@oracle.com> References: <52415B60.5050608@oracle.com> <5242EA3F.7040307@oracle.com> Message-ID: <5254604B.1080206@oracle.com> Alan, Rob, Martin, Would you please help review the backport? I see you were the reviewers for the master fix. I need a review for the backport, since the patch couldn't get applied cleanly. Here are the changes I had to make: - I had to manually replace Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle it automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Thanks in advance, Ivan On 25.09.2013 17:50, Ivan Gerasimov wrote: > Hello! > > May I please have a review for a backport of the fix for 7147084 to > jdk7u-dev? > > This webrev does not include fix 8007454 anymore, as it has already > been pushed. > http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/ > > Thanks in advance, > Ivan Gerasimov > > > -------- Original Message -------- > Subject: Re: [7u-dev] Request for approval for CRs 8007454, 7147084 > Date: Tue, 24 Sep 2013 10:29:04 +0100 > From: Se?n Coffey > To: Ivan Gerasimov > CC: jdk7u-dev at openjdk.java.net > > > > On 24/09/2013 10:25, Ivan Gerasimov wrote: >> Thanks Se?n! >> >> Then I'll ask for an approval to backport 8007454, which is applied >> cleanly. > Consider both bugs fixes approved. You could use this mail thread to > review the 7147084 changes if you want. They're innocent enough. Alan or > someone else should be able to review. > > regards, > Sean. >> And once it is pushed, I'll initiate a review for 7147084 with >> adjustments. >> >> Sincerely, >> Ivan >> >> On 24.09.2013 12:59, Se?n Coffey wrote: >>> Approved for jdk7u-dev but you'll need a review first due to the >>> adjustments needed in the backport. >>> >>> Hopefully, you'll be resolving these issues with 2 different >>> changesets. It's been the trend in the past and helps keep changesets >>> more aligned to those in JDK 8. >>> >>> regards, >>> Sean. >>> >>> On 24/09/2013 09:08, Ivan Gerasimov wrote: >>>> Sending to the correct ML >>>> >>>> -------------- >>>> >>>> Hello! >>>> >>>> We have a request to backport fix for 7147084. >>>> >>>> First, it depends on the fix for 8007454, so the webrev includes it >>>> too. >>>> Second, the fix had to be adjusted a bit. >>>> - I had to manually replaced Java_java_lang_ProcessImpl_create() >>>> function body with the new version, as 'hg patch' could not handle >>>> automatically. >>>> - I had to replace wide-char strings to regular char*, in all the >>>> calls to win32Error() function. >>>> >>>> Combined webrev: >>>> http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/ >>>> >>>> BUGS: >>>> http://bugs.sun.com/view_bug.do?bug_id=7147084 >>>> http://bugs.sun.com/view_bug.do?bug_id=8007454 >>>> >>>> JDK8 Changesets: >>>> 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa >>>> 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d >>>> >>>> Reviews for jdk8 fix: >>>> >>>> 7147084: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html >>>> >>>> 8007454: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html >>>> >>>> >>>> I had set up a JPRT job, which completed successfully. >>>> All the .*jdk_lang.* test passed. >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>> >>> >>> >> > > > > > > > From sean.coffey at oracle.com Tue Oct 8 19:43:25 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Oct 2013 20:43:25 +0100 Subject: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path In-Reply-To: <52544DDE.8080703@oracle.com> References: <52544DDE.8080703@oracle.com> Message-ID: <5254605D.2040301@oracle.com> Looks fine to me Dan but I'm not a official reviewer. regards, Sean. On 08/10/2013 19:24, Dan Xu wrote: > Hi, > > This is a backport request towards 7u-dev repository on bug > JDK-8025128 that I fixed several days ago. It is going to keep the > method, File.createTempFile(), backward compatible. Please help review > it. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 > Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ > > -Dan From Alan.Bateman at oracle.com Tue Oct 8 19:43:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 20:43:49 +0100 Subject: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path In-Reply-To: <52544DDE.8080703@oracle.com> References: <52544DDE.8080703@oracle.com> Message-ID: <52546075.2050402@oracle.com> On 08/10/2013 19:24, Dan Xu wrote: > Hi, > > This is a backport request towards 7u-dev repository on bug > JDK-8025128 that I fixed several days ago. It is going to keep the > method, File.createTempFile(), backward compatible. Please help review > it. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 > Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ > > -Dan This looks like it's the same patch that is in jdk8 so it doesn't need to be reviewed again. Instead you just need to send an approval request to the jdk7u-dev list to request approval to push it there. The approval template page [1] has the list of things that need to be included in the request. One other thing to point out is that you don't have committer role on jdk7u so you are going to need a sponsor. I'm sure Se?n or one of the other maintainers will help on this. -Alan [1] http://openjdk.java.net/projects/jdk7u/approval-template.html From sean.coffey at oracle.com Tue Oct 8 19:49:08 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 08 Oct 2013 20:49:08 +0100 Subject: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path In-Reply-To: <52546075.2050402@oracle.com> References: <52544DDE.8080703@oracle.com> <52546075.2050402@oracle.com> Message-ID: <525461B4.6010304@oracle.com> Yes - no problem pushing the changeset for Dan once the approval request is logged and approved. regards, Sean. On 08/10/2013 20:43, Alan Bateman wrote: > On 08/10/2013 19:24, Dan Xu wrote: >> Hi, >> >> This is a backport request towards 7u-dev repository on bug >> JDK-8025128 that I fixed several days ago. It is going to keep the >> method, File.createTempFile(), backward compatible. Please help >> review it. Thanks! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 >> Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ >> >> -Dan > This looks like it's the same patch that is in jdk8 so it doesn't need > to be reviewed again. Instead you just need to send an approval > request to the jdk7u-dev list to request approval to push it there. > The approval template page [1] has the list of things that need to be > included in the request. > > One other thing to point out is that you don't have committer role on > jdk7u so you are going to need a sponsor. I'm sure Se?n or one of the > other maintainers will help on this. > > -Alan > > [1] http://openjdk.java.net/projects/jdk7u/approval-template.html From Alan.Bateman at oracle.com Tue Oct 8 19:51:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 20:51:50 +0100 Subject: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation In-Reply-To: <52531B54.1000802@gmail.com> References: <524C30FA.1010209@oracle.com>, <524C4A6A.4030105@oracle.com>, <524C4E90.9030205@oracle.com>, <524CFCFF.4030805@oracle.com> <20131004113935.633938@eggemoggin.niobe.net> <52514749.6050903@gmail.com> <5251EA8D.60507@gmail.com> <5252C0E9.8050804@oracle.com> <52531B54.1000802@gmail.com> Message-ID: <52546256.3070109@oracle.com> On 07/10/2013 21:36, Peter Levart wrote: > : > > Ask not what reference handler can do for you, ask what you can do > for reference handler! ;-) Indeed. > > : > } > > I get: > > sleep(1) takes 1079078 ns > sleep(2) takes 2058245 ns > sleep(3) takes 3060258 ns > sleep(4) takes 4060121 ns > sleep(5) takes 5061263 ns > sleep(6) takes 6063189 ns > sleep(7) takes 7075132 ns > sleep(8) takes 8071381 ns > sleep(9) takes 9062244 ns > ... > > ...which seems pretty accurate. Okay although I must admit that I didn't expect to see any difference up to 5 or 10ms (but it is of course highly platform/config specific). > : > >> >> A related piece of work is the FileChannel map implementation where >> there is a gc + retry if mmap fails. This could be changed to have a >> similar back-off/retry. >> > > I see. Would it make sense to do it in same patch or separately. This > too, will need JavaLangRefAccess.tryHandlePendingReference(), I think, > since it similarly ties unmap0 to a Cleaner referencing > MappedByteBuffer. The tryMap0 would just be a call to map0 with > catching of OOME and returning true/false, right? > > Do you happen to know what defines the limit of how many bytes or > blocks can be mapped at one time? Is this some parameter for VM or is > this just plain OS limit? It's okay to separate this into a separate patch, I was really just pointing out that we file mappings is another case where this could help. There isn't a limit for this in the JDK so it does depend on the OS. A tryMap as you suggest should be okay, alternatively we could change the native method to return 0 for the ENOMEM case. > : > > Ok then, I'll finish this nevertheless and then it can sit and wait > for JDK9. > I don't know when a jdk9 project will be proposed but I expect so very soon because we will all be holding onto patches after the ZBB date. -Alan. From brent.christian at oracle.com Tue Oct 8 19:55:34 2013 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 08 Oct 2013 12:55:34 -0700 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: References: <524DFE5C.1030705@oracle.com> <524E51E9.5060400@oracle.com> Message-ID: <52546336.4000606@oracle.com> I've beefed up the test case, as suggested by Alan and Paul. It tries removing at the start, middle, and end of the iteration. FWIW, all but one of the test scenarios pass even without the fix. The failing case is: checkDescItrRmMid(m.keySet(), m.navigableKeySet().descendingIterator()); (that is, remove an element from the middle of the iteration, the specific case of this bug). So most of the new tests are of code that is already correct, but IMO it doesn't hurt to make sure it stays correct. :) http://cr.openjdk.java.net/~bchristi/8024709/webrev.01/ Thanks, -Brent On 10/4/13 1:51 AM, Paul Sandoz wrote: > > On Oct 4, 2013, at 7:28 AM, Alan Bateman wrote: > >> On 03/10/2013 16:31, Brent Christian wrote: >>> Please review my fix for 8024709 : "TreeMap.DescendingKeyIterator 'remove' confuses iterator position" >>> >>> There are two possible code paths for performing a "descending" iteration over the elements in a TreeMep, depending on how the iteration is setup. >>> >>> For instance, >>> treemap.descendingKeySet().iterator(); >>> will use a >>> TreeMap.NavigableSubMap.DescendingSubMapIterator >>> This code correctly handles Iterator.remove(). >>> >>> On the other hand, >>> treemap.navigableKeySet().descendingIterator(); >>> will use a >>> TreeMap.DescendingKeyIterator. >>> This code does not correctly handle remove(), and results in a "confused" iterator. >>> >>> >>> TreeMap.DescendingKeyIterator should override remove() with code >>> similar to that in TreeMap.NavigableSubMap.SubMapIterator.removeDescending(). >>> >>> >>> Bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8024709 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8024709/webrev.00/ >> The remove looks right to me and next() should return the predecessor that is already set. >> > > Looks ok to me too. > > >> The test looks okay (although you might want to align the parameters to checkDescendingIteratorRemove), I just wonder if you would be worth generating additional cases to exercise this code a bit more. >> > > One could write a general test without having to pass in expicit values and if so i suspect it is better to pass in the ascending collection and descending iterator (since the toArray could be implemented using an iterator): > > void checkTraverse2Remove1Traverse1(Collection aC, Iterator dIt) { > T[] values = (T) aC.toArray(); > int n = values.length -1; > > equalNext(dIt, values[n--]); > equalNext(dIt, values[n--]); > it.remove(); > equalNext(dIt, values[n]); > } > > Might also be useful to have a test that removes the last traversed element. > > Paul. > From brian.burkhalter at oracle.com Tue Oct 8 20:05:09 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 8 Oct 2013 13:05:09 -0700 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> Message-ID: On Oct 4, 2013, at 1:33 AM, Paul Sandoz wrote: > On Oct 4, 2013, at 9:18 AM, Aleksey Shipilev wrote: > >> On 10/04/2013 03:34 AM, Brian Burkhalter wrote: >>> Here is an alternative solution:http://cr.openjdk.java.net/~bpb/7189139.2/. >> >> Seems OK with me, > > Same here. Based on previous comments by Aleksey and Paul I created this test http://cr.openjdk.java.net/~bpb/7189139/PrimeTest.java and ran it with the list of primes supplied by Aleksey, N=60000000, and certainty=100. This is the output: --- Primes: /Users/bpb/Desktop/primes-50M.txt N = 60000000 certainty = 100 3562115 probable primes out of 3562115 candidates Prime test = true Not-prime test = true Test succeeded! --- An updated webrev which differs only in having a correct Hg header is here: http://cr.openjdk.java.net/~bpb/7189139/webrev.2/ If this looks good to go, would a Reviewer please issue an approval? Thanks, Brian From Alan.Bateman at oracle.com Tue Oct 8 20:06:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Oct 2013 21:06:47 +0100 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. In-Reply-To: <52543E84.5050109@oracle.com> References: <52543E84.5050109@oracle.com> Message-ID: <525465D7.7060201@oracle.com> On 08/10/2013 18:19, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8024704: Improve API documentation of ClassLoader and ServiceLoader > with respect to enumeration of resources. > > > This is a clarification of the implementation of the > ServiceLoader.iterator() method, as well as non normative advice > for ClassLoader subclasses overriding getResource() or getResources() > to consider overriding the other method in order to keep them > consistent with each other. > > As background to others, the motive for this one stems from a small compatibility issue that arose with the JAXP changes to use ServiceLoader (it was previous foraging for service configuration files itself). The compatibility issue arises with ClassLoader implementations where getResource and getResources are inconsistent, and in the JAXP case uncovered a server that located an unexpected XML parser. Daniel - in the @apiNote on getResource it reads "the implementations ensure" where it should be "the implementation ensures" or "implementations should ensure". Otherwise the wording looks okay to me. Conventions haven't been established yet but I would think that @apiNote is a case where you can use the full line. -Alan. From martijnverburg at gmail.com Tue Oct 8 20:18:23 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 8 Oct 2013 21:18:23 +0100 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. In-Reply-To: <525465D7.7060201@oracle.com> References: <52543E84.5050109@oracle.com> <525465D7.7060201@oracle.com> Message-ID: As a mostly ;-) silent observer on this list I just wanted to say "Thank You" to everyone for continuing the diligent work to fix issues like this. I've seen a host of really useful small improvements go in recently (and docs definitely count as well) - it doesn't go unnoticed! Cheers, Martijn On 8 October 2013 21:06, Alan Bateman wrote: > On 08/10/2013 18:19, Daniel Fuchs wrote: > >> Hi, >> >> Please find below a fix for: >> >> 8024704: Improve API documentation of ClassLoader and ServiceLoader >> with respect to enumeration of resources. >> >> > >> >> This is a clarification of the implementation of the >> ServiceLoader.iterator() method, as well as non normative advice >> for ClassLoader subclasses overriding getResource() or getResources() >> to consider overriding the other method in order to keep them >> consistent with each other. >> >> >> > >> > As background to others, the motive for this one stems from a small > compatibility issue that arose with the JAXP changes to use ServiceLoader > (it was previous foraging for service configuration files itself). The > compatibility issue arises with ClassLoader implementations where > getResource and getResources are inconsistent, and in the JAXP case > uncovered a server that located an unexpected XML parser. > > Daniel - in the @apiNote on getResource it reads "the implementations > ensure" where it should be "the implementation ensures" or "implementations > should ensure". Otherwise the wording looks okay to me. Conventions haven't > been established yet but I would think that @apiNote is a case where you > can use the full > line. > > -Alan. > From xueming.shen at oracle.com Tue Oct 8 20:33:16 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Oct 2013 13:33:16 -0700 Subject: Deflater enhancements In-Reply-To: References: Message-ID: <52546C0C.8020502@oracle.com> The 100 in sample really means a "big enough" buffer here for simple use case, not necessarily means a "fixed size' buffer. Sure there is always room for doc improvement, especially given this is the API has been there for decade. Deflater/Inflater.end() is for explicitly/proactively release of the memory resource held by the deflater/inflater, it does not have impact to the deflating/inflating result. the end() will be invoked by the finalizer. It might be reasonable to simply have a pair of static utility methods byte[] Deflater.deflate(byte[]); byte[] Inflater.deflate(byte[]); For the casual/simple/easy use scenario. Sherman On 10/08/2013 03:24 AM, Stephen Colebourne wrote: > I've been trying to use Deflater today and found it rather tricky. Two > thoughts... > > 1) The class level Javadoc specifies a fixed size byte array of 100. > http://download.java.net/jdk8/docs/api/java/util/zip/Deflater.html > > > From what I can tell from other searching and basic common sense, this > cannot be right as the output size could well be bigger than 100. > However, there is no real information in the Deflater class as to how > the class is supposed to be used. I don't believe that kind of broken > example is helpful. > > The best I found was > http://java.dzone.com/articles/how-compress-and-uncompress > which proposed a loop: > Deflater deflater = new Deflater(); > deflater.setInput(data); > ByteArrayOutputStream outputStream = new ByteArrayOutputStream(data.length); > deflater.finish(); > byte[] buffer = new byte[1024]; > while (!deflater.finished()) { > int count = deflater.deflate(buffer); // returns the generated code... index > outputStream.write(buffer, 0, count); > } > outputStream.close(); > byte[] output = outputStream.toByteArray(); > > Neither example call deflater.end(), which I believe to be a mistake as well. > > Is my analysis correct? Should I raise a bug for better documentation? > (this appears to affect Inflater as well) > > 2) Even with the Javadoc change, the API is still far too complex. > > As a user, all I want is something like: > byte[] compressed = Deflater.deflate(input, options...) > and similar for Inflater. > > (I actually want to compress a String, and an override to handle that > would be useful as well) > > Any thoughts on adding a convenience method to make the API a lot > easier? Can I raise a bug for that? > > Stephen From brian.burkhalter at oracle.com Tue Oct 8 20:50:55 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 8 Oct 2013 13:50:55 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <5253C781.5070600@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> <5253C781.5070600@oracle.com> Message-ID: <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> On Oct 8, 2013, at 1:51 AM, Chris Hegarty wrote: > This looks much better. > > loadfactor and size validation look good, and in line with the original suggestion in the bug. > > For the initial capacity what was originally suggested was to use a similar technique to that of HashMap.readObject ( to ensure that the table never needs to be rehashed during load, and ends up being at least 25% full). Snippet from the bug: > > int capacity = (int)Math.min(size * Math.min(1 / loadFactor, 4.0f), > HashMap.MAXIMUM_CAPACITY); > > I'm curious why you have not taken that suggestion? What you have looks ok, but it does reply on reasonable capacity and loadfactor values. I saw that suggestion. I was trying insofar as possible to use the field values as serialized. After reading your comments above however I think that the suggestion is better. I have updated the webrev accordingly http://cr.openjdk.java.net/~bpb/8016252/webrev.3/ Note that this is a new URL. > I have not looked in any detail at the test, but the file should start with the copyright/header, and not the import statements. Fixed - thanks. On Oct 8, 2013, at 2:14 AM, Alan Bateman wrote: > This looks better, the checks on loadFactor and size look okay. > > I don't know all the history on this bug but it looks like the goal was partly to avoid resizing when deserializing. This means the capacity could match HashMap. To be consistent with the size check then we could throw an exception if the capacity is negative (interesting case for tests and malware only). Negative capacity check added in the updated webrev.3. > I skimmed over the test but it doesn't appear to exercise anything new. If you want to exercise the checks then it would require deserializing from a byte stream that results in bad loadFactor, size and capacity values. It might not be worth it of course. No, it does not exercise anything new. I actually did try inserting random garbage into the written-out byte stream, but without knowing where to do so to affect the fields of interest it is rather useless and causes totally unpredictable results. I don't know that this test really needs to be included with the patch. Thanks, Brian From dan.xu at oracle.com Tue Oct 8 20:58:08 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 08 Oct 2013 13:58:08 -0700 Subject: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path In-Reply-To: <525461B4.6010304@oracle.com> References: <52544DDE.8080703@oracle.com> <52546075.2050402@oracle.com> <525461B4.6010304@oracle.com> Message-ID: <525471E0.4060300@oracle.com> Sean and Alan, Thanks for the instructions. I just sent out the request to jdk7u-dev mailing list. -Dan On Tue 08 Oct 2013 12:49:08 PM PDT, Se?n Coffey wrote: > Yes - no problem pushing the changeset for Dan once the approval > request is logged and approved. > > regards, > Sean. > > On 08/10/2013 20:43, Alan Bateman wrote: >> On 08/10/2013 19:24, Dan Xu wrote: >>> Hi, >>> >>> This is a backport request towards 7u-dev repository on bug >>> JDK-8025128 that I fixed several days ago. It is going to keep the >>> method, File.createTempFile(), backward compatible. Please help >>> review it. Thanks! >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 >>> Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ >>> >>> -Dan >> This looks like it's the same patch that is in jdk8 so it doesn't >> need to be reviewed again. Instead you just need to send an approval >> request to the jdk7u-dev list to request approval to push it there. >> The approval template page [1] has the list of things that need to be >> included in the request. >> >> One other thing to point out is that you don't have committer role on >> jdk7u so you are going to need a sponsor. I'm sure Se?n or one of the >> other maintainers will help on this. >> >> -Alan >> >> [1] http://openjdk.java.net/projects/jdk7u/approval-template.html > From brian.burkhalter at oracle.com Tue Oct 8 21:29:51 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 8 Oct 2013 14:29:51 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <525389DD.8000608@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <525389DD.8000608@oracle.com> Message-ID: I have posted an updated webrev http://cr.openjdk.java.net/~bpb/7179567/webrev.3/ which I hope addresses all the concerns expressed below. Please see also my comments in line. Once this looks acceptable I can do the CCC request. Thanks, Brian On Oct 7, 2013, at 9:28 PM, David Holmes wrote: > Aside: I'm confused about the relationship of this bug and JDK-6445180 - are they not duplicates? Seems to me this one should have been closed as a dup when it was reported. I think you are correct. I can adjust this once the webrev is approved. > On 5/10/2013 6:58 AM, Brian Burkhalter wrote: >> On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: >> >>> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: >>> >>>> On 03/10/2013 16:10, Brian Burkhalter wrote: >>>>> Please review and comment at your convenience. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>>>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ >> >> An updated webrev which I hope adequately addresses the expressed concerns may be found at: >> >> http://cr.openjdk.java.net/~bpb/7179567.2/ > > URLClassLoader.java: please delete the commented out line: > > + //Objects.requireNonNull(urls); I already fixed that but had not updated the webrev. > SecureClassLoader.java: > > 186 * @throws SecurityException if the {@code ClassLoader} instance is not > 187 * initialized. > > should read "this classloader instance" as it refers to the current instance. Also this may be bringing the spec into line with the implementation but "initialization" here is purely an implementation detail not part of the specification for this class so it should not be mentioned explicitly - and this change still needs a CCC (which might help determine exactly what should be said here - I'm unclear how you can try to call getPermissions if this is uninitialized as it would need 'this' to escape from the constructor - which perhaps it can do via a third-party security manager?). I've removed this @throws clause. > NoCallStackClassLoader.java: the comment is far too verbose, we don't write such explanatory kinds of comments for this kind of thing (else the code would be overrun with commentary!). Shortened. > Aside: if you are a JDK Author you don't need a Contributed-by line in the commit comments. Removed. On Oct 8, 2013, at 4:08 AM, Alan Bateman wrote: > This looks much better. > > If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. > > My previous comment on @throws vs. @exception was just to keep things consistent as this is old code and would look odd for a method to use both. Our preference is to switch to @throws whenever the opportunity arises. The comment was also on the alignment/style. Take URLCLassLoader(URL[], ClassLoader) for example, the existing SecurityException has its description aligned under SecurityException whereas the new NullPointerException wraps around. So my overall comment here was to avoid mixing styles (it doesn't matter too much which style is used, just keep it consistent for future maintainers). > > In the test then it might be better to change the @summary line to only include the second paragraph (the bug summary is not interesting, especially when it references a test that is not in OpenJDK). Updated. On Oct 8, 2013, at 8:53 AM, Chris Hegarty wrote: > Yes, this is much nicer. > > I'd be tempted to write another private constructor, taking all args, and checking params with checkForNullURLs before invoking, similar to ThreadGroup [1] L117, for example. But that is just clean up to remove some duplication. No need to do this. > >> If I read the code correctly then the long standing behavior of >> URLClassLoader.getPermissions(null) was to throw a NPE, now it is >> changed to return the empty collection in order to match the super type >> (SecureClassLoader). I can't think of anything that would break so this >> is probably okay, just maybe a bit surprising. > > Agreed. > >> My previous comment on @throws vs. @exception was just to keep things >> consistent as this is old code and would look odd for a method to use >> both. Our preference is to switch to @throws whenever the opportunity >> arises. The comment was also on the alignment/style. Take >> URLCLassLoader(URL[], ClassLoader) for example, the existing >> SecurityException has its description aligned under SecurityException >> whereas the new NullPointerException wraps around. So my overall comment >> here was to avoid mixing styles (it doesn't matter too much which style >> is used, just keep it consistent for future maintainers). > > Right, these classes are prime for stylistic clean up early in 9. For now, keep things locally consistent ( even if that is old style ). > > > -Chris. > > [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9f57d2774603/src/share/classes/java/lang/ThreadGroup.java From rob.mckenna at oracle.com Tue Oct 8 23:12:59 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 08 Oct 2013 23:12:59 +0000 Subject: hg: jdk8/tl/jdk: 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Message-ID: <20131008231322.E3E2662E6A@hg.openjdk.java.net> Changeset: f1e31376f419 Author: robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c From mike.duigou at oracle.com Wed Oct 9 00:04:59 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Oct 2013 17:04:59 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> Message-ID: On Oct 8 2013, at 01:27 , Paul Sandoz wrote: > Hi Mike, > > I am probably going over old ground here... Not a problem, I don't think this particular aspect has received as much attention as it probably should > Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry The retry behaviour in particular doesn't seem to be appropriate for the general Map defaults. The concurrent modification detection at this point is mostly a result of (supposed) invariant checks failing. > or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. Right, the behaviour is not consistent across all of the Map methods. Some do a better job than others of detecting concurrent modification. > Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? Yes, > > The defaults on Map could state they are not suitable for maps that can be concurrently modified, They probably should do so. > if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) Yes, there are cases where this can happen. > I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? For the ConcurrentMap implementations I've written the defaults to explicitly assume that null values are not supported (there's @implNote documentation of this assumption) Mike > > Paul. > > On Oct 4, 2013, at 5:35 AM, Mike Duigou wrote: > >> Hello all; >> >> This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. >> >> The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ >> >> Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. >> >> Mike > From mandy.chung at oracle.com Wed Oct 9 00:39:13 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Oct 2013 17:39:13 -0700 Subject: Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Message-ID: <5254A5B1.6040206@oracle.com> This fixes Level.parse to return the custom Level instance. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.00/ When a custom Level is created, a mirrored level instance (containing the same value as the custom Level) is created and used by the logging implementation. Only the custom level should be added to the known level list from which Level.parse will look up. Thanks Mandy From joe.darcy at oracle.com Wed Oct 9 00:57:40 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Oct 2013 17:57:40 -0700 Subject: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported In-Reply-To: <20131004103043.409454@eggemoggin.niobe.net> References: <524E638C.6090302@oracle.com> <20131004103043.409454@eggemoggin.niobe.net> Message-ID: <5254AA04.30901@oracle.com> On 10/04/2013 10:30 AM, mark.reinhold at oracle.com wrote: > 2013/10/3 16:43 -0700, joe.darcy at oracle.com: >> Per previous discussions on the mailing list, we've decided to rename >> the annotation type "jdk.Supported" to "jdk.Exported". >> >> ... > Looks good to me. > > One question, though: Is it intended that one use of this annotation > can be overridden by another at a deeper lexical level? For example: > > @Supported > public class X { > > @Supported(false) > public static class Y { > } > > } I would say that is most likely a logical error to have inconsistent exported-ness on a top-level and its nested types, but it is an extra-linguistic correctness issue for the semantics we want to impose on this annotation. Conceivably, such an inconsistency could arise if for some reason a nested type was slated for removal in the future but the containing type was not. > > Equivalently, imagine @Supported in a package-info.java file and > @Supported(false) on a type within that package. At the package level, I'd say the package-info file should have the prevailing exported-ness of the types in that package, but sometimes there are a few bad types and the rest should stay. > > If so then it'd be helpful to mention this possibility in the > specification. > I'll add some guidance on these points. Thanks, -Joe From joe.darcy at oracle.com Wed Oct 9 01:56:55 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Oct 2013 18:56:55 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Message-ID: <5254B7E7.6040709@oracle.com> Hello, Please review the patch below which addresses JDK-8024354 Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Thanks, -Joe diff -r f1e31376f419 src/share/classes/java/util/DoubleSummaryStatistics.java --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct 09 00:10:02 2013 +0100 +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct 08 18:54:55 2013 -0700 @@ -118,6 +118,11 @@ * value is a {@code NaN} or the sum is at any point a {@code NaN} then the * sum will be {@code NaN}. * + * @implNote This method may be implemented using compensated + * summation or other technique to reduce the error bound in the + * numerical sum compared to a simple summation of {@code double} + * values. + * * @return the sum of values, or zero if none */ public final double getSum() { @@ -161,6 +166,10 @@ * value is a {@code NaN} or the sum is at any point a {@code NaN} then the * average will be {@code NaN}. * + * @implNote This method may be implemented using compensated + * summation or other technique to reduce the error bound in the + * numerical sum used to compute the average. + * * @return the arithmetic mean of values, or zero if none */ public final double getAverage() { From mike.duigou at oracle.com Wed Oct 9 03:08:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Oct 2013 20:08:43 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <5254B7E7.6040709@oracle.com> References: <5254B7E7.6040709@oracle.com> Message-ID: <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> This seems to contradict the main documentation for these methods. Perhaps instead we should remove the "The average returned can vary depending upon the order in which values are recorded. This is due to accumulated rounding error in addition of values of differing magnitudes. Values sorted by increasing absolute magnitude tend to yield more accurate results." into an @implNote? I also suspect that having this documentation only in DoubleSummaryStatistics may be too hidden away. Perhaps similar docs on DoubleStream sum() and average() methods as well? Mike On Oct 8 2013, at 18:56 , Joe Darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8024354 Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation > > Thanks, > > -Joe > > diff -r f1e31376f419 src/share/classes/java/util/DoubleSummaryStatistics.java > --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct 09 00:10:02 2013 +0100 > +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct 08 18:54:55 2013 -0700 > @@ -118,6 +118,11 @@ > * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > * sum will be {@code NaN}. > * > + * @implNote This method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum compared to a simple summation of {@code double} > + * values. > + * > * @return the sum of values, or zero if none > */ > public final double getSum() { > @@ -161,6 +166,10 @@ > * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > * average will be {@code NaN}. > * > + * @implNote This method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum used to compute the average. > + * > * @return the arithmetic mean of values, or zero if none > */ > public final double getAverage() { > From mike.duigou at oracle.com Wed Oct 9 03:38:41 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Oct 2013 20:38:41 -0700 Subject: RFR: 8025910 : (s) rename substream(long) -> skip and substream(long, long) -> slice Message-ID: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> Hello all; Based upon feedback from the JavaOne Hands-On-Lab and other sources the 335 EG has decided to rename the two substream methods in the Streams interfaces to skip and slice. Webrev: http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/webrev/ and the specdiff: http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/specdiff/overview-summary.html Thanks, Mike From henry.jen at oracle.com Wed Oct 9 05:57:28 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 08 Oct 2013 22:57:28 -0700 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation Message-ID: <5254F048.1090802@oracle.com> Hi, Please review updated webrev at http://cr.openjdk.java.net/~henryjen/ccc/8023524/6/webrev In this update, - Check the specified directory once, disable dumping if it is invalid. This address the comment of unnecessary complexity, as this is a debug feature and most likely developer would like to restart. - minimum doPrivilege permission - Install security manager in test to verify doPrivilege Cheers, Henry From joel.franck at oracle.com Wed Oct 9 07:08:53 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 09 Oct 2013 07:08:53 +0000 Subject: hg: jdk8/tl/langtools: 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Message-ID: <20131009070900.731AD62E73@hg.openjdk.java.net> Changeset: ea000904db62 Author: alundblad Date: 2013-10-08 15:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ea000904db62 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Summary: Fixed precedence and associativity issues with pretty printing of JCConditional expressions. Reviewed-by: jfranck Contributed-by: Andreas Lundblad , Matthew Dempsky ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/T8024415.java From joe.darcy at oracle.com Wed Oct 9 07:18:07 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Oct 2013 00:18:07 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> Message-ID: <5255032F.9070709@oracle.com> On 10/08/2013 08:08 PM, Mike Duigou wrote: > This seems to contradict the main documentation for these methods. The general guidance is still valid, bug we want to allow algorithms with better worst-case behavior than simple summation. (I didn't think it would be helpful for most readers to start talking about error bounds or to otherwise explain the desired quality of implementation constraints on the behavior of the method.) > Perhaps instead we should remove the "The average returned can vary depending upon the order in which values are recorded. This is due to accumulated rounding error in addition of values of differing magnitudes. Values sorted by increasing absolute magnitude tend to yield more accurate results." into an @implNote? > > I also suspect that having this documentation only in DoubleSummaryStatistics may be too hidden away. Perhaps similar docs on DoubleStream sum() and average() methods as well? Numerically, using similar techniques in DoubleStream is preferable, but specification like /** * Returns the sum of elements in this stream. The sum returned can vary * depending upon the order in which elements are encountered. This is due * to accumulated rounding error in addition of values of differing * magnitudes. Elements sorted by increasing absolute magnitude tend to * yield more accurate results. If any stream element is a {@code NaN} or * the sum is at any point a {@code NaN} then the sum will be {@code NaN}. * This is a special case of a * reduction and is * equivalent to: * 

{@code
      *     return reduce(0, Double::sum);
      * }
* *

This is a terminal * operation. * * @return the sum of elements in this stream */ double sum(); would need to be updated. -Joe > > Mike > > On Oct 8 2013, at 18:56 , Joe Darcy wrote: > >> Hello, >> >> Please review the patch below which addresses >> >> JDK-8024354 Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation >> >> Thanks, >> >> -Joe >> >> diff -r f1e31376f419 src/share/classes/java/util/DoubleSummaryStatistics.java >> --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct 09 00:10:02 2013 +0100 >> +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct 08 18:54:55 2013 -0700 >> @@ -118,6 +118,11 @@ >> * value is a {@code NaN} or the sum is at any point a {@code NaN} then the >> * sum will be {@code NaN}. >> * >> + * @implNote This method may be implemented using compensated >> + * summation or other technique to reduce the error bound in the >> + * numerical sum compared to a simple summation of {@code double} >> + * values. >> + * >> * @return the sum of values, or zero if none >> */ >> public final double getSum() { >> @@ -161,6 +166,10 @@ >> * value is a {@code NaN} or the sum is at any point a {@code NaN} then the >> * average will be {@code NaN}. >> * >> + * @implNote This method may be implemented using compensated >> + * summation or other technique to reduce the error bound in the >> + * numerical sum used to compute the average. >> + * >> * @return the arithmetic mean of values, or zero if none >> */ >> public final double getAverage() { >> From daniel.fuchs at oracle.com Wed Oct 9 07:38:48 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Oct 2013 09:38:48 +0200 Subject: Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level In-Reply-To: <5254A5B1.6040206@oracle.com> References: <5254A5B1.6040206@oracle.com> Message-ID: <52550808.3090706@oracle.com> On 10/9/13 2:39 AM, Mandy Chung wrote: > This fixes Level.parse to return the custom Level instance. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.00/ > > When a custom Level is created, a mirrored level instance (containing > the same value as the custom Level) is created and used by the logging > implementation. Only the custom level should be added to the known > level list from which Level.parse will look up. > > Thanks > Mandy Hi Mandy, This looks good - but I think you could move the changes line 554-562 and put them back inside the KnownLevel constructor where they were before. This would allow you to keep mirroredLevel final. Small nit: the name 'custom' is a misnomer - as it will be true for both standard and custom levels... Concerning the test I don't think you need to copy the property file to test.classes, because I believe jprt puts test.src inside the classpath. (another possibility would be to use a custom subclass of ListResourceBundle instead) Finally, I think that test needs to be run in main/othervm mode - otherwise it might fail intermittently... best regards, -- daniel From ivan.gerasimov at oracle.com Wed Oct 9 07:47:36 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Oct 2013 11:47:36 +0400 Subject: [7u-dev] Request for review of backport 7147084 In-Reply-To: <5242EA3F.7040307@oracle.com> References: <52415B60.5050608@oracle.com> <5242EA3F.7040307@oracle.com> Message-ID: <52550A18.50501@oracle.com> Alan, Rob, Martin, Would you please help review the backport? I see that you were the reviewers for the master fix. I need a review for the backport, since the patch couldn't get applied cleanly. Here are the changes I had to make: - I had to manually replace Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle it automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Thanks in advance, Ivan On 25.09.2013 17:50, Ivan Gerasimov wrote: > Hello! > > May I please have a review for a backport of the fix for 7147084 to > jdk7u-dev? > > This webrev does not include fix 8007454 anymore, as it has already > been pushed. > http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/ > > Thanks in advance, > Ivan Gerasimov > > > -------- Original Message -------- > Subject: Re: [7u-dev] Request for approval for CRs 8007454, 7147084 > Date: Tue, 24 Sep 2013 10:29:04 +0100 > From: Se?n Coffey > To: Ivan Gerasimov > CC: jdk7u-dev at openjdk.java.net > > > > On 24/09/2013 10:25, Ivan Gerasimov wrote: >> Thanks Se?n! >> >> Then I'll ask for an approval to backport 8007454, which is applied >> cleanly. > Consider both bugs fixes approved. You could use this mail thread to > review the 7147084 changes if you want. They're innocent enough. Alan or > someone else should be able to review. > > regards, > Sean. >> And once it is pushed, I'll initiate a review for 7147084 with >> adjustments. >> >> Sincerely, >> Ivan >> >> On 24.09.2013 12:59, Se?n Coffey wrote: >>> Approved for jdk7u-dev but you'll need a review first due to the >>> adjustments needed in the backport. >>> >>> Hopefully, you'll be resolving these issues with 2 different >>> changesets. It's been the trend in the past and helps keep changesets >>> more aligned to those in JDK 8. >>> >>> regards, >>> Sean. >>> >>> On 24/09/2013 09:08, Ivan Gerasimov wrote: >>>> Sending to the correct ML >>>> >>>> -------------- >>>> >>>> Hello! >>>> >>>> We have a request to backport fix for 7147084. >>>> >>>> First, it depends on the fix for 8007454, so the webrev includes it >>>> too. >>>> Second, the fix had to be adjusted a bit. >>>> - I had to manually replaced Java_java_lang_ProcessImpl_create() >>>> function body with the new version, as 'hg patch' could not handle >>>> automatically. >>>> - I had to replace wide-char strings to regular char*, in all the >>>> calls to win32Error() function. >>>> >>>> Combined webrev: >>>> http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/ >>>> >>>> BUGS: >>>> http://bugs.sun.com/view_bug.do?bug_id=7147084 >>>> http://bugs.sun.com/view_bug.do?bug_id=8007454 >>>> >>>> JDK8 Changesets: >>>> 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa >>>> 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d >>>> >>>> Reviews for jdk8 fix: >>>> >>>> 7147084: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html >>>> >>>> 8007454: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html >>>> >>>> >>>> I had set up a JPRT job, which completed successfully. >>>> All the .*jdk_lang.* test passed. >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>> >>> >>> >> > > > > > > > From heinz at javaspecialists.eu Wed Oct 9 07:47:56 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Wed, 09 Oct 2013 10:47:56 +0300 Subject: Time to put a stop to Thread.stop? In-Reply-To: <51B723D6.8060509@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> <51A0A1E8.1000604@oracle.com> <51B723D6.8060509@oracle.com> Message-ID: <52550A2C.7050308@javaspecialists.eu> Alan Bateman wrote: > On 25/05/2013 12:35, Alan Bateman wrote: >> On 24/05/2013 19:14, Martin Buchholz wrote: >>> : >>> >>> Alan, you're telling everyone there's no need for Thread.stop, but >>> you are replacing usages in tests with calls to Unsafe, which is not >>> available to normal code. So you have a kind of moral obligation >>> here to replace usages with "ordinary" java code. There are other >>> ways to do sneakyThrow, and perhaps a sneakyRethrow method should be >>> added to the jdk test library. >> For these the tests then it shouldn't really matter but if you or >> Doug would prefer if they are changed to use sneakyThrow then we can >> do that. > Martin has pushed updates to the 4 tests to the jsr166 CVS so I'll > going to push these to jdk8/tl forest along with the Thread.stop changes. I noticed the other day when using Java 8 that Thread.stop(Throwable) was throwing an UOE. Unfortunately I missed the discussion in May amongst the thousands of other important JDK emails. Thus I presume that nothing I might have to say on the matter would change what is currently in the OpenJDK ;-) But I'd like to state it "for the record" anyway. Throwing checked exceptions in an unchecked context is, IMHO, something one should almost never do, except maybe in test cases. Up to now, I've known of quite a few ways to do this though: 1. Thread.stop(Throwable) with some mangling - see ThrowerConcurrent in http://www.javaspecialists.eu/archive/Issue144.html 2. Abusing generics 3. Class.newInstance(), described in Java Puzzlers (http://www.javaspecialists.eu/archive/Issue144.html) 4. Unsafe.throwException() similar to ThrowerConcurrent in #1. Since this is something that we should not do anyway, it is no harm to remove one of the ways, this being Thread.stop(Throwable). However, there is another use case. If you cause a deadlock with ReentrantLock, you might be able to bust out of that by sending a DeadlockVictimError to one of the threads in the deadlock. This would not work for threads deadlocked with synchronized. I agree this is a rare situation and we should rather avoid the deadlock. But it is useful to be able to do it. Here are two newsletters where I write about this: http://www.javaspecialists.eu/archive/Issue130.html http://www.javaspecialists.eu/archive/Issue160.html Now it is enough of an edge case that I can accept using Unsafe.throwException() as being the "proper" solution. Since it is "unsafe", we might as well use that mechanism. However, it is yet another temptation to use Unsafe, which, of course, we should avoid, seeing that it is, ahem, "unsafe" ;-) Regards Heinz From aleksey.shipilev at oracle.com Wed Oct 9 07:50:17 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Oct 2013 11:50:17 +0400 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> Message-ID: <52550AB9.8020808@oracle.com> On 10/09/2013 12:05 AM, Brian Burkhalter wrote: > Based on previous comments by Aleksey and Paul I created this test > > http://cr.openjdk.java.net/~bpb/7189139/PrimeTest.java > > and ran it with the list of primes supplied by Aleksey, N=60000000, and certainty=100. This is the output: > > --- > Primes: /Users/bpb/Desktop/primes-50M.txt > N = 60000000 > certainty = 100 > 3562115 probable primes out of 3562115 candidates > Prime test = true > Not-prime test = true > Test succeeded! Awesome, thanks! > An updated webrev which differs only in having a correct Hg header is here: > > http://cr.openjdk.java.net/~bpb/7189139/webrev.2/ Thumbs up for the fix. -Aleksey. From ivan.gerasimov at oracle.com Wed Oct 9 08:10:41 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Oct 2013 12:10:41 +0400 Subject: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed Message-ID: <52550F81.4020203@oracle.com> Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though the leak was eliminated. I couldn't ever reproduce the failure even on the machines where the failure was detected. Here are the changes I propose: - Increase number of both warm-up and measured iterations, - Number of iterations now indicates how many times a single interface is probed. It used to probe all the interfaces that many times. - Increase the memory consumption threshold - Increase the timeout These should add some confidence that the failure of the test really indicates a memory leak. In addition to that, in the case of a failure the list of all the network interfaces is displayed, so there will be some more information about the environment. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ Sincerely yours, Ivan Gerasimov From mandy.chung at oracle.com Wed Oct 9 08:18:33 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Oct 2013 01:18:33 -0700 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. In-Reply-To: <525465D7.7060201@oracle.com> References: <52543E84.5050109@oracle.com> <525465D7.7060201@oracle.com> Message-ID: <52551159.8030302@oracle.com> On 10/8/2013 1:06 PM, Alan Bateman wrote: > On 08/10/2013 18:19, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8024704: Improve API documentation of ClassLoader and ServiceLoader >> with respect to enumeration of resources. >> >> >> This is a clarification of the implementation of the >> ServiceLoader.iterator() method, as well as non normative advice >> for ClassLoader subclasses overriding getResource() or getResources() >> to consider overriding the other method in order to keep them >> consistent with each other. >> >> Daniel - the spec update looks okay to me. > As background to others, the motive for this one stems from a small > compatibility issue that arose with the JAXP changes to use > ServiceLoader (it was previous foraging for service configuration > files itself). The compatibility issue arises with ClassLoader > implementations where getResource and getResources are inconsistent, > and in the JAXP case uncovered a server that located an unexpected XML > parser. > It'd be interesting to find out how many custom ClassLoader implements the getResource and getResources inconsistently but this might not be easy. Mandy From Alan.Bateman at oracle.com Wed Oct 9 08:22:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 09:22:17 +0100 Subject: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed In-Reply-To: <52550F81.4020203@oracle.com> References: <52550F81.4020203@oracle.com> Message-ID: <52551239.4010902@oracle.com> This looks like one for the net-dev list. On 09/10/2013 09:10, Ivan Gerasimov wrote: > Hello all! > > The MemLeakTest had been added with the fix for 8022584. > Since that, the test was reported to fail intermittently, even though > the leak was eliminated. > > I couldn't ever reproduce the failure even on the machines where the > failure was detected. > > Here are the changes I propose: > - Increase number of both warm-up and measured iterations, > - Number of iterations now indicates how many times a single interface > is probed. It used to probe all the interfaces that many times. > - Increase the memory consumption threshold > - Increase the timeout > > These should add some confidence that the failure of the test really > indicates a memory leak. > > In addition to that, in the case of a failure the list of all the > network interfaces is displayed, so there will be some more > information about the environment. > > Here is the webrev: > http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > > From alan.bateman at oracle.com Wed Oct 9 08:23:36 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 09 Oct 2013 08:23:36 +0000 Subject: hg: jdk8/tl/jdk: 8008662: Add @jdk.Exported to JDK-specific/exported APIs Message-ID: <20131009082348.AE9D462E76@hg.openjdk.java.net> Changeset: 2ea162b2ff55 Author: alanb Date: 2013-10-09 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ea162b2ff55 8008662: Add @jdk.Exported to JDK-specific/exported APIs Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy ! 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/package-info.java - src/share/classes/com/sun/jdi/connect/package.html ! 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/connect/spi/package-info.java - src/share/classes/com/sun/jdi/connect/spi/package.html ! 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/event/package-info.java - src/share/classes/com/sun/jdi/event/package.html + src/share/classes/com/sun/jdi/package-info.java - src/share/classes/com/sun/jdi/package.html ! 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/jdi/request/package-info.java - src/share/classes/com/sun/jdi/request/package.html ! 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/management/package-info.java - src/share/classes/com/sun/management/package.html ! 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/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/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/PolicyFile.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/callback/package-info.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + src/share/classes/com/sun/security/auth/login/package-info.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/auth/module/package-info.java + src/share/classes/com/sun/security/auth/package-info.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/jgss/package-info.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/VirtualMachine.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java + src/share/classes/com/sun/tools/attach/package-info.java - src/share/classes/com/sun/tools/attach/package.html ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java + src/share/classes/com/sun/tools/attach/spi/package-info.java - src/share/classes/com/sun/tools/attach/spi/package.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/jconsole/package-info.java - src/share/classes/com/sun/tools/jconsole/package.html ! src/solaris/classes/com/sun/management/OSMBeanFactory.java From ivan.gerasimov at oracle.com Wed Oct 9 08:26:40 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Oct 2013 12:26:40 +0400 Subject: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed In-Reply-To: <52551239.4010902@oracle.com> References: <52550F81.4020203@oracle.com> <52551239.4010902@oracle.com> Message-ID: <52551340.2020900@oracle.com> Yes, right, thanks! Just resend it to the right list On 09.10.2013 12:22, Alan Bateman wrote: > > This looks like one for the net-dev list. > > On 09/10/2013 09:10, Ivan Gerasimov wrote: >> Hello all! >> >> The MemLeakTest had been added with the fix for 8022584. >> Since that, the test was reported to fail intermittently, even though >> the leak was eliminated. >> >> I couldn't ever reproduce the failure even on the machines where the >> failure was detected. >> >> Here are the changes I propose: >> - Increase number of both warm-up and measured iterations, >> - Number of iterations now indicates how many times a single >> interface is probed. It used to probe all the interfaces that many >> times. >> - Increase the memory consumption threshold >> - Increase the timeout >> >> These should add some confidence that the failure of the test really >> indicates a memory leak. >> >> In addition to that, in the case of a failure the list of all the >> network interfaces is displayed, so there will be some more >> information about the environment. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~igerasim/8023390/0/webrev/ >> >> Sincerely yours, >> Ivan Gerasimov >> >> > > > From chris.hegarty at oracle.com Wed Oct 9 08:56:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Oct 2013 09:56:32 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <525389DD.8000608@oracle.com> Message-ID: <52551A40.7020301@oracle.com> This latest webrev looks good to me. If you haven't already got a sponsor, then I would be happy to sponsor this for you. Since there are minor spec clarifications, to document long standing behavior, then a CCC request will need to be submitted, and approved, before integration. -Chris. On 08/10/2013 22:29, Brian Burkhalter wrote: > I have posted an updated webrev http://cr.openjdk.java.net/~bpb/7179567/webrev.3/ which I hope addresses all the concerns expressed below. > > Please see also my comments in line. > > Once this looks acceptable I can do the CCC request. > > Thanks, > > Brian > > On Oct 7, 2013, at 9:28 PM, David Holmes wrote: > >> Aside: I'm confused about the relationship of this bug and JDK-6445180 - are they not duplicates? Seems to me this one should have been closed as a dup when it was reported. > > I think you are correct. I can adjust this once the webrev is approved. > >> On 5/10/2013 6:58 AM, Brian Burkhalter wrote: >>> On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: >>> >>>> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: >>>> >>>>> On 03/10/2013 16:10, Brian Burkhalter wrote: >>>>>> Please review and comment at your convenience. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-7179567 >>>>>> Webrev: http://cr.openjdk.java.net/~bpb/7179567/ >>> >>> An updated webrev which I hope adequately addresses the expressed concerns may be found at: >>> >>> http://cr.openjdk.java.net/~bpb/7179567.2/ >> >> URLClassLoader.java: please delete the commented out line: >> >> + //Objects.requireNonNull(urls); > > I already fixed that but had not updated the webrev. > >> SecureClassLoader.java: >> >> 186 * @throws SecurityException if the {@code ClassLoader} instance is not >> 187 * initialized. >> >> should read "this classloader instance" as it refers to the current instance. Also this may be bringing the spec into line with the implementation but "initialization" here is purely an implementation detail not part of the specification for this class so it should not be mentioned explicitly - and this change still needs a CCC (which might help determine exactly what should be said here - I'm unclear how you can try to call getPermissions if this is uninitialized as it would need 'this' to escape from the constructor - which perhaps it can do via a third-party security manager?). > > I've removed this @throws clause. > >> NoCallStackClassLoader.java: the comment is far too verbose, we don't write such explanatory kinds of comments for this kind of thing (else the code would be overrun with commentary!). > > Shortened. > >> Aside: if you are a JDK Author you don't need a Contributed-by line in the commit comments. > > > Removed. > > On Oct 8, 2013, at 4:08 AM, Alan Bateman wrote: > >> This looks much better. >> >> If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. >> >> My previous comment on @throws vs. @exception was just to keep things consistent as this is old code and would look odd for a method to use both. Our preference is to switch to @throws whenever the opportunity arises. The comment was also on the alignment/style. Take URLCLassLoader(URL[], ClassLoader) for example, the existing SecurityException has its description aligned under SecurityException whereas the new NullPointerException wraps around. So my overall comment here was to avoid mixing styles (it doesn't matter too much which style is used, just keep it consistent for future maintainers). >> >> In the test then it might be better to change the @summary line to only include the second paragraph (the bug summary is not interesting, especially when it references a test that is not in OpenJDK). > > > Updated. > > On Oct 8, 2013, at 8:53 AM, Chris Hegarty wrote: > >> Yes, this is much nicer. >> >> I'd be tempted to write another private constructor, taking all args, and checking params with checkForNullURLs before invoking, similar to ThreadGroup [1] L117, for example. But that is just clean up to remove some duplication. No need to do this. >> >>> If I read the code correctly then the long standing behavior of >>> URLClassLoader.getPermissions(null) was to throw a NPE, now it is >>> changed to return the empty collection in order to match the super type >>> (SecureClassLoader). I can't think of anything that would break so this >>> is probably okay, just maybe a bit surprising. >> >> Agreed. >> >>> My previous comment on @throws vs. @exception was just to keep things >>> consistent as this is old code and would look odd for a method to use >>> both. Our preference is to switch to @throws whenever the opportunity >>> arises. The comment was also on the alignment/style. Take >>> URLCLassLoader(URL[], ClassLoader) for example, the existing >>> SecurityException has its description aligned under SecurityException >>> whereas the new NullPointerException wraps around. So my overall comment >>> here was to avoid mixing styles (it doesn't matter too much which style >>> is used, just keep it consistent for future maintainers). >> >> Right, these classes are prime for stylistic clean up early in 9. For now, keep things locally consistent ( even if that is old style ). >> >> >> -Chris. >> >> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9f57d2774603/src/share/classes/java/lang/ThreadGroup.java > From chris.hegarty at oracle.com Wed Oct 9 09:00:25 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Oct 2013 10:00:25 +0100 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> <5253C781.5070600@oracle.com> <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> Message-ID: <52551B29.4040208@oracle.com> On 08/10/2013 21:50, Brian Burkhalter wrote: > .... > > http://cr.openjdk.java.net/~bpb/8016252/webrev.3/ This looks good to me. If you haven't already got a sponsor, then I would be happy to sponsor this for you. -Chris. From daniel.fuchs at oracle.com Wed Oct 9 09:44:53 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Oct 2013 11:44:53 +0200 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. In-Reply-To: <525465D7.7060201@oracle.com> References: <52543E84.5050109@oracle.com> <525465D7.7060201@oracle.com> Message-ID: <52552595.8070703@oracle.com> Hi, Thank you all for the nice & valuable feedback! I have updated the webrev with Alan's correction. The ClassLoader api note now reads: "When overriding this method it is recommended that an implementation ensures that ... " (and also fixed indentation) -- daniel On 10/8/13 10:06 PM, Alan Bateman wrote: > On 08/10/2013 18:19, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8024704: Improve API documentation of ClassLoader and ServiceLoader >> with respect to enumeration of resources. >> >> >> This is a clarification of the implementation of the >> ServiceLoader.iterator() method, as well as non normative advice >> for ClassLoader subclasses overriding getResource() or getResources() >> to consider overriding the other method in order to keep them >> consistent with each other. >> >> > As background to others, the motive for this one stems from a small > compatibility issue that arose with the JAXP changes to use > ServiceLoader (it was previous foraging for service configuration files > itself). The compatibility issue arises with ClassLoader implementations > where getResource and getResources are inconsistent, and in the JAXP > case uncovered a server that located an unexpected XML parser. > > Daniel - in the @apiNote on getResource it reads "the implementations > ensure" where it should be "the implementation ensures" or > "implementations should ensure". Otherwise the wording looks okay to me. > Conventions haven't been established yet but I would think that @apiNote > is a case where you can use the full > line. > > -Alan. From mandy.chung at oracle.com Wed Oct 9 09:47:34 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Oct 2013 02:47:34 -0700 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <5254F048.1090802@oracle.com> References: <5254F048.1090802@oracle.com> Message-ID: <52552636.9080209@oracle.com> Hi Henry, On 10/8/2013 10:57 PM, Henry Jen wrote: > Hi, > > Please review updated webrev at > http://cr.openjdk.java.net/~henryjen/ccc/8023524/6/webrev ProxyClassesDumper looks simpler after moving the path validation to the static factory method. One minor comment: ProxyClassesDumper.getInstance returns null if the given path is invalid. For a null path, it can simply return null rather than throwing NPE. It's good to see the limited doPrivileged being used here. I can see that listing the limited permissions would be a tradeoff with maintainability and readability. This also leads to the question how one can determine the complete list of permissions required (besides testing) and guideline on when to use limited privileged and when to use the entire ACC (Jeff may have some thoughts). Anyway, just some comments related to limited doPrivileged and not anything related to this fix. Henry - your fix looks good for me. You don't not need to generate a new webrev if you make any change per my comment about null path unless others have any other comment. thanks Mandy From Alan.Bateman at oracle.com Wed Oct 9 10:06:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 11:06:08 +0100 Subject: [7u-dev] Request for review of backport 7147084 In-Reply-To: <52550A18.50501@oracle.com> References: <52415B60.5050608@oracle.com> <5242EA3F.7040307@oracle.com> <52550A18.50501@oracle.com> Message-ID: <52552A90.4090104@oracle.com> On 09/10/2013 08:47, Ivan Gerasimov wrote: > Alan, Rob, Martin, > > Would you please help review the backport? I see that you were the > reviewers for the master fix. > I need a review for the backport, since the patch couldn't get applied > cleanly. > > Here are the changes I had to make: > - I had to manually replace Java_java_lang_ProcessImpl_create() > function body with the new version, as 'hg patch' could not handle it > automatically. > - I had to replace wide-char strings to regular char*, in all the > calls to win32Error() function. > > Thanks in advance, > Ivan > I looked over the webrev and it seems to match the jdk8 changes except for the win32Error usage. So I think it's okay. One thing to mention is that there is a patch under review to fix issues with the test so this should probably be pushed to jdk7u-dev too. -Alan. From michael.x.mcmahon at oracle.com Wed Oct 9 10:06:49 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 09 Oct 2013 11:06:49 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <5253E7C8.3030707@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> Message-ID: <52552AB9.803@oracle.com> On 08/10/13 12:08, Alan Bateman wrote: > On 04/10/2013 21:58, Brian Burkhalter wrote: >> : >> An updated webrev which I hope adequately addresses the expressed >> concerns may be found at: >> >> http://cr.openjdk.java.net/~bpb/7179567.2/ >> > This looks much better. > > If I read the code correctly then the long standing behavior of > URLClassLoader.getPermissions(null) was to throw a NPE, now it is > changed to return the empty collection in order to match the super > type (SecureClassLoader). I can't think of anything that would break > so this is probably okay, just maybe a bit surprising. > I'm still not sure about that change. Its effect in sub-classes will be to continue on in the sub-class implementation of getPermissions() with a null codesource parameter, where currently NPE would be thrown. Michael From Alan.Bateman at oracle.com Wed Oct 9 10:12:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 11:12:00 +0100 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: <52546336.4000606@oracle.com> References: <524DFE5C.1030705@oracle.com> <524E51E9.5060400@oracle.com> <52546336.4000606@oracle.com> Message-ID: <52552BF0.4020606@oracle.com> On 08/10/2013 20:55, Brent Christian wrote: > I've beefed up the test case, as suggested by Alan and Paul. It tries > removing at the start, middle, and end of the iteration. > > FWIW, all but one of the test scenarios pass even without the fix. > The failing case is: > > checkDescItrRmMid(m.keySet(), m.navigableKeySet().descendingIterator()); > > (that is, remove an element from the middle of the iteration, the > specific case of this bug). > > So most of the new tests are of code that is already correct, but IMO > it doesn't hurt to make sure it stays correct. :) > > http://cr.openjdk.java.net/~bchristi/8024709/webrev.01/ Thanks for the update and expanding the test. I skimmed over the new test cases and they looks good. There are a few commented out cases and it's not clear why this also. Also a minor observation is that the method names are a bit inconsistent with the other method names in the test, they might be something to look at before pushing. -Alan From mandy.chung at oracle.com Wed Oct 9 10:29:29 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Oct 2013 03:29:29 -0700 Subject: Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level In-Reply-To: <52550808.3090706@oracle.com> References: <5254A5B1.6040206@oracle.com> <52550808.3090706@oracle.com> Message-ID: <52553009.8080206@oracle.com> Daniel, Thanks for the review. On 10/9/2013 12:38 AM, Daniel Fuchs wrote: > > This looks good - but I think you could move the changes line 554-562 and > put them back inside the KnownLevel constructor where they were before. > This would allow you to keep mirroredLevel final. > That's right. I separated those lines in any earlier version and later added the private constructor per your suggestion. > Small nit: the name 'custom' is a misnomer - as it will be true for > both standard and > custom levels... I renamed it to "visible" (visible levels can be found by Level.parse) > > Concerning the test I don't think you need to copy the property file > to test.classes, > because I believe jprt puts test.src inside the classpath. I think you meant jtreg. Thanks I have fixed that. > (another possibility would be to use a custom subclass of > ListResourceBundle instead) > > Finally, I think that test needs to be run in main/othervm mode - > otherwise it might > fail intermittently... Another good catch. Fixed. The updated webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.01/ Mandy From Alan.Bateman at oracle.com Wed Oct 9 10:41:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 11:41:06 +0100 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> <5253C781.5070600@oracle.com> <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> Message-ID: <525532C2.30703@oracle.com> On 08/10/2013 21:50, Brian Burkhalter wrote: > I have updated the webrev accordingly > > http://cr.openjdk.java.net/~bpb/8016252/webrev.3/ > This looks good, I think this gets us to where we wanted to be. > : > >> I skimmed over the test but it doesn't appear to exercise anything >> new. If you want to exercise the checks then it would require >> deserializing from a byte stream that results in bad loadFactor, size >> and capacity values. It might not be worth it of course. > > No, it does not exercise anything new. I actually did try inserting > random garbage into the written-out byte stream, but without knowing > where to do so to affect the fields of interest it is rather useless > and causes totally unpredictable results. I don't know that this test > really needs to be included with the patch. There are tools around for decoding serialization streams and in this case you need to change the right bytes to exercise the conditions. It's probably not worth spending too much time on this (there are more important things to get done before ZBB) so I wouldn't object to just creating another bug to improve the test coverage for this area and move on. -Alan. From daniel.fuchs at oracle.com Wed Oct 9 10:41:13 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Oct 2013 12:41:13 +0200 Subject: Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level In-Reply-To: <52553009.8080206@oracle.com> References: <5254A5B1.6040206@oracle.com> <52550808.3090706@oracle.com> <52553009.8080206@oracle.com> Message-ID: <525532C9.1090003@oracle.com> Hi Mandy, This looks good! (not a reviewer) -- daniel On 10/9/13 12:29 PM, Mandy Chung wrote: > Daniel, > > Thanks for the review. > > On 10/9/2013 12:38 AM, Daniel Fuchs wrote: >> >> This looks good - but I think you could move the changes line 554-562 and >> put them back inside the KnownLevel constructor where they were before. >> This would allow you to keep mirroredLevel final. >> > > That's right. I separated those lines in any earlier version and later > added the private constructor per your suggestion. > >> Small nit: the name 'custom' is a misnomer - as it will be true for >> both standard and >> custom levels... > > I renamed it to "visible" (visible levels can be found by Level.parse) > >> >> Concerning the test I don't think you need to copy the property file >> to test.classes, >> because I believe jprt puts test.src inside the classpath. > > I think you meant jtreg. Thanks I have fixed that. > >> (another possibility would be to use a custom subclass of >> ListResourceBundle instead) >> >> Finally, I think that test needs to be run in main/othervm mode - >> otherwise it might >> fail intermittently... > > Another good catch. Fixed. > > The updated webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.01/ > > Mandy From scolebourne at joda.org Wed Oct 9 10:41:13 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 9 Oct 2013 11:41:13 +0100 Subject: Deflater enhancements In-Reply-To: <52546C0C.8020502@oracle.com> References: <52546C0C.8020502@oracle.com> Message-ID: See https://bugs.openjdk.java.net/browse/JDK-8026127 https://bugs.openjdk.java.net/browse/JDK-8026128 Stephen On 8 October 2013 21:33, Xueming Shen wrote: > The 100 in sample really means a "big enough" buffer here for simple use > case, not > necessarily means a "fixed size' buffer. Sure there is always room for doc > improvement, > especially given this is the API has been there for decade. > > Deflater/Inflater.end() is for explicitly/proactively release of the memory > resource > held by the deflater/inflater, it does not have impact to the > deflating/inflating result. > the end() will be invoked by the finalizer. > > It might be reasonable to simply have a pair of static utility methods > > byte[] Deflater.deflate(byte[]); > byte[] Inflater.deflate(byte[]); > > For the casual/simple/easy use scenario. > > Sherman > > > On 10/08/2013 03:24 AM, Stephen Colebourne wrote: >> >> I've been trying to use Deflater today and found it rather tricky. Two >> thoughts... >> >> 1) The class level Javadoc specifies a fixed size byte array of 100. >> http://download.java.net/jdk8/docs/api/java/util/zip/Deflater.html >> >> > From what I can tell from other searching and basic common sense, this >> cannot be right as the output size could well be bigger than 100. >> However, there is no real information in the Deflater class as to how >> the class is supposed to be used. I don't believe that kind of broken >> example is helpful. >> >> The best I found was >> http://java.dzone.com/articles/how-compress-and-uncompress >> which proposed a loop: >> Deflater deflater = new Deflater(); >> deflater.setInput(data); >> ByteArrayOutputStream outputStream = new >> ByteArrayOutputStream(data.length); >> deflater.finish(); >> byte[] buffer = new byte[1024]; >> while (!deflater.finished()) { >> int count = deflater.deflate(buffer); // returns the generated code... >> index >> outputStream.write(buffer, 0, count); >> } >> outputStream.close(); >> byte[] output = outputStream.toByteArray(); >> >> Neither example call deflater.end(), which I believe to be a mistake as >> well. >> >> Is my analysis correct? Should I raise a bug for better documentation? >> (this appears to affect Inflater as well) >> >> 2) Even with the Javadoc change, the API is still far too complex. >> >> As a user, all I want is something like: >> byte[] compressed = Deflater.deflate(input, options...) >> and similar for Inflater. >> >> (I actually want to compress a String, and an override to handle that >> would be useful as well) >> >> Any thoughts on adding a convenience method to make the API a lot >> easier? Can I raise a bug for that? >> >> Stephen > > From Alan.Bateman at oracle.com Wed Oct 9 10:42:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 11:42:06 +0100 Subject: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. In-Reply-To: <52552595.8070703@oracle.com> References: <52543E84.5050109@oracle.com> <525465D7.7060201@oracle.com> <52552595.8070703@oracle.com> Message-ID: <525532FE.4010504@oracle.com> On 09/10/2013 10:44, Daniel Fuchs wrote: > Hi, > > Thank you all for the nice & valuable feedback! > > I have updated the webrev with Alan's correction. > > The ClassLoader api note now reads: > > "When overriding this method it is recommended that an > implementation ensures that ... " > > (and also fixed indentation) > > > > -- daniel Thanks for the update, this looks good to me. -Alan. From vincent.x.ryan at oracle.com Wed Oct 9 10:50:46 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 09 Oct 2013 10:50:46 +0000 Subject: hg: jdk8/tl/jdk: 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Message-ID: <20131009105101.6D73A62E7F@hg.openjdk.java.net> Changeset: 91a752e3d50b Author: vinnie Date: 2013-10-09 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91a752e3d50b 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Reviewed-by: mullan, weijun + src/share/classes/java/security/DomainLoadStoreParameter.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/provider/DomainKeyStore.java ! test/sun/security/provider/KeyStore/DKSTest.java From Alan.Bateman at oracle.com Wed Oct 9 11:00:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 12:00:59 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <52550A2C.7050308@javaspecialists.eu> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> <51A0A1E8.1000604@oracle.com> <51B723D6.8060509@oracle.com> <52550A2C.7050308@javaspecialists.eu> Message-ID: <5255376B.1070603@oracle.com> On 09/10/2013 08:47, Dr Heinz M. Kabutz wrote: > I noticed the other day when using Java 8 that Thread.stop(Throwable) > was throwing an UOE. Unfortunately I missed the discussion in May > amongst the thousands of other important JDK emails. Thus I presume > that nothing I might have to say on the matter would change what is > currently in the OpenJDK ;-) But I'd like to state it "for the > record" anyway. > > Throwing checked exceptions in an unchecked context is, IMHO, > something one should almost never do, except maybe in test cases. Up > to now, I've known of quite a few ways to do this though: > > 1. Thread.stop(Throwable) with some mangling - see ThrowerConcurrent > in http://www.javaspecialists.eu/archive/Issue144.html > 2. Abusing generics > 3. Class.newInstance(), described in Java Puzzlers > (http://www.javaspecialists.eu/archive/Issue144.html) > 4. Unsafe.throwException() similar to ThrowerConcurrent in #1. > > Since this is something that we should not do anyway, it is no harm to > remove one of the ways, this being Thread.stop(Throwable). As I'm sure you can appreciate, it consumes a lot of oxygen to remove something and I'm hoping we don't have to spend any more time on this one. One comment on your list is that #1 differs in that it can cause other threads to misbehave and this is one of the main motives for finally pulling the plug on this method. For a sneakyThrow on the current thread then there are other options (as your puzzlers demonstrate) but hopefully there aren't too many cases where non-test code needs to do this. -Alan. From Alan.Bateman at oracle.com Wed Oct 9 11:13:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 12:13:29 +0100 Subject: RFR: 8025910 : (s) rename substream(long) -> skip and substream(long, long) -> slice In-Reply-To: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> References: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> Message-ID: <52553A59.3090504@oracle.com> On 09/10/2013 04:38, Mike Duigou wrote: > Hello all; > > Based upon feedback from the JavaOne Hands-On-Lab and other sources the 335 EG has decided to rename the two substream methods in the Streams interfaces to skip and slice. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/webrev/ > This looks okay to me and I assume the renames have caught any references in the javadoc. -Alan. From jan.lahoda at oracle.com Wed Oct 9 11:13:15 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Oct 2013 11:13:15 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20131009111321.C1A1D62E81@hg.openjdk.java.net> Changeset: 0be3f1820e8b Author: jlahoda Date: 2013-10-09 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0be3f1820e8b 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) Summary: Should not generate non-public $assertionsDisabled field into interfaces Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/Assertions.java + test/tools/javac/defaultMethods/CannotChangeAssertionsStateAfterInitialized.java Changeset: 1b469fd31e35 Author: jlahoda Date: 2013-10-09 13:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1b469fd31e35 8025087: Annotation processing api returns default modifier for interface static method Summary: ClassReader must not set Flags.DEFAULT for interface static methods Reviewed-by: vromero, jjg ! make/build.xml ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java + test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java + test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java + test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/processing/model/element/TestExecutableElement.java From Alan.Bateman at oracle.com Wed Oct 9 11:55:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Oct 2013 12:55:48 +0100 Subject: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Message-ID: <52554444.40402@oracle.com> This test has been failing (very intermittently) for some time. It was assumed to be a HotSpot issue on SPARC but more recently it has been duplicated on Linux x64 too. David Simms has notes in the bug [1] from this instrumentation and analysis, and Doug has pushed a fix to his CVS that fixes the issue (although they may still be an underlying issue that still needs to be hunted down). Doug's fix updates AQS and AQLS to re-read the head and avoid the race. We need to bring this into jdk8/tl, the webrev with the patch is here: http://cr.openjdk.java.net/~alanb/7011859/webrev/ -Alan [1] https://bugs.openjdk.java.net/browse/JDK-7011859 From paul.sandoz at oracle.com Wed Oct 9 12:33:57 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Oct 2013 14:33:57 +0200 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> Message-ID: On Oct 8, 2013, at 10:05 PM, Brian Burkhalter wrote: > On Oct 4, 2013, at 1:33 AM, Paul Sandoz wrote: > >> On Oct 4, 2013, at 9:18 AM, Aleksey Shipilev wrote: >> >>> On 10/04/2013 03:34 AM, Brian Burkhalter wrote: >>>> Here is an alternative solution:http://cr.openjdk.java.net/~bpb/7189139.2/. >>> >>> Seems OK with me, >> >> Same here. > > Based on previous comments by Aleksey and Paul I created this test > > http://cr.openjdk.java.net/~bpb/7189139/PrimeTest.java > > and ran it with the list of primes supplied by Aleksey, N=60000000, and certainty=100. This is the output: > > --- > Primes: /Users/bpb/Desktop/primes-50M.txt > N = 60000000 > certainty = 100 > 3562115 probable primes out of 3562115 candidates > Prime test = true > Not-prime test = true > Test succeeded! > --- > Nice! Perhaps as a separate bug you could place that code in the JDK test area as a non-jtreg test? Tip: you can use Files.lines().map(BigInteger::new) but we don't current have a limitWhen operation so need to limit to N primes and not the content. And... a bonus we can now go parallel and since TLR is used there is no longer the contention point as with SR, which means we go faster! I have added a modified version of the test code (see end of email) if you want to play. If you place this test in the JDK test area i strongly recommend using streams, it's a nice use-case we can point people to. Here is the difference for the first 1000000 primes (with your patch applied) for parallel and sequential execution (which also includes the fixed cost of loading the primes from disk): $ time java PrimeTest primes-50M.txt 1000000 100 true Primes: primes-50M.txt N = 1000000 certainty = 100 parallel = true Loaded 1000000 primes 1000000 probable primes out of 1000000 candidates Prime test = true real 0m16.252s user 1m59.065s sys 0m0.649s $ time java PrimeTest primes-50M.txt 1000000 100 false Primes: primes-50M.txt N = 1000000 certainty = 100 parallel = false Loaded 1000000 primes 1000000 probable primes out of 1000000 candidates Prime test = true real 0m54.613s user 1m0.278s sys 0m0.343s 16s vs. 55s :-) > An updated webrev which differs only in having a correct Hg header is here: > > http://cr.openjdk.java.net/~bpb/7189139/webrev.2/ > > If this looks good to go, would a Reviewer please issue an approval? > +1 Paul. /* * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import java.io.BufferedReader; import java.io.File; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.IOException; import java.math.BigInteger; import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.util.HashSet; import java.util.List; import java.util.concurrent.atomic.LongAdder; import java.util.stream.Stream; import static java.util.stream.Collectors.toList; public class PrimeTest { public static void main(String[] args) throws Throwable { File primesFile = new File(args[0]); int upperBound = Integer.valueOf(args[1]); int certainty = Integer.valueOf(args[2]); boolean parallel = Boolean.valueOf(args[3]); System.out.println("Primes: " + primesFile + "\nN = " + upperBound + "\ncertainty = " + certainty + "\nparallel = " + parallel); boolean primeTest = checkPrime(primesFile, upperBound, certainty, parallel); System.out.println("Prime test = " + primeTest); // boolean notPrimeTest = checkNotPrime(primesFile, upperBound, certainty); // System.out.println("Not-prime test = " + notPrimeTest); // // if (!primeTest || !notPrimeTest) { // throw new Exception("Test failed!"); // } // System.out.println("Test succeeded!"); } private static List parsePrimes(File f, long n) throws IOException { try (Stream lines = Files.lines(f.toPath(), StandardCharsets.UTF_8)) { return lines.limit(n).map(BigInteger::new).collect(toList()); } } /** * Verifies whether the fraction of probable primes detected in the range * [2,upperBound) is at least 1 - 1/2^certainty. * * @return true if and only if the test succeeds */ private static boolean checkPrime(File primesFile, int upperBound, int certainty, boolean parallel) throws FileNotFoundException, IOException { BufferedReader reader = new BufferedReader(new FileReader(primesFile)); BigInteger bigBound = BigInteger.valueOf(upperBound); List primes = parsePrimes(primesFile, upperBound); System.out.println(String.format("Loaded %d primes", primes.size())); long probablePrimes = (parallel ? primes.parallelStream() : primes.stream()) .filter(bi -> bi.isProbablePrime(certainty)) .count(); System.out.println(probablePrimes + " probable primes out of " + primes.size() + " candidates"); // N = certainty / 2 // Success if p/t >= 1 - 1/4^N // or (p/t)*4^N >= 4^N - 1 // or p*4^N >= t*(4^N - 1) BigInteger p = BigInteger.valueOf(probablePrimes); BigInteger t = BigInteger.valueOf(primes.size()); BigInteger fourToTheC = BigInteger.valueOf(4).pow(certainty / 2); BigInteger fourToTheCMinusOne = fourToTheC.subtract(BigInteger.ONE); BigInteger left = p.multiply(fourToTheC); BigInteger right = t.multiply(fourToTheCMinusOne); return left.compareTo(right) >= 0; } /** * Verifies whether all {@code BigInteger}s in the range [2,upperBound) for * which {@code isProbablePrime()} returns {@code false} are not * prime numbers. * * @return true if and only if the test succeeds */ private static boolean checkNotPrime(File primesFile, int upperBound, int certainty) throws FileNotFoundException, IOException { BufferedReader reader = new BufferedReader(new FileReader(primesFile)); HashSet primes = new HashSet(upperBound); String line; while ((line = reader.readLine()) != null) { Integer primeValue = Integer.valueOf(line); if (primeValue >= upperBound) { //System.out.println("Break at "+primeValue); break; } primes.add(primeValue); } reader.close(); boolean result = true; for (int i = 2; i < upperBound; i++) { BigInteger bigInt = BigInteger.valueOf(i); if (!bigInt.isProbablePrime(certainty) && primes.contains(Integer.valueOf(i))) { result = false; break; } } return result; } } From paul.sandoz at oracle.com Wed Oct 9 12:45:17 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Oct 2013 14:45:17 +0200 Subject: RFR: 8025910 : (s) rename substream(long) -> skip and substream(long, long) -> slice In-Reply-To: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> References: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> Message-ID: On Oct 9, 2013, at 5:38 AM, Mike Duigou wrote: > Hello all; > > Based upon feedback from the JavaOne Hands-On-Lab and other sources the 335 EG has decided to rename the two substream methods in the Streams interfaces to skip and slice. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/webrev/ > > and the specdiff: > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/specdiff/overview-summary.html > > Thanks, > Looks ok, but I have a preference to change the parameter name from "startInclusive" to say "n": /** * Returns a stream consisting of the remaining elements of this stream * after discarding the first {@code n} elements of the stream. * If this stream contains fewer than {@code n} elements then an * empty stream will be returned. * *

This is a stateful * intermediate operation. * * @apiNote * While {@code skip()} is generally a cheap operation on sequential * stream pipelines, it can be quite expensive on ordered parallel pipelines, * especially for large values of {@code n}, since {@code skip(n)} * is constrained to skip not just any n elements, but the * first n elements in the encounter order. Using an unordered * stream source (such as {@link #generate(Supplier)}) or removing the * ordering constraint with {@link #unordered()} may result in significant * speedups of {@code skip()} in parallel pipelines, if the semantics of * your situation permit. If consistency with encounter order is required, * and you are experiencing poor performance or memory utilization with * {@code skip()} in parallel pipelines, switching to sequential execution * with {@link #sequential()} may improve performance. * * @param n the number of leading elements to skip * @return the new stream * @throws IllegalArgumentException if {@code startInclusive} is negative */ Stream skip(long n); Paul. From chris.hegarty at oracle.com Wed Oct 9 12:55:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Oct 2013 13:55:17 +0100 Subject: Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level In-Reply-To: <525532C9.1090003@oracle.com> References: <5254A5B1.6040206@oracle.com> <52550808.3090706@oracle.com> <52553009.8080206@oracle.com> <525532C9.1090003@oracle.com> Message-ID: <52555235.2000202@oracle.com> On 09/10/2013 11:41, Daniel Fuchs wrote: > Hi Mandy, > > This looks good! +1 -Chris. > > (not a reviewer) > -- daniel > > On 10/9/13 12:29 PM, Mandy Chung wrote: >> Daniel, >> >> Thanks for the review. >> >> On 10/9/2013 12:38 AM, Daniel Fuchs wrote: >>> >>> This looks good - but I think you could move the changes line 554-562 >>> and >>> put them back inside the KnownLevel constructor where they were before. >>> This would allow you to keep mirroredLevel final. >>> >> >> That's right. I separated those lines in any earlier version and later >> added the private constructor per your suggestion. >> >>> Small nit: the name 'custom' is a misnomer - as it will be true for >>> both standard and >>> custom levels... >> >> I renamed it to "visible" (visible levels can be found by Level.parse) >> >>> >>> Concerning the test I don't think you need to copy the property file >>> to test.classes, >>> because I believe jprt puts test.src inside the classpath. >> >> I think you meant jtreg. Thanks I have fixed that. >> >>> (another possibility would be to use a custom subclass of >>> ListResourceBundle instead) >>> >>> Finally, I think that test needs to be run in main/othervm mode - >>> otherwise it might >>> fail intermittently... >> >> Another good catch. Fixed. >> >> The updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.01/ >> >> Mandy > From sundararajan.athijegannathan at oracle.com Wed Oct 9 13:08:35 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 09 Oct 2013 13:08:35 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131009130838.EBB9962E8A@hg.openjdk.java.net> Changeset: 8d29733ad609 Author: sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026112.js Changeset: 1e03d7caa68b Author: sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8026125.js Changeset: ec3094d9d5d5 Author: hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8026008.js + test/script/basic/JDK-8026008.js.EXPECTED From paul.sandoz at oracle.com Wed Oct 9 13:20:46 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 09 Oct 2013 13:20:46 +0000 Subject: hg: jdk8/tl/jdk: 8020061: Clarify reporting characteristics between splits Message-ID: <20131009132111.4767F62E8D@hg.openjdk.java.net> Changeset: 1cd20806fd5c Author: psandoz Date: 2013-10-09 15:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1cd20806fd5c 8020061: Clarify reporting characteristics between splits Reviewed-by: alanb, chegar ! src/share/classes/java/util/Spliterator.java From mandy.chung at oracle.com Wed Oct 9 13:27:21 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Oct 2013 13:27:21 +0000 Subject: hg: jdk8/tl/jdk: 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Message-ID: <20131009132733.D27DC62E8E@hg.openjdk.java.net> Changeset: cf6e39cfdf50 Author: mchung Date: 2013-10-09 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf6e39cfdf50 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Reviewed-by: dfuchs, chegar ! src/share/classes/java/util/logging/Level.java + test/java/util/logging/Level/CustomLevel.java + test/java/util/logging/Level/myresource.properties From roger.riggs at oracle.com Wed Oct 9 14:36:39 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 09 Oct 2013 10:36:39 -0400 Subject: Review Request for java.time test fix 8024612 Message-ID: <525569F7.7020206@oracle.com> Please Review a locale sensitive test correction: The API under test is based on Locale.getDefault(Locale.Category.FORMAT) and the test data should be using the same Locale. The failure was seen in locale: ar_EG with Locale.Category.FORMAT=ar_SA webrev: http://cr.openjdk.java.net/~rriggs/webrev-test-formatters-locale-8024612/ Thanks, Roger From roger.riggs at oracle.com Wed Oct 9 14:38:48 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 09 Oct 2013 10:38:48 -0400 Subject: RFR: improved exception messages in java.time 8025718 In-Reply-To: <524F18EF.7020808@oracle.com> References: <524F18EF.7020808@oracle.com> Message-ID: <52556A78.9010501@oracle.com> Ping... any Reviewer... Thanks On 10/4/2013 3:37 PM, roger riggs wrote: > Hi, > > Please review these small improvements in messages resulting from > parsing date and time errors and corresponding tests. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-better-msg-8025718/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8025718 > > Thanks, Roger > From Lance.Andersen at oracle.com Wed Oct 9 14:44:36 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 9 Oct 2013 10:44:36 -0400 Subject: Review Request for java.time test fix 8024612 In-Reply-To: <525569F7.7020206@oracle.com> References: <525569F7.7020206@oracle.com> Message-ID: +1 On Oct 9, 2013, at 10:36 AM, roger riggs wrote: > Please Review a locale sensitive test correction: > > The API under test is based on Locale.getDefault(Locale.Category.FORMAT) > and the test data should be using the same Locale. > The failure was seen in locale: ar_EG with Locale.Category.FORMAT=ar_SA > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-test-formatters-locale-8024612/ > > Thanks, Roger > > > -------------- 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 Lance.Andersen at oracle.com Wed Oct 9 14:51:29 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 9 Oct 2013 10:51:29 -0400 Subject: RFR: improved exception messages in java.time 8025718 In-Reply-To: <52556A78.9010501@oracle.com> References: <524F18EF.7020808@oracle.com> <52556A78.9010501@oracle.com> Message-ID: <9E2FE131-EB03-4622-9920-9A9947E8EE08@oracle.com> +1 On Oct 9, 2013, at 10:38 AM, roger riggs wrote: > Ping... any Reviewer... > > Thanks > > On 10/4/2013 3:37 PM, roger riggs wrote: >> Hi, >> >> Please review these small improvements in messages resulting from >> parsing date and time errors and corresponding tests. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-better-msg-8025718/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8025718 >> >> Thanks, Roger >> > -------------- 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 roger.riggs at oracle.com Wed Oct 9 15:07:08 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 09 Oct 2013 15:07:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131009150735.2783B62E95@hg.openjdk.java.net> Changeset: e3b70e601c1c Author: rriggs Date: 2013-10-09 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3b70e601c1c 8024612: java/time/tck/java/time/format/TCKDateTimeFormatters.java failed Summary: The test should be using the Locale.Category.FORMAT to verify the test data Reviewed-by: lancea ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: 09e2a73aa1dc Author: rriggs Date: 2013-09-26 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09e2a73aa1dc 8025718: Enhance error messages for parsing Summary: Add values and types to exception messages Reviewed-by: lancea Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/DayOfWeek.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/Month.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/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/format/Parsed.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java From henry.jen at oracle.com Wed Oct 9 17:00:42 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 09 Oct 2013 17:00:42 +0000 Subject: hg: jdk8/tl/jdk: 8023524: Mechanism to dump generated lambda classes / log lambda code generation Message-ID: <20131009170105.2E54462E9D@hg.openjdk.java.net> Changeset: c070001c4f60 Author: henryjen Date: 2013-10-09 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c070001c4f60 8023524: Mechanism to dump generated lambda classes / log lambda code generation Reviewed-by: plevart, mchung, forax, jjb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/ProxyClassesDumper.java + test/java/lang/invoke/lambda/LogGeneratedClassesTest.java From Thomas.Salter at unisys.com Wed Oct 9 17:08:50 2013 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Wed, 9 Oct 2013 12:08:50 -0500 Subject: Slow readng tzdb.dat Message-ID: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> I noticed recently that the JDK8 JVM was very slow starting on systems where the JRE is on a high-latency, remote file system. I tracked this down to the reading of tzdb.dat. In java/time/zone/TzdbZoneRulesProvider.java and sun/util/calendar/ZoneInfoFile.java the tzdb.dat file is read using a DataInputStream directly over a FileInputStream. Consequently there ends up being a large number of very small (often a single byte) read requests to the underlying O/S file system. This can be fixed trivially by adding a BufferedInputStream between the DataInputStream and the FileInputStream. Thus this: try (DataInputStream dis = new DataInputStream( new FileInputStream(new File(libDir, "tzdb.dat")))) { becomes: try (DataInputStream dis = new DataInputStream( new BufferedInputStream( new FileInputStream(new File(libDir, "tzdb.dat")), 32000))) { ? Tom Salter? |? Software Engineer? |? Java & Middleware Development Unisys? |? 2476 Swedesford Road? |? Malvern, PA? 19355?? |? 610-648-2568 | ?N385-2568 From henry.jen at oracle.com Wed Oct 9 17:10:32 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 09 Oct 2013 10:10:32 -0700 Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation In-Reply-To: <52552636.9080209@oracle.com> References: <5254F048.1090802@oracle.com> <52552636.9080209@oracle.com> Message-ID: <52558E08.3050902@oracle.com> Thanks Mandy, and all others have reviewed and commented. Cheers, Henry On 10/09/2013 02:47 AM, Mandy Chung wrote: > Hi Henry, > > On 10/8/2013 10:57 PM, Henry Jen wrote: >> Hi, >> >> Please review updated webrev at >> http://cr.openjdk.java.net/~henryjen/ccc/8023524/6/webrev > > ProxyClassesDumper looks simpler after moving the path validation to the > static factory method. > > One minor comment: > ProxyClassesDumper.getInstance returns null if the given path is invalid. > For a null path, it can simply return null rather than throwing NPE. > > It's good to see the limited doPrivileged being used here. I can > see that listing the limited permissions would be a tradeoff with > maintainability and readability. This also leads to the question > how one can determine the complete list of permissions required > (besides testing) and guideline on when to use limited privileged > and when to use the entire ACC (Jeff may have some thoughts). > > Anyway, just some comments related to limited doPrivileged and not > anything related to this fix. > > Henry - your fix looks good for me. You don't not need to > generate a new webrev if you make any change per my comment about > null path unless others have any other comment. > > thanks > Mandy From brent.christian at oracle.com Wed Oct 9 17:33:41 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 09 Oct 2013 10:33:41 -0700 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: <52552BF0.4020606@oracle.com> References: <524DFE5C.1030705@oracle.com> <524E51E9.5060400@oracle.com> <52546336.4000606@oracle.com> <52552BF0.4020606@oracle.com> Message-ID: <52559375.5050606@oracle.com> On 10/9/13 3:12 AM, Alan Bateman wrote: > On 08/10/2013 20:55, Brent Christian wrote: >> >> I've beefed up the test case > > Thanks for the update and expanding the test. I skimmed over the new > test cases and they looks good. Thanks. > There are a few commented out cases and > it's not clear why this also. Ooops - I was confirming the new tests work using 5- and 3- element collections. I'll take the commented lines back out. > Also a minor observation is that the > method names are a bit inconsistent with the other method names in the > test, they might be something to look at before pushing. Anything in particular? Other than clear(), I don't see other methods that take a collection and make it ready for testing. Most collections are populated inline, but my tests need a Map setup the exact same way many times, so I added prep[Map|Set]ForDescItrTests(). A lot of "helper" test methods are named "checkXYZ", and that's how I named mine. The new tests check pretty specific behaviors, and I chose pretty descriptive names. I guess most existing method names are fully written out rather than abbreviated (e.g. checkNavigableMapKeys()), which I generally like to do, but mine got *really* long. I abbreviated the names to keep things under 80 characters without having to break everything onto multiple lines. I think this is ready for someone to push (I can send a changeset), unless more should be done with the method names in the test case. Thanks, -Brent From huizhe.wang at oracle.com Wed Oct 9 17:35:48 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 09 Oct 2013 10:35:48 -0700 Subject: RFR (JAXP) : 8003262 reverse translation required changes Message-ID: <525593F4.10208@oracle.com> Hi, These resource bundles in JAXP were refactored due to request by WPTG. Now that the WPTG tool has been approved to support the original format, I'm reverting the previous change back to the original format: http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ Thanks, Joe From roger.riggs at oracle.com Wed Oct 9 17:40:25 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 09 Oct 2013 13:40:25 -0400 Subject: Slow reading tzdb.dat In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> Message-ID: <52559509.9020301@oracle.com> Hi Thomas, Thanks for the report and suggestion, I filed an issue for it. https://bugs.openjdk.java.net/browse/JDK-8026198 Roger On 10/9/2013 1:08 PM, Salter, Thomas A wrote: > I noticed recently that the JDK8 JVM was very slow starting on systems where the JRE is on a high-latency, remote file system. I tracked this down to the reading of tzdb.dat. In java/time/zone/TzdbZoneRulesProvider.java and sun/util/calendar/ZoneInfoFile.java the tzdb.dat file is read using a DataInputStream directly over a FileInputStream. Consequently there ends up being a large number of very small (often a single byte) read requests to the underlying O/S file system. This can be fixed trivially by adding a BufferedInputStream between the DataInputStream and the FileInputStream. > > Thus this: > try (DataInputStream dis = new DataInputStream( > new FileInputStream(new File(libDir, "tzdb.dat")))) { > becomes: > try (DataInputStream dis = new DataInputStream( > new BufferedInputStream( > new FileInputStream(new File(libDir, "tzdb.dat")), 32000))) { > > > > Tom Salter | Software Engineer | Java & Middleware Development > Unisys | 2476 Swedesford Road | Malvern, PA 19355 | 610-648-2568 | N385-2568 > > From daniel.fuchs at oracle.com Wed Oct 9 17:51:45 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Oct 2013 19:51:45 +0200 Subject: RFR (JAXP) : 8003262 reverse translation required changes In-Reply-To: <525593F4.10208@oracle.com> References: <525593F4.10208@oracle.com> Message-ID: <525597B1.4050208@oracle.com> Hi Joe, I don't know what was the original format but these changes look reasonable. best regards, -- daniel (not a reviewer) On 10/9/13 7:35 PM, huizhe wang wrote: > Hi, > > These resource bundles in JAXP were refactored due to request by WPTG. > Now that the WPTG tool has been approved to support the original format, > I'm reverting the previous change back to the original format: > > http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ > > Thanks, > Joe From Lance.Andersen at oracle.com Wed Oct 9 17:58:41 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 9 Oct 2013 13:58:41 -0400 Subject: RFR (JAXP) : 8003262 reverse translation required changes In-Reply-To: <525593F4.10208@oracle.com> References: <525593F4.10208@oracle.com> Message-ID: +1 On Oct 9, 2013, at 1:35 PM, huizhe wang wrote: > Hi, > > These resource bundles in JAXP were refactored due to request by WPTG. Now that the WPTG tool has been approved to support the original format, I'm reverting the previous change back to the original format: > > http://cr.openjdk.java.net/~joehw/jdk8/8003262/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 heinz at javaspecialists.eu Wed Oct 9 18:00:04 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Wed, 09 Oct 2013 21:00:04 +0300 Subject: Slow readng tzdb.dat In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> Message-ID: <525599A4.1010701@javaspecialists.eu> May I suggest rather: try ( File file = new File(libDir, "tzdb.dat"); FileInputStream fis = new FileInputStream(file); BufferedInputStream bis = new BufferedInputStream(fis, 32000); DataInputStream dis = new DataInputStream(bis); ) { ... That way, the resources are closed in the reverse order in which they are opened and an exception in the middle of the creation chain does not prevent the earlier resources from being closed. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Oracle Java Champion 2005-2013 JavaOne Rock Star Speaker 2012 http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz Salter, Thomas A wrote: > I noticed recently that the JDK8 JVM was very slow starting on systems where the JRE is on a high-latency, remote file system. I tracked this down to the reading of tzdb.dat. In java/time/zone/TzdbZoneRulesProvider.java and sun/util/calendar/ZoneInfoFile.java the tzdb.dat file is read using a DataInputStream directly over a FileInputStream. Consequently there ends up being a large number of very small (often a single byte) read requests to the underlying O/S file system. This can be fixed trivially by adding a BufferedInputStream between the DataInputStream and the FileInputStream. > > Thus this: > try (DataInputStream dis = new DataInputStream( > new FileInputStream(new File(libDir, "tzdb.dat")))) { > becomes: > try (DataInputStream dis = new DataInputStream( > new BufferedInputStream( > new FileInputStream(new File(libDir, "tzdb.dat")), 32000))) { > > > > Tom Salter | Software Engineer | Java & Middleware Development > Unisys | 2476 Swedesford Road | Malvern, PA 19355 | 610-648-2568 | N385-2568 > > > > From mike.duigou at oracle.com Wed Oct 9 18:11:15 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Oct 2013 11:11:15 -0700 Subject: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position In-Reply-To: <52559375.5050606@oracle.com> References: <524DFE5C.1030705@oracle.com> <524E51E9.5060400@oracle.com> <52546336.4000606@oracle.com> <52552BF0.4020606@oracle.com> <52559375.5050606@oracle.com> Message-ID: On Oct 9 2013, at 10:33 , Brent Christian wrote: > On 10/9/13 3:12 AM, Alan Bateman wrote: >> On 08/10/2013 20:55, Brent Christian wrote: > >> >>> I've beefed up the test case > > >> Thanks for the update and expanding the test. I skimmed over the new >> test cases and they looks good. > > Thanks. > > > There are a few commented out cases and >> it's not clear why this also. > > Ooops - I was confirming the new tests work using 5- and 3- element collections. I'll take the commented lines back out. > >> Also a minor observation is that the >> method names are a bit inconsistent with the other method names in the >> test, they might be something to look at before pushing. > > Anything in particular? > > Other than clear(), I don't see other methods that take a collection and make it ready for testing. Most collections are populated inline, but my tests need a Map setup the exact same way many times, so I added prep[Map|Set]ForDescItrTests(). > > A lot of "helper" test methods are named "checkXYZ", and that's how I named mine. > > The new tests check pretty specific behaviors, and I chose pretty descriptive names. I guess most existing method names are fully written out rather than abbreviated (e.g. checkNavigableMapKeys()), which I generally like to do, but mine got *really* long. I abbreviated the names to keep things under 80 characters without having to break everything onto multiple lines. > > > I think this is ready for someone to push (I can send a changeset), unless more should be done with the method names in the test case. I haven't looked at the latest webrev but if you send me a changeset I will review it and push it. Mike From brian.burkhalter at oracle.com Wed Oct 9 18:16:16 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 11:16:16 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <5253D3C2.3080509@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> Message-ID: On Oct 8, 2013, at 2:43 AM, Alan Bateman wrote: >> Thanks for the previous comments. My feeling at this point is to do one of two things: >> >> A) defer to something after JDK 8, or >> B) on EAI_AGAIN do not retry but set the cause of the UAE to "new SomeException(gai_strerror(error))" where SomeException could be for example Exception, RuntimeException, or IOException. >> >> Comments? >> > Throwing UHE with a useful message or cause would be best, so option B. However, I don't think it is critical for jdk8 as it's not a new issue (at least I think UHE has always been thrown with just the hostname, never the reason if it is known). So if there isn't time to be confident with the patch then it should be okay to move this out to 9. I have created a simple implementation for option B: http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ I should note that the Unix Inet6 implementation was already using the call ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in this case the message should already have been useful. This call formats the UHE message such as would: sprintf(error_message, "%s: %s", hostname, gai_strerror(error)) I changed the Unix Inet4 implementation to do this as well instead of calling JNU_ThrowByName(). For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments. Thanks, Brian From joel.franck at oracle.com Wed Oct 9 18:33:07 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 9 Oct 2013 20:33:07 +0200 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Message-ID: <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> Hi Please review this spec update and test for getting array classes and instances of more dimensions than the class file can express or the VM can handle. Array.newInstance have a test for arrays of more dimensions than 255, this patch adds a test for Class.forName as well. Also the javadoc for Array.newInstance are clarified. Bug: https://bugs.openjdk.java.net/browse/JDK-7044282 Webrev: http://cr.openjdk.java.net/~jfranck/7044282/webrev.00/ cheers /Joel From paul.sandoz at oracle.com Wed Oct 9 18:36:11 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Oct 2013 20:36:11 +0200 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <5254B7E7.6040709@oracle.com> References: <5254B7E7.6040709@oracle.com> Message-ID: On Oct 9, 2013, at 3:56 AM, Joe Darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8024354 Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation > > Thanks, > The note feels more like an api note since it leaves me wondering what does the current implementation does. Presumably we should mention that current impl does do not do anything special? Paul. > -Joe > > diff -r f1e31376f419 src/share/classes/java/util/DoubleSummaryStatistics.java > --- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct 09 00:10:02 2013 +0100 > +++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct 08 18:54:55 2013 -0700 > @@ -118,6 +118,11 @@ > * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > * sum will be {@code NaN}. > * > + * @implNote This method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum compared to a simple summation of {@code double} > + * values. > + * > * @return the sum of values, or zero if none > */ > public final double getSum() { > @@ -161,6 +166,10 @@ > * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > * average will be {@code NaN}. > * > + * @implNote This method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum used to compute the average. > + * > * @return the arithmetic mean of values, or zero if none > */ > public final double getAverage() { > From roger.riggs at oracle.com Wed Oct 9 18:42:06 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 09 Oct 2013 18:42:06 +0000 Subject: hg: jdk8/tl/jdk: 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Message-ID: <20131009184222.ABF3E62EA7@hg.openjdk.java.net> Changeset: d42fe440bda8 Author: rriggs Date: 2013-10-09 13:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d42fe440bda8 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Summary: Add appendValueReduced method based on a ChronoLocalDate to provide context for the value Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java From david.r.chase at oracle.com Wed Oct 9 18:49:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 9 Oct 2013 14:49:51 -0400 Subject: RFR: 8022718 : Runtime accessibility checking: protected class, if extended, should be accessible from another package Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8022718 webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/ Problem: Needed implementation for change to the spec for JVM behavior (from the bug report): > JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References" contains following assertion: > > If the method reference has the form ExpressionName :: NonWildTypeArgumentsopt Identifier or Primary :: NonWildTypeArgumentsopt Identifier, the body of the invocation method has the effect of invoking the compile-time declaration of the method reference, as described in 15.12.4.3, 15.12.4.4, 15.12.4.5.[jsr335-15.28.2-41] > > This assertions refers to chapter "15.12.4.3. Check Accessibility of Type and Method" which contains following assertions: > > Let C be the class containing the method invocation, and let T be the qualifying type of the method invocation (?13.1), and let m be the name of the method as determined at compile-time (?15.12.3). > ... > If T is in a different package than C, and T is protected, then T is accessible if and only if C is a subclass of T. > ... Note that this cannot be expressed in compatibly compiled Java (yet). Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime. Fix: Turns out that all that was needed was the missing case of checking the conditions for protected access, despite suggestions in the bug report that something different might be needed (the different version of the access flags was not suitable, and not using them makes for a smaller change anyway). The new behavior needed to be mentioned in the Javadoc, so I did. Testing: 1) wrote new self-contained test to verify behavior (*) 2) jtreg of jdk/lambda java/lang/invoke java/util/stream (passed) 3) running ute on vm.quick.testlist 4) running JPRT on testset core (well, trying to run JPRT). Issues: - It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them. - (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes. I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass. The test is written to mimic standalone (with bytecode rewriting) what was seen in the test. - I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this. Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree. David From brian.burkhalter at oracle.com Wed Oct 9 18:50:05 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Wed, 09 Oct 2013 18:50:05 +0000 Subject: hg: jdk8/tl/jdk: 8016252: More defensive HashSet.readObject Message-ID: <20131009185018.E91C762EA8@hg.openjdk.java.net> Changeset: b86e6700266e Author: bpb Date: 2013-10-09 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b86e6700266e 8016252: More defensive HashSet.readObject Summary: Add data validation checks in readObject(). Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashSet.java + test/java/util/HashSet/Serialization.java From dan.xu at oracle.com Wed Oct 9 18:51:03 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 09 Oct 2013 11:51:03 -0700 Subject: RFR: JDK-8025712,,(props) Possible memory leak in java_props_md.c / ParseLocale Message-ID: <5255A597.9030007@oracle.com> Hi All, This fix is to solve the memory leak issue in ParseLocale() function of jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, lc, is copied into temp, it is not necessary to do the strdup(), which leads to the memery leak. The fix simply removes the line of strdup operation. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 -Dan From brian.burkhalter at oracle.com Wed Oct 9 18:51:33 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 11:51:33 -0700 Subject: JDK 8 RFR 8016252: More defensive HashSet.readObject In-Reply-To: <525532C2.30703@oracle.com> References: <524E4ECB.2040007@oracle.com> <575353D9-564A-433C-9D7D-82A7389684D1@oracle.com> <52531A22.1070803@oracle.com> <8E26D265-DF6A-46C3-A09D-75D5AA5086CE@oracle.com> <10A617D0-F0D0-4426-A6E9-CE693B6C3F77@oracle.com> <5253C781.5070600@oracle.com> <266C4D4F-8C6F-4859-B95B-2CFBEFD3C86B@oracle.com> <525532C2.30703@oracle.com> Message-ID: On Oct 9, 2013, at 3:41 AM, Alan Bateman wrote: > On 08/10/2013 21:50, Brian Burkhalter wrote: >> >> I have updated the webrev accordingly >> >> http://cr.openjdk.java.net/~bpb/8016252/webrev.3/ > This looks good, I think this gets us to where we wanted to be. Pushed: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b86e6700266e >> : >> >>> I skimmed over the test but it doesn't appear to exercise anything new. If you want to exercise the checks then it would require deserializing from a byte stream that results in bad loadFactor, size and capacity values. It might not be worth it of course. >> >> >> No, it does not exercise anything new. I actually did try inserting random garbage into the written-out byte stream, but without knowing where to do so to affect the fields of interest it is rather useless and causes totally unpredictable results. I don't know that this test really needs to be included with the patch. > There are tools around for decoding serialization streams and in this case you need to change the right bytes to exercise the conditions. It's probably not worth spending too much time on this (there are more important things to get done before ZBB) so I wouldn't object to just creating another bug to improve the test coverage for this area and move on. I created https://bugs.openjdk.java.net/browse/JDK-8026216 so I will move on from this topic. Thanks, Brian From tom.hawtin at oracle.com Wed Oct 9 18:55:51 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Wed, 09 Oct 2013 19:55:51 +0100 Subject: Slow readng tzdb.dat In-Reply-To: <525599A4.1010701@javaspecialists.eu> References: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> <525599A4.1010701@javaspecialists.eu> Message-ID: <5255A6B7.6030209@oracle.com> On 09/10/2013 19:00, Dr Heinz M. Kabutz wrote: > That way, the resources are closed in the reverse order in which they > are opened and an exception in the middle of the creation chain does not > prevent the earlier resources from being closed. But there is only one resource. File tzdb = new File(libDir, "tzdb.dat"); try (InputStream rawIn = new FileInputStream(tzdb)) { DataInputStream dis = new DataInputStream( new BufferedInputStream(rawIn, 32000) ); Tom From brian.burkhalter at oracle.com Wed Oct 9 19:06:14 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 12:06:14 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <52551A40.7020301@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <525389DD.8000608@oracle.com> <52551A40.7020301@oracle.com> Message-ID: <64A54058-CDBE-4337-92E2-BF3A2B4FC584@oracle.com> On Oct 9, 2013, at 1:56 AM, Chris Hegarty wrote: > This latest webrev looks good to me. If you haven't already got a sponsor, then I would be happy to sponsor this for you. Thanks. > Since there are minor spec clarifications, to document long standing behavior, then a CCC request will need to be submitted, and approved, before integration. Yes, I intend to do that. I was hoping to get a consensus on the review first but I will file the request this week in any case. Thanks, Brian From john.r.rose at oracle.com Wed Oct 9 19:22:59 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Oct 2013 12:22:59 -0700 Subject: RFR: 8022718 : Runtime accessibility checking: protected class, if extended, should be accessible from another package In-Reply-To: References: Message-ID: <97248223-77FF-48FA-A0ED-978268962952@oracle.com> On Oct 9, 2013, at 11:49 AM, David Chase wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8022718 > > webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/ > > Problem: Needed implementation for change to the spec for JVM behavior (from the bug report): > >> JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References" contains following assertion: >> >> If the method reference has the form ExpressionName :: NonWildTypeArgumentsopt Identifier or Primary :: NonWildTypeArgumentsopt Identifier, the body of the invocation method has the effect of invoking the compile-time declaration of the method reference, as described in 15.12.4.3, 15.12.4.4, 15.12.4.5.[jsr335-15.28.2-41] >> >> This assertions refers to chapter "15.12.4.3. Check Accessibility of Type and Method" which contains following assertions: >> >> Let C be the class containing the method invocation, and let T be the qualifying type of the method invocation (?13.1), and let m be the name of the method as determined at compile-time (?15.12.3). >> ... >> If T is in a different package than C, and T is protected, then T is accessible if and only if C is a subclass of T. >> ... JSR 292 doesn't implement the Java language spec; it implements the JVM spec. In this case there is a difference. Mixing language and JVM spec. can lead to confusion down the road. The error is that Class.getModifiers (which is correctly saying "protected") is information about the source code. The JVM does not look at this for checking access; it looks at the more obscure Reflection.getClassAccessFlags. Those flags will say "public" (correctly) for a class compiled as "protected". In order to align exactly with JVM behavior (not Java semantics) the Reflection.getClassAccessFlags need to be looked at. So I think this fix is wrong. I think the root cause of this problem was me reaching for Class.getModifiers when I should have grabbed Reflection.getClassAccessFlags. About BogoLoader: I would prefer to see it hoisted into a place where more tests can use it. Consider test/java/lang/invoke/indify/Indify.java as a model; name it test/java/lang/invoke/loader/BogoLoader.java. ? John > Note that this cannot be expressed in compatibly compiled Java (yet). Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime. > > Fix: > Turns out that all that was needed was the missing case of checking the conditions for protected access, > despite suggestions in the bug report that something different might be needed (the different version of the > access flags was not suitable, and not using them makes for a smaller change anyway). The new behavior > needed to be mentioned in the Javadoc, so I did. > > Testing: > 1) wrote new self-contained test to verify behavior (*) > 2) jtreg of jdk/lambda java/lang/invoke java/util/stream (passed) > 3) running ute on vm.quick.testlist > 4) running JPRT on testset core (well, trying to run JPRT). > > Issues: > > - It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them. > > - (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes. I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass. The test is written to mimic standalone (with bytecode rewriting) what was seen in the test. > > - I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this. Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree. > > David > From naoto.sato at oracle.com Wed Oct 9 19:49:51 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 09 Oct 2013 12:49:51 -0700 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <5255A597.9030007@oracle.com> References: <5255A597.9030007@oracle.com> Message-ID: <5255B35F.6090104@oracle.com> Looks good to me. Naoto On 10/9/13 11:51 AM, Dan Xu wrote: > Hi All, > > This fix is to solve the memory leak issue in ParseLocale() function of > jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, > lc, is copied into temp, it is not necessary to do the strdup(), which > leads to the memery leak. The fix simply removes the line of strdup > operation. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 > > -Dan From brian.burkhalter at oracle.com Wed Oct 9 20:01:26 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 13:01:26 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <52552AB9.803@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> Message-ID: On Oct 9, 2013, at 3:06 AM, Michael McMahon wrote: >> If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. >> > > I'm still not sure about that change. Its effect in sub-classes will be to continue on in the sub-class implementation > of getPermissions() with a null codesource parameter, where currently NPE would be thrown. Well, upon re-examination I actually agree with you, especially considering the class hierarchy: AppletClassLoader :: URLClassLoader :: SecureClassLoader :: ClassLoader I have posted an updated webrev here: http://cr.openjdk.java.net/~bpb/7179567/webrev.4/ The differences with respect to the previous webrev [1] are: 1) the javadoc change of SecureClassLoader has been reverted; 2) these statements 665 if (codesource == null) { 666 return perms; 667 } 668 in URLClassLoader.getPermissions() have been reverted; 3) the javadoc of getPermissions() in URLClassLoader and AppletClassLoader has been updated to add "@exception NullPointerException if {@code codesource} is {@code null}." The CCC request to be associated with this change would indicate that "@exception NullPointerException" has been added to the javadoc of: A) all public URLClassLoader constructors; B) URLClassLoader.findClass(); C) URLClassLoader.getPermissions(); D) both URLClassLoader.newInstance() methods; E) AppletClassLoader.getPermissions(). The only actual *code* changes are in URLClassLoader. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/7179567/webrev.3/ From david.r.chase at oracle.com Wed Oct 9 20:18:30 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 9 Oct 2013 16:18:30 -0400 Subject: RFR: 8022718 : Runtime accessibility checking: protected class, if extended, should be accessible from another package In-Reply-To: <97248223-77FF-48FA-A0ED-978268962952@oracle.com> References: <97248223-77FF-48FA-A0ED-978268962952@oracle.com> Message-ID: <73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com> How about this one? http://cr.openjdk.java.net/~drchase/8022718/webrev.01/ This version tests both versions of the modifiers for "public" -- ref.getModifiers apparently sets public in some cases where the other one does not. Not 100% sure what those cases are, I suspect arrays from the cryptic failure message. Retested so far on the added test, and on j/l/i/MethodHandlesTest, which has been a fruitful source of problems so far. David On 2013-10-09, at 3:22 PM, John Rose wrote: > JSR 292 doesn't implement the Java language spec; it implements the JVM spec. In this case there is a difference. > > Mixing language and JVM spec. can lead to confusion down the road. > > The error is that Class.getModifiers (which is correctly saying "protected") is information about the source code. The JVM does not look at this for checking access; it looks at the more obscure Reflection.getClassAccessFlags. Those flags will say "public" (correctly) for a class compiled as "protected". > > In order to align exactly with JVM behavior (not Java semantics) the Reflection.getClassAccessFlags need to be looked at. So I think this fix is wrong. I think the root cause of this problem was me reaching for Class.getModifiers when I should have grabbed Reflection.getClassAccessFlags. > > About BogoLoader: I would prefer to see it hoisted into a place where more tests can use it. Consider test/java/lang/invoke/indify/Indify.java as a model; name it test/java/lang/invoke/loader/BogoLoader.java. > > ? John > >> Note that this cannot be expressed in compatibly compiled Java (yet). Testing requires either monkeying with change and recompilation, or doctoring bytecodes at runtime. >> >> Fix: >> Turns out that all that was needed was the missing case of checking the conditions for protected access, >> despite suggestions in the bug report that something different might be needed (the different version of the >> access flags was not suitable, and not using them makes for a smaller change anyway). The new behavior >> needed to be mentioned in the Javadoc, so I did. >> >> Testing: >> 1) wrote new self-contained test to verify behavior (*) >> 2) jtreg of jdk/lambda java/lang/invoke java/util/stream (passed) >> 3) running ute on vm.quick.testlist >> 4) running JPRT on testset core (well, trying to run JPRT). >> >> Issues: >> >> - It's highly likely I botched the Javadoc changes; I'm sure we have standards, and I'm sure I don't know them. >> >> - (*) The bug, as reported, describes as "wrong" the behavior obtained if the -PUBLIC +PROTECTED access mode appears on the innerclass attributes, not on the class attributes. I explored this space while developing the test, and if the class itself is marked protected, the failure occurs much earlier in the game when an attempt is made to load the subclass. The test is written to mimic standalone (with bytecode rewriting) what was seen in the test. >> >> - I decided to put the test in its own subdirectory of test/java/lang/invoke with its own informative name, and not directly in that directory, because all these invocation/protection tests have overlapping and near-overlapping class names, and so it would be confusing not to do this. Unfortunately, that means there's now two copies of the BogoLoader checked in to the test tree. >> >> David >> > From valerie.peng at oracle.com Wed Oct 9 20:26:29 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Wed, 09 Oct 2013 20:26:29 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20131009202801.65D1362EB0@hg.openjdk.java.net> Changeset: 1597066b58ee Author: valeriep Date: 2013-10-08 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1597066b58ee 7196382: PKCS11 provider should support 2048-bit DH Summary: Query and enforce range checking using the values from native PKCS11 library. Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java + test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Changeset: 3da8be8d13bf Author: valeriep Date: 2013-10-08 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3da8be8d13bf 8012900: CICO ignores AAD in GCM mode Summary: Change GCM decryption to not return result until tag verification passed Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherFeedback.java ! src/share/classes/com/sun/crypto/provider/CounterMode.java ! src/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GCTR.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/javax/crypto/CipherSpi.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java Changeset: f4305254f92f Author: valeriep Date: 2013-10-08 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4305254f92f 8014374: Cannot initialize "AES/GCM/NoPadding" on wrap/unseal on solaris with OracleUcrypto Summary: Removed OracleUcrypto provider regression tests from OpenJDK Reviewed-by: xuelei - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java Changeset: e044b0151858 Author: valeriep Date: 2013-10-08 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e044b0151858 8025967: addition of -Werror broke the old build Summary: Fixed and suppressed compiler warnings on rawtypes Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/sun/instrument/InstrumentationImpl.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/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/security/provider/AuthPolicyFile.java ! src/share/classes/sun/security/provider/SubjectCodeSource.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 7a7b73a40bb1 Author: valeriep Date: 2013-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7b73a40bb1 Merge - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html From heinz at javaspecialists.eu Wed Oct 9 20:45:39 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Wed, 09 Oct 2013 23:45:39 +0300 Subject: Slow readng tzdb.dat In-Reply-To: <5255A6B7.6030209@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C30148FC1CA52B@USEA-EXCH7.na.uis.unisys.com> <525599A4.1010701@javaspecialists.eu> <5255A6B7.6030209@oracle.com> Message-ID: <5255C073.5020905@javaspecialists.eu> Tom Hawtin wrote: > On 09/10/2013 19:00, Dr Heinz M. Kabutz wrote: > >> That way, the resources are closed in the reverse order in which they >> are opened and an exception in the middle of the creation chain does not >> prevent the earlier resources from being closed. > > But there is only one resource. > > File tzdb = new File(libDir, "tzdb.dat"); > try (InputStream rawIn = new FileInputStream(tzdb)) { > DataInputStream dis = new DataInputStream( > new BufferedInputStream(rawIn, 32000) > ); But you've written it slightly differently from the original try (DataInputStream dis = new DataInputStream( new FileInputStream(new File(libDir, "tzdb.dat")))) { Your code is also fine, as it isolates the resource that should be closed should something go wrong during the initialization of the DataInputStream / BufferedInputStream. Either of our solutions would be good and it would just be a matter of how you'd like to scope the various local variables. From joe.darcy at oracle.com Wed Oct 9 20:47:28 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Oct 2013 13:47:28 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: References: <5254B7E7.6040709@oracle.com> Message-ID: <5255C0E0.40900@oracle.com> On 10/09/2013 11:36 AM, Paul Sandoz wrote: > On Oct 9, 2013, at 3:56 AM, Joe Darcy wrote: > >> Hello, >> >> Please review the patch below which addresses >> >> JDK-8024354 Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation >> >> Thanks, >> > The note feels more like an api note since it leaves me wondering what does the current implementation does. Presumably we should mention that current impl does do not do anything special? > The goal here is to explicitly allow (but not require) better-than-straightforard summation algorithms to be used. Time permitting, I'd prefer to get a better implementation pushed before JDK 8 GA and, failing that, in an 8 update before JDK 9. -Joe From karen.kinnear at oracle.com Wed Oct 9 22:13:49 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 9 Oct 2013 18:13:49 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces Message-ID: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Please review: webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8026213 Summary: Reflection generates code dynamically to speed up reflection processing after startup. The first 15 runs of a reflection call use the vm code path, after that we use the generated code path, which needs to use invokespecial on private methods in interfaces. Tested: Test attached to the bug Also - all the 8011311 private method testing was run with this in the build: Robert Field's TypeTest 8025475 test defmeth privatemethodstest with reflection John Rose's intfbug jtreg: java.util, java.lang jck vm, lang thanks, Karen From joe.darcy at oracle.com Wed Oct 9 23:38:57 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Oct 2013 16:38:57 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> Message-ID: <5255E911.8020905@oracle.com> On 10/08/2013 08:08 PM, Mike Duigou wrote: > This seems to contradict the main documentation for these methods. Perhaps instead we should remove the "The average returned can vary depending upon the order in which values are recorded. This is due to accumulated rounding error in addition of values of differing magnitudes. Values sorted by increasing absolute magnitude tend to yield more accurate results." into an @implNote? > > I also suspect that having this documentation only in DoubleSummaryStatistics may be too hidden away. Perhaps similar docs on DoubleStream sum() and average() methods as well? > > Hello, Please review the second take on this change which is expanded to include DoubleStream.sum: http://cr.openjdk.java.net/~darcy/8024354.1/ Patch below, Thanks, -Joe --- old/src/share/classes/java/util/DoubleSummaryStatistics.java 2013-10-09 16:37:23.000000000 -0700 +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 2013-10-09 16:37:23.000000000 -0700 @@ -111,12 +111,24 @@ /** * Returns the sum of values recorded, or zero if no values have been - * recorded. The sum returned can vary depending upon the order in which - * values are recorded. This is due to accumulated rounding error in - * addition of values of differing magnitudes. Values sorted by increasing - * absolute magnitude tend to yield more accurate results. If any recorded - * value is a {@code NaN} or the sum is at any point a {@code NaN} then the - * sum will be {@code NaN}. + * recorded. + * + * If any recorded value is a NaN or the sum is at any point a NaN + * then the sum will be NaN. + * + * @apiNote The value of a floating-point sum is a function both + * of the input values as well as the order of addition + * operations. The order of addition operations of this method is + * intentionally not defined to allow for implementation flexibility + * to improve the speed and accuracy of the computed result. + * + * In particular, this method may be implemented using compensated + * summation or other technique to reduce the error bound in the + * numerical sum compared to a simple summation of {@code double} + * values. + * + * Sorting values by increasing absolute magnitude tends to yield + * more accurate results. * * @return the sum of values, or zero if none */ @@ -153,13 +165,21 @@ } /** - * Returns the arithmetic mean of values recorded, or zero if no values have been - * recorded. The average returned can vary depending upon the order in - * which values are recorded. This is due to accumulated rounding error in - * addition of values of differing magnitudes. Values sorted by increasing - * absolute magnitude tend to yield more accurate results. If any recorded - * value is a {@code NaN} or the sum is at any point a {@code NaN} then the - * average will be {@code NaN}. + * Returns the arithmetic mean of values recorded, or zero if no + * values have been recorded. + * + * If any recorded value is a NaN or the sum is at any point a NaN + * then the average will be code NaN. + * + * @apiNote The average returned can vary depending upon the order in + * which values are recorded. + * + * This method may be implemented using compensated summation or + * other technique to reduce the error bound in the numerical sum + * used to compute the average. + * + * Values sorted by increasing absolute magnitude tend to yield + * more accurate results. * * @return the arithmetic mean of values, or zero if none */ --- old/src/share/classes/java/util/stream/DoubleStream.java 2013-10-09 16:37:23.000000000 -0700 +++ new/src/share/classes/java/util/stream/DoubleStream.java 2013-10-09 16:37:23.000000000 -0700 @@ -502,22 +502,42 @@ BiConsumer combiner); /** - * Returns the sum of elements in this stream. The sum returned can vary - * depending upon the order in which elements are encountered. This is due - * to accumulated rounding error in addition of values of differing - * magnitudes. Elements sorted by increasing absolute magnitude tend to - * yield more accurate results. If any stream element is a {@code NaN} or - * the sum is at any point a {@code NaN} then the sum will be {@code NaN}. - * This is a special case of a - * reduction and is + * Returns the sum of elements in this stream. + * + * Summation is a special case of a reduction. If + * floating-point summation were exact, this method would be * equivalent to: + * * 

{@code
       *     return reduce(0, Double::sum);
       * }
* + * However, since floating-point summation is not exact, the above + * code is not necessarily equivalent to the summation computation + * done by this method. + * *

This is a terminal * operation. * + *

If any stream element is a NaN or the sum is at any point a NaN + * then the sum will be NaN. + * + * @apiNote The value of a floating-point sum is a function both + * of the input values as well as the order of addition + * operations. The order of addition operations of this method is + * intentionally not defined to allow for implementation + * flexibility to improve the speed and accuracy of the computed + * result. + * + * In particular, this method may be implemented using compensated + * summation or other technique to reduce the error bound in the + * numerical sum compared to a simple summation of {@code double} + * values. + * + * Sorting values by increasing absolute magnitude tends to yield + * more accurate results. + * * @return the sum of elements in this stream */ double sum(); From mike.duigou at oracle.com Wed Oct 9 23:47:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Oct 2013 16:47:25 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <5255E911.8020905@oracle.com> References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> <5255E911.8020905@oracle.com> Message-ID: <69E806A0-85E4-4E12-BFB2-B6DB16330CB7@oracle.com> Big improvement. This looks like the right direction. DoubleStream.average() needs the same treatment for completeness. Mike On Oct 9 2013, at 16:38 , Joe Darcy wrote: > On 10/08/2013 08:08 PM, Mike Duigou wrote: >> This seems to contradict the main documentation for these methods. Perhaps instead we should remove the "The average returned can vary depending upon the order in which values are recorded. This is due to accumulated rounding error in addition of values of differing magnitudes. Values sorted by increasing absolute magnitude tend to yield more accurate results." into an @implNote? >> >> I also suspect that having this documentation only in DoubleSummaryStatistics may be too hidden away. Perhaps similar docs on DoubleStream sum() and average() methods as well? >> >> > > Hello, > > Please review the second take on this change which is expanded to include DoubleStream.sum: > > http://cr.openjdk.java.net/~darcy/8024354.1/ > > Patch below, > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/DoubleSummaryStatistics.java 2013-10-09 16:37:23.000000000 -0700 > +++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 2013-10-09 16:37:23.000000000 -0700 > @@ -111,12 +111,24 @@ > > /** > * Returns the sum of values recorded, or zero if no values have been > - * recorded. The sum returned can vary depending upon the order in which > - * values are recorded. This is due to accumulated rounding error in > - * addition of values of differing magnitudes. Values sorted by increasing > - * absolute magnitude tend to yield more accurate results. If any recorded > - * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > - * sum will be {@code NaN}. > + * recorded. > + * > + * If any recorded value is a NaN or the sum is at any point a NaN > + * then the sum will be NaN. > + * > + * @apiNote The value of a floating-point sum is a function both > + * of the input values as well as the order of addition > + * operations. The order of addition operations of this method is > + * intentionally not defined to allow for implementation flexibility > + * to improve the speed and accuracy of the computed result. > + * > + * In particular, this method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum compared to a simple summation of {@code double} > + * values. > + * > + * Sorting values by increasing absolute magnitude tends to yield > + * more accurate results. > * > * @return the sum of values, or zero if none > */ > @@ -153,13 +165,21 @@ > } > > /** > - * Returns the arithmetic mean of values recorded, or zero if no values have been > - * recorded. The average returned can vary depending upon the order in > - * which values are recorded. This is due to accumulated rounding error in > - * addition of values of differing magnitudes. Values sorted by increasing > - * absolute magnitude tend to yield more accurate results. If any recorded > - * value is a {@code NaN} or the sum is at any point a {@code NaN} then the > - * average will be {@code NaN}. > + * Returns the arithmetic mean of values recorded, or zero if no > + * values have been recorded. > + * > + * If any recorded value is a NaN or the sum is at any point a NaN > + * then the average will be code NaN. > + * > + * @apiNote The average returned can vary depending upon the order in > + * which values are recorded. > + * > + * This method may be implemented using compensated summation or > + * other technique to reduce the error bound in the numerical sum > + * used to compute the average. > + * > + * Values sorted by increasing absolute magnitude tend to yield > + * more accurate results. > * > * @return the arithmetic mean of values, or zero if none > */ > --- old/src/share/classes/java/util/stream/DoubleStream.java 2013-10-09 16:37:23.000000000 -0700 > +++ new/src/share/classes/java/util/stream/DoubleStream.java 2013-10-09 16:37:23.000000000 -0700 > @@ -502,22 +502,42 @@ > BiConsumer combiner); > > /** > - * Returns the sum of elements in this stream. The sum returned can vary > - * depending upon the order in which elements are encountered. This is due > - * to accumulated rounding error in addition of values of differing > - * magnitudes. Elements sorted by increasing absolute magnitude tend to > - * yield more accurate results. If any stream element is a {@code NaN} or > - * the sum is at any point a {@code NaN} then the sum will be {@code NaN}. > - * This is a special case of a > - * reduction and is > + * Returns the sum of elements in this stream. > + * > + * Summation is a special case of a + * href="package-summary.html#Reduction">reduction. If > + * floating-point summation were exact, this method would be > * equivalent to: > + * > * 

{@code
>      *     return reduce(0, Double::sum);
>      * }
> * > + * However, since floating-point summation is not exact, the above > + * code is not necessarily equivalent to the summation computation > + * done by this method. > + * > *

This is a terminal > * operation. > * > + *

If any stream element is a NaN or the sum is at any point a NaN > + * then the sum will be NaN. > + * > + * @apiNote The value of a floating-point sum is a function both > + * of the input values as well as the order of addition > + * operations. The order of addition operations of this method is > + * intentionally not defined to allow for implementation > + * flexibility to improve the speed and accuracy of the computed > + * result. > + * > + * In particular, this method may be implemented using compensated > + * summation or other technique to reduce the error bound in the > + * numerical sum compared to a simple summation of {@code double} > + * values. > + * > + * Sorting values by increasing absolute magnitude tends to yield > + * more accurate results. > + * > * @return the sum of elements in this stream > */ > double sum(); > From brian.burkhalter at oracle.com Thu Oct 10 00:20:17 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 17:20:17 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> Message-ID: <592E68ED-551E-4D68-B0B1-EA0DD2752ABA@oracle.com> On Oct 9, 2013, at 11:16 AM, Brian Burkhalter wrote: > For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments. Since compiled successfully on Windows but holding off on JPRT until there are comments. Thanks, Brian From brian.burkhalter at oracle.com Thu Oct 10 00:29:26 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Thu, 10 Oct 2013 00:29:26 +0000 Subject: hg: jdk8/tl/jdk: 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Message-ID: <20131010002949.8ACA162EB7@hg.openjdk.java.net> Changeset: 673f8045311e Author: bpb Date: 2013-10-09 17:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/673f8045311e 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Summary: Use ThreadLocalRandom instead of SecureRandom. Reviewed-by: shade, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java From brian.burkhalter at oracle.com Thu Oct 10 00:47:08 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Oct 2013 17:47:08 -0700 Subject: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks In-Reply-To: References: <1B2B78D7-898B-4663-A35F-A1F10689E17C@oracle.com> <524E6BE1.6080406@oracle.com> <2CC9BADD-6D40-4DAC-8932-DDDB4F077D2F@oracle.com> Message-ID: On Oct 9, 2013, at 5:33 AM, Paul Sandoz wrote: > Nice! > > Perhaps as a separate bug you could place that code in the JDK test area as a non-jtreg test? Please see: https://bugs.openjdk.java.net/browse/JDK-8026236 The file of primes would need to be hosted elsewhere than the repository given its size. > Tip: you can use Files.lines().map(BigInteger::new) but we don't current have a limitWhen operation so need to limit to N primes and not the content. > > And... a bonus we can now go parallel and since TLR is used there is no longer the contention point as with SR, which means we go faster! > > I have added a modified version of the test code (see end of email) if you want to play. If you place this test in the JDK test area i strongly recommend using streams, it's a nice use-case we can point people to. > > Here is the difference for the first 1000000 primes (with your patch applied) for parallel and sequential execution (which also includes the fixed cost of loading the primes from disk): > > $ time java PrimeTest primes-50M.txt 1000000 100 true By way of comparison here are some other results of the same test --- SecureRandom, parallel = false --- real 3m36.360s --- SecureRandom, parallel = true --- real 3m11.726s --- ThreadLocalRandom, parallel = false --- real 2m34.260s --- ThreadLocalRandom, parallel = true --- real 1m39.173s These are of course not real benchmarks, especially as I was running on my dev system, but they are encouraging. > 16s vs. 55s :-) The most salient point here is clearly that my machine is *much* slower. ;-) >> An updated webrev which differs only in having a correct Hg header is here: >> >> http://cr.openjdk.java.net/~bpb/7189139/webrev.2/ >> >> If this looks good to go, would a Reviewer please issue an approval? >> > > +1 Done: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/673f8045311e. Thanks, Brian From joe.darcy at oracle.com Thu Oct 10 00:57:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Oct 2013 17:57:36 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <69E806A0-85E4-4E12-BFB2-B6DB16330CB7@oracle.com> References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> <5255E911.8020905@oracle.com> <69E806A0-85E4-4E12-BFB2-B6DB16330CB7@oracle.com> Message-ID: <5255FB80.3010902@oracle.com> On 10/09/2013 04:47 PM, Mike Duigou wrote: > Big improvement. This looks like the right direction. DoubleStream.average() needs the same treatment for completeness. Thanks Mike. Next iteration incorporating this feedback (and some other off-list feedback): http://cr.openjdk.java.net/~darcy/8024354.2 -Joe From mike.duigou at oracle.com Thu Oct 10 01:17:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Oct 2013 18:17:57 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: <5255FB80.3010902@oracle.com> References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> <5255E911.8020905@oracle.com> <69E806A0-85E4-4E12-BFB2-B6DB16330CB7@oracle.com> <5255FB80.3010902@oracle.com> Message-ID: For consistency I would move the "this is a terminal operation" paragraph to just before the @apiNote. I would suggest after the @apiNote but there's no mechanism for ending a javadoc tag other than starting another tag and we don't want the terminal text in the apiNote. Other than that it looks correct. Mike On Oct 9 2013, at 17:57 , Joe Darcy wrote: > On 10/09/2013 04:47 PM, Mike Duigou wrote: >> Big improvement. This looks like the right direction. DoubleStream.average() needs the same treatment for completeness. > > Thanks Mike. Next iteration incorporating this feedback (and some other off-list feedback): > > http://cr.openjdk.java.net/~darcy/8024354.2 > > -Joe > > From joe.darcy at oracle.com Thu Oct 10 01:30:52 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 09 Oct 2013 18:30:52 -0700 Subject: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation In-Reply-To: References: <5254B7E7.6040709@oracle.com> <1AABEA4E-38C0-4027-AA0B-9045A865A64C@oracle.com> <5255E911.8020905@oracle.com> <69E806A0-85E4-4E12-BFB2-B6DB16330CB7@oracle.com> <5255FB80.3010902@oracle.com> Message-ID: <5256034C.4030805@oracle.com> I'll pushed with the terminal op reordering you've suggested; thanks for the reviews, -Joe On 10/9/2013 6:17 PM, Mike Duigou wrote: > For consistency I would move the "this is a terminal operation" paragraph to just before the @apiNote. I would suggest after the @apiNote but there's no mechanism for ending a javadoc tag other than starting another tag and we don't want the terminal text in the apiNote. > > Other than that it looks correct. > > Mike > > On Oct 9 2013, at 17:57 , Joe Darcy wrote: > >> On 10/09/2013 04:47 PM, Mike Duigou wrote: >>> Big improvement. This looks like the right direction. DoubleStream.average() needs the same treatment for completeness. >> Thanks Mike. Next iteration incorporating this feedback (and some other off-list feedback): >> >> http://cr.openjdk.java.net/~darcy/8024354.2 >> >> -Joe >> >> From mike.duigou at oracle.com Thu Oct 10 01:25:58 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 10 Oct 2013 01:25:58 +0000 Subject: hg: jdk8/tl/jdk: 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Message-ID: <20131010012639.85AE162EB8@hg.openjdk.java.net> Changeset: eab3c09745b6 Author: bchristi Date: 2013-10-09 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eab3c09745b6 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Summary: Override remove() method in DescendingKeyIterator Reviewed-by: alanb, mduigou, psandoz ! src/share/classes/java/util/TreeMap.java ! test/java/util/Collection/MOAT.java From joe.darcy at oracle.com Thu Oct 10 01:32:23 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Oct 2013 01:32:23 +0000 Subject: hg: jdk8/tl/jdk: 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Message-ID: <20131010013235.BE03562EBB@hg.openjdk.java.net> Changeset: c13309f658e1 Author: darcy Date: 2013-10-09 18:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c13309f658e1 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/DoubleStream.java From joe.darcy at oracle.com Thu Oct 10 03:11:10 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 09 Oct 2013 20:11:10 -0700 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> References: <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> Message-ID: <52561ACE.8090800@oracle.com> Hi Joel, The code changes look fine, but I'd like to see some refactoring to the tests. In particular, please put the logic in 81 try { 82 Class c256 = Class.forName(name256); 83 error++; 84 System.err.println("ERROR: could create " + c256); 85 } catch (ClassNotFoundException e) { 86 ;// ok 87 } into a method that can be called like failingForName(name, clazz) (or whatever is appropriate). Thanks, -Joe On 10/9/2013 11:33 AM, Joel Borggren-Franck wrote: > Hi > > Please review this spec update and test for getting array classes and > instances of more dimensions than the class file can express or the VM > can handle. > > Array.newInstance have a test for arrays of more dimensions than 255, > this patch adds a test for Class.forName as well. > > Also the javadoc for Array.newInstance are clarified. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7044282 > Webrev: http://cr.openjdk.java.net/~jfranck/7044282/webrev.00/ > > cheers > /Joel From david.holmes at oracle.com Thu Oct 10 03:32:06 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 13:32:06 +1000 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> Message-ID: <52561FB6.1060301@oracle.com> Hi Brian, In the text: * @exception NullPointerException if {@code urls} or any of its elements * is {@code null} I'm unsure if it should be "is null" or "are null" given the initial subject is singular and latter subject is plural. Existing similar phrases seem to be split roughly 50-50. Nit: In the test there are a few places where you have t on a line by itself: 65 t); but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + Thanks, David On 10/10/2013 6:01 AM, Brian Burkhalter wrote: > On Oct 9, 2013, at 3:06 AM, Michael McMahon wrote: > >>> If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. >>> >> >> I'm still not sure about that change. Its effect in sub-classes will be to continue on in the sub-class implementation >> of getPermissions() with a null codesource parameter, where currently NPE would be thrown. > > Well, upon re-examination I actually agree with you, especially considering the class hierarchy: > > AppletClassLoader :: URLClassLoader :: SecureClassLoader :: ClassLoader > > I have posted an updated webrev here: > > http://cr.openjdk.java.net/~bpb/7179567/webrev.4/ > > The differences with respect to the previous webrev [1] are: > > 1) the javadoc change of SecureClassLoader has been reverted; > 2) these statements > 665 if (codesource == null) { > 666 return perms; > 667 } > 668 > in URLClassLoader.getPermissions() have been reverted; > 3) the javadoc of getPermissions() in URLClassLoader and AppletClassLoader has been updated to add "@exception NullPointerException if {@code codesource} is {@code null}." > > The CCC request to be associated with this change would indicate that "@exception NullPointerException" has been added to the javadoc of: > > A) all public URLClassLoader constructors; > B) URLClassLoader.findClass(); > C) URLClassLoader.getPermissions(); > D) both URLClassLoader.newInstance() methods; > E) AppletClassLoader.getPermissions(). > > The only actual *code* changes are in URLClassLoader. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/7179567/webrev.3/ > From mike.duigou at oracle.com Thu Oct 10 03:46:15 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Oct 2013 20:46:15 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> Message-ID: <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> On Oct 8 2013, at 01:27 , Paul Sandoz wrote: > Hi Mike, > > I am probably going over old ground here... > > Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry, or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. > > Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? I have created a prototype renovated Map and ConcurrentMap to provide (mostly) separate implementations. http://cr.openjdk.java.net/~mduigou/JDK-8024688.2/0/webrev/ This passes all of the existing regression tests and I believe is performance neutral. The implementations are now more relatively correct for both flavours. ie. Map defaults don't retry and throw CME when they detect that something changed unexpectedly. The ConcurrentMap defaults were mostly just moving over the prior Map defaults but I also removed a few cases of null value handling that were no longer needed. I've wanted to explore this for a while (since June) but haven't previously had a chance. I'm somewhat convinced that this is the right direction to be going but I am sure further refinement is possible (particularly in regards to the spec). > The defaults on Map could state they are not suitable for maps that can be concurrently modified, if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) > > I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? I realized that some of the statements about "implementations must document how they handle nulls with this method" were no longer relevant. The null handling behaviour was entirely covered by the class documentation and the method specification. This is mostly a consequence of having added "or is mapped to null value" in couple of cases later on in the process. Thanks for pushing on this point (and David Holmes for earlier suggestion that this might be important) Mike > Paul. > > On Oct 4, 2013, at 5:35 AM, Mike Duigou wrote: > >> Hello all; >> >> This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. >> >> The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ >> >> Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. >> >> Mike > From john.r.rose at oracle.com Thu Oct 10 04:07:29 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Oct 2013 21:07:29 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <52561FB6.1060301@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> Message-ID: <058B94A2-4038-4969-8D00-E8553334ACE4@oracle.com> On Oct 9, 2013, at 8:32 PM, David Holmes wrote: > I'm unsure if it should be "is null" or "are null" given the initial subject is singular and latter subject is plural. The English major in me surfaces briefly to note that "any" can be either singular or plural: "Pick a card, any card" (singular) vs. "any takers?" (plural). Brian's works well enough as a singular. Etymologically, "any" (like "an") is a cognate of the word "one". ? John From david.holmes at oracle.com Thu Oct 10 04:43:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 14:43:16 +1000 Subject: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing In-Reply-To: <52554444.40402@oracle.com> References: <52554444.40402@oracle.com> Message-ID: <52563064.8090406@oracle.com> On 9/10/2013 9:55 PM, Alan Bateman wrote: > > This test has been failing (very intermittently) for some time. It was > assumed to be a HotSpot issue on SPARC but more recently it has been > duplicated on Linux x64 too. David Simms has notes in the bug [1] from > this instrumentation and analysis, and Doug has pushed a fix to his CVS > that fixes the issue (although they may still be an underlying issue > that still needs to be hunted down). > > Doug's fix updates AQS and AQLS to re-read the head and avoid the race. > We need to bring this into jdk8/tl, the webrev with the patch is here: > > http://cr.openjdk.java.net/~alanb/7011859/webrev/ Reviewed! Thanks Alan (and Doug and David S.) David H. -------- > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-7011859 From shanliang.jiang at oracle.com Thu Oct 10 06:49:33 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 06:49:33 +0000 Subject: hg: jdk8/tl/jdk: 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Message-ID: <20131010064945.52B3A62EC3@hg.openjdk.java.net> Changeset: e8097e1e18a7 Author: sjiang Date: 2013-10-10 08:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8097e1e18a7 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/monitor/NullAttributeValueTest.java From shanliang.jiang at oracle.com Thu Oct 10 06:38:38 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 06:38:38 +0000 Subject: hg: jdk8/tl/jdk: 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Message-ID: <20131010063900.29E1C62EC1@hg.openjdk.java.net> Changeset: e901a618dcff Author: sjiang Date: 2013-10-10 08:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e901a618dcff 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Reviewed-by: dfuchs, dholmes ! test/javax/management/monitor/CounterMonitorThresholdTest.java From shanliang.jiang at oracle.com Thu Oct 10 07:04:02 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 07:04:02 +0000 Subject: hg: jdk8/tl/jdk: 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Message-ID: <20131010070414.34A2A62EC4@hg.openjdk.java.net> Changeset: a30f6fd581b3 Author: sjiang Date: 2013-10-10 09:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a30f6fd581b3 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java From cowwoc at bbs.darktech.org Thu Oct 10 07:22:04 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 10 Oct 2013 03:22:04 -0400 Subject: @SafeVarargs on final classes Message-ID: <5256559C.4070007@bbs.darktech.org> Hi, JDK7 triggers a compiler error on non-final methods annotated with @SafeVarargs even if the class itself is final. I couldn't find any literature indicating whether this is intentional (the Javadoc states that the method must be final but says nothing about final classes). Can we change the behavior so final classes no longer trigger a compiler error? Gili From cowwoc at bbs.darktech.org Thu Oct 10 07:27:59 2013 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 10 Oct 2013 03:27:59 -0400 Subject: @SafeVarargs on final classes In-Reply-To: <5256559C.4070007@bbs.darktech.org> References: <5256559C.4070007@bbs.darktech.org> Message-ID: <525656FF.3020809@bbs.darktech.org> On 10/10/2013 3:22 AM, cowwoc wrote: > Hi, > > JDK7 triggers a compiler error on non-final methods annotated with > @SafeVarargs even if the class itself is final. I couldn't find any > literature indicating whether this is intentional (the Javadoc states > that the method must be final but says nothing about final classes). > Can we change the behavior so final classes no longer trigger a > compiler error? > > Gili A follow-up question is why the "Possible heap pollution" warning shows for interface methods since @SafeVarargs cannot be used to suppress it (an interface method cannot be final). Gili From staffan.larsen at oracle.com Thu Oct 10 07:38:46 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 10 Oct 2013 07:38:46 +0000 Subject: hg: jdk8/tl/jdk: 8025427: jstat tests fails on 32-bit platforms Message-ID: <20131010073859.3EABA62EC9@hg.openjdk.java.net> Changeset: 6aa637dde16e Author: sla Date: 2013-10-10 09:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6aa637dde16e 8025427: jstat tests fails on 32-bit platforms Reviewed-by: ehelin, dsamersoff, dholmes, sspitsyn ! src/share/classes/sun/tools/jstat/RowClosure.java ! test/ProblemList.txt ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk From weijun.wang at oracle.com Thu Oct 10 07:26:37 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 10 Oct 2013 07:26:37 +0000 Subject: hg: jdk8/tl/jdk: 8026235: keytool NSS test should use 64 bit lib on Solaris Message-ID: <20131010072652.AE4E062EC5@hg.openjdk.java.net> Changeset: 74b4d20769fd Author: weijun Date: 2013-10-10 15:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74b4d20769fd 8026235: keytool NSS test should use 64 bit lib on Solaris Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh From staffan.larsen at oracle.com Thu Oct 10 08:43:56 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 10 Oct 2013 08:43:56 +0000 Subject: hg: jdk8/tl/jdk: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Message-ID: <20131010084446.2952162ED0@hg.openjdk.java.net> Changeset: 998560cccefc Author: allwin Date: 2013-10-10 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/998560cccefc 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Reviewed-by: sla, mgronlun, dholmes, jbachorik, chegar ! test/com/sun/jdi/NoLaunchOptionTest.java From alan.bateman at oracle.com Thu Oct 10 09:01:24 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 10 Oct 2013 09:01:24 +0000 Subject: hg: jdk8/tl/jdk: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Message-ID: <20131010090153.05EAF62ED4@hg.openjdk.java.net> Changeset: 99b7bbe0474f Author: dl Date: 2013-10-10 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99b7bbe0474f 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Reviewed-by: alanb, dholmes ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java From david.holmes at oracle.com Thu Oct 10 08:59:24 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 10 Oct 2013 08:59:24 +0000 Subject: hg: jdk8/tl/jdk: 8026232: Move libnpt from profile compact1 to compact3 Message-ID: <20131010085955.5711062ED3@hg.openjdk.java.net> Changeset: 254173b48dcb Author: dholmes Date: 2013-10-10 04:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/254173b48dcb 8026232: Move libnpt from profile compact1 to compact3 Reviewed-by: mchung, alanb ! makefiles/profile-includes.txt From david.holmes at oracle.com Thu Oct 10 09:06:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 19:06:14 +1000 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Message-ID: <52566E06.8060208@oracle.com> Hi Karen, On 10/10/2013 8:13 AM, Karen Kinnear wrote: > > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026213 > > Summary: > Reflection generates code dynamically to speed up reflection processing after startup. The first > 15 runs of a reflection call use the vm code path, after that we use the generated code path, which > needs to use invokespecial on private methods in interfaces. Minor nit: 30 import java.lang.reflect.*; The approved style these days is to list the exact imports needed rather than rely on import-on-demand. Otherwise change seems fine. Is the VM side of this already in place or does this need to sync with a VM change? Thanks, David > Tested: > Test attached to the bug > > Also - all the 8011311 private method testing was run with this in the build: > Robert Field's TypeTest > 8025475 test > defmeth privatemethodstest with reflection > John Rose's intfbug > jtreg: java.util, java.lang > jck vm, lang > > thanks, > Karen > > From paul.sandoz at oracle.com Thu Oct 10 09:13:54 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Oct 2013 11:13:54 +0200 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Message-ID: On Oct 10, 2013, at 12:13 AM, Karen Kinnear wrote: > > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026213 > > Summary: > Reflection generates code dynamically to speed up reflection processing after startup. The first > 15 runs of a reflection call use the vm code path, after that we use the generated code path, which > needs to use invokespecial on private methods in interfaces. > You don't need to pass modifiers as a parameter to emitInvoke since it is set as a field on AccessorGenerator and used, e.g. see isStatic(). So perhaps add the following method to AccessorGenerator: protected boolean isPrivate() { return Modifier.isPrivate(modifiers); } and do: 642 if (isInterface()) { 643 if (isPrivate()) { 644 cb.opc_invokespecial(targetMethodRef, count, 0); 645 } else { 646 cb.opc_invokeinterface(targetMethodRef, 647 count, 648 count, 649 typeSizeInStackSlots(returnType)); 650 } 651 } else { 652 cb.opc_invokevirtual(targetMethodRef, 653 count, 654 typeSizeInStackSlots(returnType)); 655 } 656 } 657 } ? Paul. > Tested: > Test attached to the bug > > Also - all the 8011311 private method testing was run with this in the build: > Robert Field's TypeTest > 8025475 test > defmeth privatemethodstest with reflection > John Rose's intfbug > jtreg: java.util, java.lang > jck vm, lang > > thanks, > Karen > > From chris.hegarty at oracle.com Thu Oct 10 09:22:18 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Oct 2013 10:22:18 +0100 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <5255A597.9030007@oracle.com> References: <5255A597.9030007@oracle.com> Message-ID: <525671CA.5080904@oracle.com> Dan, Your changes look fine to me. While looking at this I notice that there is another potential leak. If the malloc for temp fails, then we need to free lc ( for MAC only ), right? -Chris. On 10/09/2013 07:51 PM, Dan Xu wrote: > Hi All, > > This fix is to solve the memory leak issue in ParseLocale() function of > jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, > lc, is copied into temp, it is not necessary to do the strdup(), which > leads to the memery leak. The fix simply removes the line of strdup > operation. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 > > -Dan From forax at univ-mlv.fr Thu Oct 10 09:21:18 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Oct 2013 11:21:18 +0200 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Message-ID: <5256718E.3070408@univ-mlv.fr> On 10/10/2013 12:13 AM, Karen Kinnear wrote: > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026213 > > Summary: > Reflection generates code dynamically to speed up reflection processing after startup. The first > 15 runs of a reflection call use the vm code path, after that we use the generated code path, which > needs to use invokespecial on private methods in interfaces. > > Tested: > Test attached to the bug > > Also - all the 8011311 private method testing was run with this in the build: > Robert Field's TypeTest > 8025475 test > defmeth privatemethodstest with reflection > John Rose's intfbug > jtreg: java.util, java.lang > jck vm, lang > > thanks, > Karen > > Hi Karen, the code is Ok for me. By the way, at some point the comment at the top of emitInvoke() and the corresponding test should be removed because you can not have more than 255/256 parameters for a method. cheers, R?mi From paul.sandoz at oracle.com Thu Oct 10 09:27:36 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Oct 2013 11:27:36 +0200 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> References: <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> Message-ID: <6D4EB62C-ED7D-4EC5-8F99-FA7C8EA8726C@oracle.com> On Oct 9, 2013, at 8:33 PM, Joel Borggren-Franck wrote: > Hi > > Please review this spec update and test for getting array classes and > instances of more dimensions than the class file can express or the VM > can handle. > > Array.newInstance have a test for arrays of more dimensions than 255, > this patch adds a test for Class.forName as well. > > Also the javadoc for Array.newInstance are clarified. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7044282 > Webrev: http://cr.openjdk.java.net/~jfranck/7044282/webrev.00/ > Looks OK, i agree with Joe on the test refactoring. FYI (because i have streams on my brain...). String brackets254 = Stream.generate(() -> "[").limit(254).collect(joining()); or: String name254 = Stream.generate(() -> "[").limit(254).collect(joining("", "", "Ljava.lang.String;")); or: IntFunction nameN = (int n) -> Stream.generate(() -> "[").limit(n).collect(joining("", "", "Ljava.lang.String;")); String name254 = nameN.apply(254); String name254 = nameN.apply(255); String name254 = nameN.apply(256); String name1 = nameN.apply(1); String bigName = nameN.apply(Short.MAX_VALUE + 20); Paul. > cheers > /Joel From michael.x.mcmahon at oracle.com Thu Oct 10 11:38:41 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 10 Oct 2013 11:38:41 +0000 Subject: hg: jdk8/tl/jdk: 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Message-ID: <20131010113908.54B3C62EEB@hg.openjdk.java.net> Changeset: 8294c49d23b3 Author: michaelm Date: 2013-10-10 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8294c49d23b3 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Reviewed-by: alanb, chegar ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + 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 From david.holmes at oracle.com Thu Oct 10 12:06:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 22:06:05 +1000 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <058B94A2-4038-4969-8D00-E8553334ACE4@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <058B94A2-4038-4969-8D00-E8553334ACE4@oracle.com> Message-ID: <5256982D.8050606@oracle.com> On 10/10/2013 2:07 PM, John Rose wrote: > On Oct 9, 2013, at 8:32 PM, David Holmes wrote: > >> I'm unsure if it should be "is null" or "are null" given the initial subject is singular and latter subject is plural. > > The English major in me surfaces briefly to note that "any" can be either singular or plural: "Pick a card, any card" (singular) vs. "any takers?" (plural). Brian's works well enough as a singular. Etymologically, "any" (like "an") is a cognate of the word "one". It isn't the "any" that introduces the plural but "elements". David > ? John > From sundararajan.athijegannathan at oracle.com Thu Oct 10 12:07:16 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 12:07:16 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131010120727.9160A62EEC@hg.openjdk.java.net> Changeset: 03a68e7ca1d5 Author: lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java - src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8026137.js + test/script/basic/JDK-8026137.js.EXPECTED Changeset: 7cc5ff16380f Author: sundar Date: 2013-10-10 11:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7cc5ff16380f 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/script/assert.js ! test/script/basic/JDK-8019508.js ! test/script/basic/JDK-8019508.js.EXPECTED ! test/script/basic/JDK-8019553.js ! test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/JDK-8019791.js ! test/script/basic/JDK-8019791.js.EXPECTED ! test/script/basic/JDK-8019805.js ! test/script/basic/JDK-8019805.js.EXPECTED + test/script/basic/JDK-8026167.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-100.js.EXPECTED ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-293.js.EXPECTED ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-40.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-98.js.EXPECTED ! test/script/basic/eval.js ! test/script/basic/eval.js.EXPECTED Changeset: e60bbcf2f6b6 Author: sundar Date: 2013-10-10 13:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e60bbcf2f6b6 8026248: importClass has to be a varargs function Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026248.js + test/script/basic/JDK-8026248.js.EXPECTED From joel.franck at oracle.com Thu Oct 10 08:56:35 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 10 Oct 2013 08:56:35 +0000 Subject: hg: jdk8/tl/langtools: 8021237: clean up JavacAnnotatedConstruct Message-ID: <20131010085713.4CF4062ED1@hg.openjdk.java.net> Changeset: 1e7ad879f15e Author: alundblad Date: 2013-10-10 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e7ad879f15e 8021237: clean up JavacAnnotatedConstruct Summary: Refactored the static helper methods in JavacAnnoConstructs into ordinary methods and put them in a common superclass (AnnoConstruct) of Symbol and Type. Reviewed-by: jjg, vromero, jfranck + src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java From ivan.gerasimov at oracle.com Thu Oct 10 12:43:37 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 10 Oct 2013 16:43:37 +0400 Subject: [7u-dev] Request for review of backport 7147084 In-Reply-To: <52552A90.4090104@oracle.com> References: <52415B60.5050608@oracle.com> <5242EA3F.7040307@oracle.com> <52550A18.50501@oracle.com> <52552A90.4090104@oracle.com> Message-ID: <5256A0F9.7030803@oracle.com> Thank you Alan! On 09.10.2013 14:06, Alan Bateman wrote: > On 09/10/2013 08:47, Ivan Gerasimov wrote: >> Alan, Rob, Martin, >> >> Would you please help review the backport? I see that you were the >> reviewers for the master fix. >> I need a review for the backport, since the patch couldn't get >> applied cleanly. >> >> Here are the changes I had to make: >> - I had to manually replace Java_java_lang_ProcessImpl_create() >> function body with the new version, as 'hg patch' could not handle it >> automatically. >> - I had to replace wide-char strings to regular char*, in all the >> calls to win32Error() function. >> >> Thanks in advance, >> Ivan >> > I looked over the webrev and it seems to match the jdk8 changes except > for the win32Error usage. So I think it's okay. One thing to mention > is that there is a patch under review to fix issues with the test so > this should probably be pushed to jdk7u-dev too. > Yes, thanks. I'll keep an eye on it. Sincerely yous, Ivan From joel.franck at oracle.com Thu Oct 10 12:46:22 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 10 Oct 2013 14:46:22 +0200 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <52561ACE.8090800@oracle.com> <6D4EB62C-ED7D-4EC5-8F99-FA7C8EA8726C@oracle.com> <20131009183307.GQ1969@jfranck-desktop.jrpg.bea.com> Message-ID: <20131010124622.GS1969@jfranck-desktop.jrpg.bea.com> Hi, Joe, Paul, agreed the test could be better. Improved it (without using streams) and also added a bug id tag to the old Arrays.newInstance test. Thanks for the comments. Webrev here: http://cr.openjdk.java.net/~jfranck/7044282/webrev.01/ cheres /Joel On 2013-10-09, Joel Borggren-Franck wrote: > Hi > > Please review this spec update and test for getting array classes and > instances of more dimensions than the class file can express or the VM > can handle. > > Array.newInstance have a test for arrays of more dimensions than 255, > this patch adds a test for Class.forName as well. > > Also the javadoc for Array.newInstance are clarified. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7044282 > Webrev: http://cr.openjdk.java.net/~jfranck/7044282/webrev.00/ > > cheers > /Joel From paul.sandoz at oracle.com Thu Oct 10 12:56:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Oct 2013 14:56:14 +0200 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <20131010124622.GS1969@jfranck-desktop.jrpg.bea.com> References: <20131010124622.GS1969@jfranck-desktop.jrpg.bea.com> Message-ID: <5088349C-ED02-433F-81E4-16413DF991EF@oracle.com> On Oct 10, 2013, at 2:46 PM, Joel Borggren-Franck wrote: > Hi, > > Joe, Paul, agreed the test could be better. Improved it (without using > streams) and also added a bug id tag to the old Arrays.newInstance test. > > Thanks for the comments. > > Webrev here: http://cr.openjdk.java.net/~jfranck/7044282/webrev.01/ > Looks OK. Paul. From joel.franck at oracle.com Thu Oct 10 13:02:54 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 10 Oct 2013 15:02:54 +0200 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Message-ID: <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> Hi Karen, I agree with the others, the code looks good though I like Paul's suggestion. Silly question perhaps, do you know if we have good test coverage on actually reflectively invoking a Method more than 15 times? cheers /Joel On 2013-10-09, Karen Kinnear wrote: > > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026213 > > Summary: > Reflection generates code dynamically to speed up reflection processing after startup. The first > 15 runs of a reflection call use the vm code path, after that we use the generated code path, which > needs to use invokespecial on private methods in interfaces. > > Tested: > Test attached to the bug > > Also - all the 8011311 private method testing was run with this in the build: > Robert Field's TypeTest > 8025475 test > defmeth privatemethodstest with reflection > John Rose's intfbug > jtreg: java.util, java.lang > jck vm, lang > > thanks, > Karen > > From daniel.fuchs at oracle.com Thu Oct 10 13:11:46 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 10 Oct 2013 15:11:46 +0200 Subject: RFR: 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger Message-ID: <5256A792.1000305@oracle.com> Hi, Please find below a patch for 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger https://bugs.openjdk.java.net/browse/JDK-8011638 best regards, -- daniel From aleksej.efimov at oracle.com Thu Oct 10 13:30:05 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 10 Oct 2013 17:30:05 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g Message-ID: <5256ABDD.9060900@oracle.com> Hi, Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. The brief list of changes: 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). 2. a) Updates to long time zone names b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) c) Removed unused ACT[] array d) Added "Europe/Busingen" time zone name All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files The following tests were executed on JDK 8 with fix: test/java/util/TimeZone test/java/util/Calendar test/java/util/Formatter test/sun/util/calendar test/java/time Testing result: All test passed Thanks! Aleksej [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ From paul.sandoz at oracle.com Thu Oct 10 13:37:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Oct 2013 15:37:40 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> Message-ID: <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> Hi Mike, This looks like a good direction. Need to look more closely. I wonder if we even require such detailed support to throw CME? For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". Paul. On Oct 10, 2013, at 5:46 AM, Mike Duigou wrote: > > On Oct 8 2013, at 01:27 , Paul Sandoz wrote: > >> Hi Mike, >> >> I am probably going over old ground here... >> >> Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry, or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. >> >> Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? > > I have created a prototype renovated Map and ConcurrentMap to provide (mostly) separate implementations. > > http://cr.openjdk.java.net/~mduigou/JDK-8024688.2/0/webrev/ > > This passes all of the existing regression tests and I believe is performance neutral. The implementations are now more relatively correct for both flavours. ie. Map defaults don't retry and throw CME when they detect that something changed unexpectedly. The ConcurrentMap defaults were mostly just moving over the prior Map defaults but I also removed a few cases of null value handling that were no longer needed. > > I've wanted to explore this for a while (since June) but haven't previously had a chance. I'm somewhat convinced that this is the right direction to be going but I am sure further refinement is possible (particularly in regards to the spec). > >> The defaults on Map could state they are not suitable for maps that can be concurrently modified, if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) >> >> I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? > > I realized that some of the statements about "implementations must document how they handle nulls with this method" were no longer relevant. The null handling behaviour was entirely covered by the class documentation and the method specification. This is mostly a consequence of having added "or is mapped to null value" in couple of cases later on in the process. > > Thanks for pushing on this point (and David Holmes for earlier suggestion that this might be important) > > Mike > >> Paul. >> >> On Oct 4, 2013, at 5:35 AM, Mike Duigou wrote: >> >>> Hello all; >>> >>> This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. >>> >>> The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ >>> >>> Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. >>> >>> Mike >> > From karen.kinnear at oracle.com Thu Oct 10 13:47:01 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Oct 2013 09:47:01 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> Message-ID: <431737C3-8B89-4DEB-9594-5CFA578CA5CB@oracle.com> Paul, Thank you so much for the review and suggestion. I will rewrite this this way and resend. thanks! Karen On Oct 10, 2013, at 5:13 AM, Paul Sandoz wrote: > > On Oct 10, 2013, at 12:13 AM, Karen Kinnear wrote: > >> >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >> needs to use invokespecial on private methods in interfaces. >> > > You don't need to pass modifiers as a parameter to emitInvoke since it is set as a field on AccessorGenerator and used, e.g. see isStatic(). > > So perhaps add the following method to AccessorGenerator: > > protected boolean isPrivate() { > return Modifier.isPrivate(modifiers); > } > > and do: > > 642 if (isInterface()) { > > 643 if (isPrivate()) { > 644 cb.opc_invokespecial(targetMethodRef, count, 0); > 645 } else { > > 646 cb.opc_invokeinterface(targetMethodRef, > 647 count, > 648 count, > 649 typeSizeInStackSlots(returnType)); > > 650 } > > 651 } else { > 652 cb.opc_invokevirtual(targetMethodRef, > 653 count, > 654 typeSizeInStackSlots(returnType)); > 655 } > 656 } > 657 } > > ? > > Paul. > >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >> > From karen.kinnear at oracle.com Thu Oct 10 13:48:06 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Oct 2013 09:48:06 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <5256718E.3070408@univ-mlv.fr> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <5256718E.3070408@univ-mlv.fr> Message-ID: Thank you Remi. I'm actually going to leave the assertion. We are frequently asked to expand limits and catching this if that time ever happens would make our lives much easier. thanks, Karen On Oct 10, 2013, at 5:21 AM, Remi Forax wrote: > On 10/10/2013 12:13 AM, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >> needs to use invokespecial on private methods in interfaces. >> >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >> > > Hi Karen, > the code is Ok for me. > > By the way, at some point the comment at the top of emitInvoke() and the corresponding test > should be removed because you can not have more than 255/256 parameters for a method. > > cheers, > R?mi > From karen.kinnear at oracle.com Thu Oct 10 13:49:19 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Oct 2013 09:49:19 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <52566E06.8060208@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <52566E06.8060208@oracle.com> Message-ID: David, Thanks for the information. The VM side of this is 8011311 which pushed on 10/8 to jdk8 master to be part of JDK8b111. thanks, Karen On Oct 10, 2013, at 5:06 AM, David Holmes wrote: > Hi Karen, > > On 10/10/2013 8:13 AM, Karen Kinnear wrote: >> >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >> needs to use invokespecial on private methods in interfaces. > > Minor nit: > > 30 import java.lang.reflect.*; > > The approved style these days is to list the exact imports needed rather than rely on import-on-demand. > > Otherwise change seems fine. Is the VM side of this already in place or does this need to sync with a VM change? > > Thanks, > David > > >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >> From Alan.Bateman at oracle.com Thu Oct 10 13:52:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Oct 2013 14:52:53 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> Message-ID: <5256B135.2020507@oracle.com> On 09/10/2013 19:16, Brian Burkhalter wrote: > : > I have created a simple implementation for option B: > > http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ > > I should note that the Unix Inet6 implementation was already using the call ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in this case the message should already have been useful. This call formats the UHE message such as would: > > sprintf(error_message, "%s: %s", hostname, gai_strerror(error)) > > I changed the Unix Inet4 implementation to do this as well instead of calling JNU_ThrowByName(). Thanks for persevering with this, we are on the right road now. I just looked at JDK-8010371 and the "OS" field is set to "linux". I don't know if this is right but as IPv6 is usually enabled by default these days then I have to guess that the person that submitted the bug has IPv6 disabled or is running with -Djava.net.preferIPv4Stack=true, otherwise it would be a non-issue (as you have discovered). The other thing about your observation is that ThrowUnknownHostExceptionWithGaiError is creating the UHE with the both the hostname and the error message. This resolves to the concern in one or two of the mails that the UHE names the exception message "host" and that someone might assume that the exception detail is the hostname. So thumbs up on the update to src/solaris/native/java/net/Inet4Address.c. > > For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments. > Inet4AddressImpl.lookupAllHostAddr uses gethostbyname and when I look at the MSDN documentation then I don't see EAI_AGAIN as possible error. It does list WSATRY_AGAIN and I'm wondering if they have the same value and whether the WSA* error is only returned by WSAGetLastError? However I think we have a problem with using gai_strerror here as the MSDN documentation says that it is not thread safe. This means we may have to look for a WSA equivalent or maybe drop the Windows part of the fix (using a mutex of some synchronization might be possible but the scope would require research and of course it wouldn't work with 3rd party native code that is also using it). -Alan From joe.darcy at oracle.com Thu Oct 10 13:56:24 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Oct 2013 06:56:24 -0700 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <5088349C-ED02-433F-81E4-16413DF991EF@oracle.com> References: <20131010124622.GS1969@jfranck-desktop.jrpg.bea.com> <5088349C-ED02-433F-81E4-16413DF991EF@oracle.com> Message-ID: <5256B208.1060406@oracle.com> Looks fine; thanks, -Joe On 10/10/2013 5:56 AM, Paul Sandoz wrote: > On Oct 10, 2013, at 2:46 PM, Joel Borggren-Franck wrote: > >> Hi, >> >> Joe, Paul, agreed the test could be better. Improved it (without using >> streams) and also added a bug id tag to the old Arrays.newInstance test. >> >> Thanks for the comments. >> >> Webrev here: http://cr.openjdk.java.net/~jfranck/7044282/webrev.01/ >> > Looks OK. > > Paul. From paul.sandoz at oracle.com Thu Oct 10 14:23:51 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Oct 2013 16:23:51 +0200 Subject: RFR: 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger In-Reply-To: <5256A792.1000305@oracle.com> References: <5256A792.1000305@oracle.com> Message-ID: <8DC242B8-D9E5-4A98-B2D7-C5D3D78E0FFA@oracle.com> +1 Please send a tweet to @DrDeprecator when pushed https://twitter.com/DrDeprecator :-) Paul. On Oct 10, 2013, at 3:11 PM, Daniel Fuchs wrote: > Hi, > > Please find below a patch for > 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger > https://bugs.openjdk.java.net/browse/JDK-8011638 > > > > best regards, > > -- daniel From karen.kinnear at oracle.com Thu Oct 10 14:32:41 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Oct 2013 10:32:41 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> Message-ID: Joel, Thank you for the review. Actually, that is a very good question. We will be adding the test case for this one to our vm side defmeth.PrivateMethodsTest, because you have to create a classfile since private methods in interfaces are not supported by javac, they are for internal use for Lambda support. So it was decided to not try to add them to the java reflection tests. Good question - I brought this up once with Tristan and Amy who were writing reflection tests for lambda. I will ask again about reflection coverage for invoking a method more than 15 times. thanks, Karen On Oct 10, 2013, at 9:02 AM, Joel Borggren-Franck wrote: > Hi Karen, > > I agree with the others, the code looks good though I like Paul's > suggestion. > > Silly question perhaps, do you know if we have good test coverage on > actually reflectively invoking a Method more than 15 times? > > cheers > /Joel > > On 2013-10-09, Karen Kinnear wrote: >> >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >> needs to use invokespecial on private methods in interfaces. >> >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >> From Alan.Bateman at oracle.com Thu Oct 10 14:49:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Oct 2013 15:49:12 +0100 Subject: RFR: 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger In-Reply-To: <5256A792.1000305@oracle.com> References: <5256A792.1000305@oracle.com> Message-ID: <5256BE68.8000101@oracle.com> On 10/10/2013 14:11, Daniel Fuchs wrote: > Hi, > > Please find below a patch for > 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger > https://bugs.openjdk.java.net/browse/JDK-8011638 > > This looks okay to me too. You might want to wait for a reply to Mandy in case there is anything else (I can't think of anything but Mandy has the history, and the scars). -Alan. From karen.kinnear at oracle.com Thu Oct 10 16:02:10 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Oct 2013 12:02:10 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <431737C3-8B89-4DEB-9594-5CFA578CA5CB@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <431737C3-8B89-4DEB-9594-5CFA578CA5CB@oracle.com> Message-ID: <83CA33BB-9F2D-4CC4-B6CB-21D31BBD6FCE@oracle.com> Updated webrev: >>> webrev: http://cr.openjdk.java.net/~acorn/8026213.2/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 Testing: Specific test for private methods (attached to bug) jtreg jdk java.lang, sun.reflect thanks, Karen p.s. this should look very much like Paul's suggestion - thank you again On Oct 10, 2013, at 9:47 AM, Karen Kinnear wrote: > Paul, > > Thank you so much for the review and suggestion. I will rewrite this this way and resend. > > thanks! > Karen > > On Oct 10, 2013, at 5:13 AM, Paul Sandoz wrote: > >> >> On Oct 10, 2013, at 12:13 AM, Karen Kinnear wrote: >> >>> >>> Please review: >>> >>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >>> >>> Summary: >>> Reflection generates code dynamically to speed up reflection processing after startup. The first >>> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >>> needs to use invokespecial on private methods in interfaces. >>> >> >> You don't need to pass modifiers as a parameter to emitInvoke since it is set as a field on AccessorGenerator and used, e.g. see isStatic(). >> >> So perhaps add the following method to AccessorGenerator: >> >> protected boolean isPrivate() { >> return Modifier.isPrivate(modifiers); >> } >> >> and do: >> >> 642 if (isInterface()) { >> >> 643 if (isPrivate()) { >> 644 cb.opc_invokespecial(targetMethodRef, count, 0); >> 645 } else { >> >> 646 cb.opc_invokeinterface(targetMethodRef, >> 647 count, >> 648 count, >> 649 typeSizeInStackSlots(returnType)); >> >> 650 } >> >> 651 } else { >> 652 cb.opc_invokevirtual(targetMethodRef, >> 653 count, >> 654 typeSizeInStackSlots(returnType)); >> 655 } >> 656 } >> 657 } >> >> ? >> >> Paul. >> >>> Tested: >>> Test attached to the bug >>> >>> Also - all the 8011311 private method testing was run with this in the build: >>> Robert Field's TypeTest >>> 8025475 test >>> defmeth privatemethodstest with reflection >>> John Rose's intfbug >>> jtreg: java.util, java.lang >>> jck vm, lang >>> >>> thanks, >>> Karen >>> >>> >> > From shanliang.jiang at oracle.com Thu Oct 10 15:48:09 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 15:48:09 +0000 Subject: hg: jdk8/tl/jdk: 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Message-ID: <20131010154859.B08D062F01@hg.openjdk.java.net> Changeset: cab80088c671 Author: sjiang Date: 2013-10-10 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cab80088c671 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Reviewed-by: dholmes, jbachorik ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java From joel.franck at oracle.com Thu Oct 10 16:19:01 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 10 Oct 2013 16:19:01 +0000 Subject: hg: jdk8/tl/jdk: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Message-ID: <20131010161931.9663E62F04@hg.openjdk.java.net> Changeset: f25d9d8811ca Author: jfranck Date: 2013-10-10 18:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f25d9d8811ca 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Reviewed-by: darcy, psandoz ! src/share/classes/java/lang/reflect/Array.java + test/java/lang/Class/forName/arrayClass/Class1.java + test/java/lang/Class/forName/arrayClass/Class2.java + test/java/lang/Class/forName/arrayClass/Class3.java + test/java/lang/Class/forName/arrayClass/Class4.java + test/java/lang/Class/forName/arrayClass/ExceedMaxDim.java ! test/java/lang/reflect/Array/ExceedMaxDim.java From huizhe.wang at oracle.com Thu Oct 10 16:47:36 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 10 Oct 2013 09:47:36 -0700 Subject: RFR (JAXP) : 8003262 reverse translation required changes In-Reply-To: References: <525593F4.10208@oracle.com> Message-ID: <5256DA28.9030407@oracle.com> Hi Daniel, Lance, I've updated the webrev to include other resource bundles. The changes are the same. http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ Thanks, Joe On 10/9/2013 10:58 AM, Lance Andersen - Oracle wrote: > +1 > On Oct 9, 2013, at 1:35 PM, huizhe wang wrote: > >> Hi, >> >> These resource bundles in JAXP were refactored due to request by WPTG. Now that the WPTG tool has been approved to support the original format, I'm reverting the previous change back to the original format: >> >> http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ >> >> Thanks, >> Joe > > > 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 Lance.Andersen at oracle.com Thu Oct 10 16:57:48 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 10 Oct 2013 12:57:48 -0400 Subject: RFR (JAXP) : 8003262 reverse translation required changes In-Reply-To: <5256DA28.9030407@oracle.com> References: <525593F4.10208@oracle.com> <5256DA28.9030407@oracle.com> Message-ID: <5E4F45FC-B347-41C4-B5E4-8DF1A3703958@oracle.com> Hi Joe, I skimmed all of the changes and they look in line with the previous so +1 Best Lance On Oct 10, 2013, at 12:47 PM, huizhe wang wrote: > Hi Daniel, Lance, > > I've updated the webrev to include other resource bundles. The changes are the same. > > http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ > > Thanks, > Joe > > > On 10/9/2013 10:58 AM, Lance Andersen - Oracle wrote: >> +1 >> On Oct 9, 2013, at 1:35 PM, huizhe wang wrote: >> >>> Hi, >>> >>> These resource bundles in JAXP were refactored due to request by WPTG. Now that the WPTG tool has been approved to support the original format, I'm reverting the previous change back to the original format: >>> >>> http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ >>> >>> Thanks, >>> Joe >> >> >> 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 >> > -------------- 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 Oct 10 17:15:44 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Oct 2013 10:15:44 -0700 Subject: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing In-Reply-To: <52554444.40402@oracle.com> References: <52554444.40402@oracle.com> Message-ID: I recall trying to grok this code in AQS when it first went in - it has some of the most difficult code in java.util.concurrent. It is not entirely surprising there might be a race left that we have just fixed, but I would be happier if we had a clearer understanding ("proof" of correctness) and clearer repro recipe. I'm glad the work we did on RacingFoo tests paid off in finding bugs. Does David Simms recommend any changes to RacingReleases (he's done the most to repro/instrument this test)? On Wed, Oct 9, 2013 at 4:55 AM, Alan Bateman wrote: > > This test has been failing (very intermittently) for some time. It was > assumed to be a HotSpot issue on SPARC but more recently it has been > duplicated on Linux x64 too. David Simms has notes in the bug [1] from this > instrumentation and analysis, and Doug has pushed a fix to his CVS that > fixes the issue (although they may still be an underlying issue that still > needs to be hunted down). > > Doug's fix updates AQS and AQLS to re-read the head and avoid the race. We > need to bring this into jdk8/tl, the webrev with the patch is here: > > http://cr.openjdk.java.net/~**alanb/7011859/webrev/ > > -Alan > > [1] https://bugs.openjdk.java.net/**browse/JDK-7011859 > From bhavesh.x.patel at oracle.com Thu Oct 10 17:52:29 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 10 Oct 2013 17:52:29 +0000 Subject: hg: jdk8/tl/langtools: 8025633: Fix javadoc to generate valid anchor names Message-ID: <20131010175322.BB19962F20@hg.openjdk.java.net> Changeset: 933ba3f81a87 Author: bpatel Date: 2013-10-10 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/933ba3f81a87 8025633: Fix javadoc to generate valid anchor names Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/SectionName.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java + test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testAnchorNames/pkg1/DeprMemClass.java + test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java ! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java From eric.mccorkle at oracle.com Thu Oct 10 17:56:29 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 10 Oct 2013 17:56:29 +0000 Subject: hg: jdk8/tl/langtools: 8019461: Clean up javac diagnostics; ... Message-ID: <20131010175642.9149F62F23@hg.openjdk.java.net> Changeset: 6dcf94e32a3a Author: emc Date: 2013-10-10 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6dcf94e32a3a 8019461: Clean up javac diagnostics 7196553: Review error messages for repeating annotations Summary: Changes to the diagnostic messages to improve clarity and JLS coherence Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/InterfaceOrArrayExpected.java + test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java From brian.burkhalter at oracle.com Thu Oct 10 18:05:53 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Oct 2013 11:05:53 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <52561FB6.1060301@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> Message-ID: On Oct 9, 2013, at 8:32 PM, David Holmes wrote: > In the text: > > * @exception NullPointerException if {@code urls} or any of its elements > * is {@code null} > > I'm unsure if it should be "is null" or "are null" given the initial subject is singular and latter subject is plural. Existing similar phrases seem to be split roughly 50-50. I have changed these to * @exception NullPointerException if {@code urls} or at least one of its * elements is {@code null}. Update: http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ > Nit: In the test there are a few places where you have t on a line by itself: > > 65 t); > > but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + I don't see what you are referring to. Thanks, Brian From brian.burkhalter at oracle.com Thu Oct 10 18:21:36 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Oct 2013 11:21:36 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> Message-ID: <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: >> Nit: In the test there are a few places where you have t on a line by itself: >> >> 65 t); >> >> but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + > > I don't see what you are referring to. Oh, sorry, now I do. Will update. Brian From dmitry.samersoff at oracle.com Thu Oct 10 19:21:00 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Oct 2013 23:21:00 +0400 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <5256B135.2020507@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> Message-ID: <5256FE1C.4030001@oracle.com> Alan, getaddrinfo could return EAI_AGAIN[1] But recomended way is to just check return value of getaddrinfo and then use WSA functions especially, FormatMessage[2] instead of gai_strerror. Also we may consider rewriting this code using GetAddrInfoW sometimes in a future to support IDN. PS: Brian, please notice mixing WSA and EAI at ll. 137. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351(v=vs.85).aspx On 2013-10-10 17:52, Alan Bateman wrote: > On 09/10/2013 19:16, Brian Burkhalter wrote: >> : >> I have created a simple implementation for option B: >> >> http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ >> >> I should note that the Unix Inet6 implementation was already using the call ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in this case the message should already have been useful. This call formats the UHE message such as would: >> >> sprintf(error_message, "%s: %s", hostname, gai_strerror(error)) >> >> I changed the Unix Inet4 implementation to do this as well instead of calling JNU_ThrowByName(). > Thanks for persevering with this, we are on the right road now. > > I just looked at JDK-8010371 and the "OS" field is set to "linux". I > don't know if this is right but as IPv6 is usually enabled by default > these days then I have to guess that the person that submitted the bug > has IPv6 disabled or is running with -Djava.net.preferIPv4Stack=true, > otherwise it would be a non-issue (as you have discovered). > > The other thing about your observation is that > ThrowUnknownHostExceptionWithGaiError is creating the UHE with the both > the hostname and the error message. This resolves to the concern in one > or two of the mails that the UHE names the exception message "host" and > that someone might assume that the exception detail is the hostname. > > So thumbs up on the update to src/solaris/native/java/net/Inet4Address.c. > >> >> For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments. >> > Inet4AddressImpl.lookupAllHostAddr uses gethostbyname and when I look at > the MSDN documentation then I don't see EAI_AGAIN as possible error. It > does list WSATRY_AGAIN and I'm wondering if they have the same value and > whether the WSA* error is only returned by WSAGetLastError? > > However I think we have a problem with using gai_strerror here as the > MSDN documentation says that it is not thread safe. This means we may > have to look for a WSA equivalent or maybe drop the Windows part of the > fix (using a mutex of some synchronization might be possible but the > scope would require research and of course it wouldn't work with 3rd > party native code that is also using it). > > -Alan > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From brian.burkhalter at oracle.com Thu Oct 10 19:24:09 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Oct 2013 12:24:09 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> Message-ID: <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> On Oct 10, 2013, at 11:21 AM, Brian Burkhalter wrote: > On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: > >>> Nit: In the test there are a few places where you have t on a line by itself: >>> >>> 65 t); >>> >>> but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + >> >> I don't see what you are referring to. > > Oh, sorry, now I do. Will update. I hope that as of now all nits have been picked. http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ Thanks, Brian From brian.burkhalter at oracle.com Thu Oct 10 19:37:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Oct 2013 12:37:05 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <5256B135.2020507@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> Message-ID: <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> On Oct 10, 2013, at 6:52 AM, Alan Bateman wrote: > Thanks for persevering with this, we are on the right road now. > > I just looked at JDK-8010371 and the "OS" field is set to "linux". I don't know if this is right but as IPv6 is usually enabled by default these days then I have to guess that the person that submitted the bug has IPv6 disabled or is running with -Djava.net.preferIPv4Stack=true, otherwise it would be a non-issue (as you have discovered). > > The other thing about your observation is that ThrowUnknownHostExceptionWithGaiError is creating the UHE with the both the hostname and the error message. This resolves to the concern in one or two of the mails that the UHE names the exception message "host" and that someone might assume that the exception detail is the hostname. > > So thumbs up on the update to src/solaris/native/java/net/Inet4Address.c. Thanks. >> For Windows I added a similar NET_ ThrowUnknownHostExceptionWithGaiError and modified Inet{4,6} to mimic the Unix case. Note that the Windows code has not yet been compiled pending comments. >> > Inet4AddressImpl.lookupAllHostAddr uses gethostbyname and when I look at the MSDN documentation then I don't see EAI_AGAIN as possible error. It does list WSATRY_AGAIN and I'm wondering if they have the same value and whether the WSA* error is only returned by WSAGetLastError? This symbolic name definition #define EAI_AGAIN WSATRY_AGAIN is at line 99 of net_util_mh. which is included by net_util.h hence the two aforementioned values are the same. > However I think we have a problem with using gai_strerror here as the MSDN documentation says that it is not thread safe. This means we may have to look for a WSA equivalent or maybe drop the Windows part of the fix (using a mutex of some synchronization might be possible but the scope would require research and of course it wouldn't work with 3rd party native code that is also using it). Yes, I read about the thread safety. There are other ways to do this but I wanted first to air the general idea using gai_strerror() before doing any further work. > getaddrinfo could return EAI_AGAIN[1] > > But recomended way is to just check return value of getaddrinfo and then > use WSA functions especially, FormatMessage[2] instead of gai_strerror. Thanks, I did read about FormatMessage() but forewent the usage thereof for the just stated reason. > Also we may consider rewriting this code using GetAddrInfoW sometimes in > a future to support IDN. > > PS: > Brian, please notice mixing WSA and EAI at ll. 137. Agreed, that indeed should be changed as EAI_AGAIN -> WSATRY_AGAIN. Thanks, Brian From dan.xu at oracle.com Thu Oct 10 20:23:50 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 10 Oct 2013 13:23:50 -0700 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <525671CA.5080904@oracle.com> References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com> Message-ID: <52570CD6.6040602@oracle.com> Good catch, Chris. Btw, according to the description, it seems the block in #ifndef __linux__ is the workaround only for Solaris. Shall we use a more strict macro here instead of #ifndef __linux__? Thanks! -Dan On 10/10/2013 02:22 AM, Chris Hegarty wrote: > Dan, > > Your changes look fine to me. > > While looking at this I notice that there is another potential leak. > If the malloc for temp fails, then we need to free lc ( for MAC only > ), right? > > -Chris. > > On 10/09/2013 07:51 PM, Dan Xu wrote: >> Hi All, >> >> This fix is to solve the memory leak issue in ParseLocale() function of >> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, >> lc, is copied into temp, it is not necessary to do the strdup(), which >> leads to the memery leak. The fix simply removes the line of strdup >> operation. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 >> >> -Dan From brian.burkhalter at oracle.com Thu Oct 10 20:24:23 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Oct 2013 13:24:23 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> Message-ID: <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> On Oct 10, 2013, at 12:37 PM, Brian Burkhalter wrote: > Yes, I read about the thread safety. There are other ways to do this but I wanted first to air the general idea using gai_strerror() before doing any further work. > >> [?] > > Thanks, I did read about FormatMessage() but forewent the usage thereof for the just stated reason. Assuming that the general idea is correct, there are a few possible alternatives for a final version for Windows. I am not concerned in this discussion about picky details including naming which can be fine tuned at the end. 1) In net_util_mh.c/NET_ThrowUnknownHostExceptionWithGaiError replace gai_strerror() with FormatMessage(). 2) In Inet4AddressImpl.c and Inet6AddressImpl.c replace NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowByNameWithLastError (see net_md_util.c). 3) In net_md_util.c change (line 97 in http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ version) { WSATRY_AGAIN, 0, "Nonauthoritative host not found" }, to { WSATRY_AGAIN, "UnknownHostException", "Nonauthoritative host not found" }, and in Inet4AddressImpl.c and Inet6AddressImpl.c replace NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowNew(). 4) In NET_ThrowUnknownHostExceptionWithGaiError instead of using gai_strerror() use the hard-coded error message "Nonauthoritative host not found". The pros and/or cons for each, respectively, are 1) Most closely matches the Unix version and avoids hard-coded messages. 2) Simple and obviates the need for NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message has a different format from the Unix version and contains the error code instead of an error string. 3) Simple and obviates the need for NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message format is slightly different from the Unix version and the change could have the undesirable (and unpredictable) side effect of an UnknownHostException being thrown somewhere else where a SocketException used to be thrown. 4) Simplest option but has distasteful hard-coding (as do option 3 indirectly and NET_ThrowNew() for that matter). If the "con" of option 2 is acceptable then I think that would be the best way to go, otherwise option 1. Thanks, Brian From naoto.sato at oracle.com Thu Oct 10 22:14:40 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 10 Oct 2013 15:14:40 -0700 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <52570CD6.6040602@oracle.com> References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com> <52570CD6.6040602@oracle.com> Message-ID: <525726D0.9030807@oracle.com> You could, but that part only relates to the @euro locales handling, which is at this moment almost obsolete, let alone for MacOSX platform. So the current code should work fine. Naoto On 10/10/13 1:23 PM, Dan Xu wrote: > Good catch, Chris. > > Btw, according to the description, it seems the block in #ifndef > __linux__ is the workaround only for Solaris. Shall we use a more strict > macro here instead of #ifndef __linux__? Thanks! > > -Dan > > On 10/10/2013 02:22 AM, Chris Hegarty wrote: >> Dan, >> >> Your changes look fine to me. >> >> While looking at this I notice that there is another potential leak. >> If the malloc for temp fails, then we need to free lc ( for MAC only >> ), right? >> >> -Chris. >> >> On 10/09/2013 07:51 PM, Dan Xu wrote: >>> Hi All, >>> >>> This fix is to solve the memory leak issue in ParseLocale() function of >>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, >>> lc, is copied into temp, it is not necessary to do the strdup(), which >>> leads to the memery leak. The fix simply removes the line of strdup >>> operation. Thanks! >>> >>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 >>> >>> -Dan > From brian.goetz at oracle.com Thu Oct 10 22:44:49 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 10 Oct 2013 18:44:49 -0400 Subject: RFR: 8025910 : (s) rename substream(long) -> skip and substream(long, long) -> slice In-Reply-To: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> References: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> Message-ID: <52572DE1.8090008@oracle.com> For skip: should rename the parameters away from "startInclusive" to something like "toSkip". For slice: should probably change back to slice(toSkip, maxSize) rather than start/end offsets; in this way, slice is skip+limit. On 10/8/2013 11:38 PM, Mike Duigou wrote: > Hello all; > > Based upon feedback from the JavaOne Hands-On-Lab and other sources the 335 EG has decided to rename the two substream methods in the Streams interfaces to skip and slice. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/webrev/ > > and the specdiff: > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/specdiff/overview-summary.html > > Thanks, > > Mike > From eric.mccorkle at oracle.com Thu Oct 10 22:48:16 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 10 Oct 2013 18:48:16 -0400 Subject: Review request for JDK-8026011: j.l.r.MalformedParametersException introduces doclint warnings Message-ID: <52572EB0.7080903@oracle.com> Hello, Please review this simple patch that adds javadoc comments to MalformedParametersException to quiet doclint warnings. Note this patch involves no code changes. The bug report is here: https://bugs.openjdk.java.net/browse/JDK-8026011 The webrev is here: http://cr.openjdk.java.net/~emc/8026011/ Thanks, Eric From joe.darcy at oracle.com Thu Oct 10 23:00:19 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 10 Oct 2013 16:00:19 -0700 Subject: Review request for JDK-8026011: j.l.r.MalformedParametersException introduces doclint warnings In-Reply-To: <52572EB0.7080903@oracle.com> References: <52572EB0.7080903@oracle.com> Message-ID: <52573183.8060207@oracle.com> Hi Eric, Looks fine; thanks, -Joe On 10/10/2013 3:48 PM, Eric McCorkle wrote: > Hello, > > Please review this simple patch that adds javadoc comments to > MalformedParametersException to quiet doclint warnings. > > Note this patch involves no code changes. > > The bug report is here: > https://bugs.openjdk.java.net/browse/JDK-8026011 > > The webrev is here: > http://cr.openjdk.java.net/~emc/8026011/ > > Thanks, > Eric From eric.mccorkle at oracle.com Thu Oct 10 22:56:46 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 10 Oct 2013 22:56:46 +0000 Subject: hg: jdk8/tl/jdk: 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Message-ID: <20131010225701.3187A62F46@hg.openjdk.java.net> Changeset: 4abfcbac1cb6 Author: emc Date: 2013-10-10 18:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4abfcbac1cb6 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Summary: Add javadoc comments to members of MalformedParametersException Reviewed-by: darcy ! src/share/classes/java/lang/reflect/MalformedParametersException.java From john.r.rose at oracle.com Thu Oct 10 23:56:50 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Oct 2013 16:56:50 -0700 Subject: RFR: 8025910 : (s) rename substream(long) -> skip and substream(long, long) -> slice In-Reply-To: <52572DE1.8090008@oracle.com> References: <2A8358E1-247C-40DE-A587-A72AA118CECB@oracle.com> <52572DE1.8090008@oracle.com> Message-ID: On Oct 10, 2013, at 3:44 PM, Brian Goetz wrote: > maxSize "maxFoo" suggests an inclusive limit to "foo". "fooLimit" suggests an exclusive limit. For slice I suggest "sizeLimit" ("limit" with similar meaning to argument in String.split or java.io.Reader.mark). On Oct 9, 2013, at 5:45 AM, Paul Sandoz wrote: > Looks ok, but I have a preference to change the parameter name from "startInclusive" to say "n": +1, noting java.io.Reader.skip. ? John From huizhe.wang at oracle.com Fri Oct 11 00:02:04 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 10 Oct 2013 17:02:04 -0700 Subject: RFR (JAXP) : 8003262 reverse translation required changes In-Reply-To: <5E4F45FC-B347-41C4-B5E4-8DF1A3703958@oracle.com> References: <525593F4.10208@oracle.com> <5256DA28.9030407@oracle.com> <5E4F45FC-B347-41C4-B5E4-8DF1A3703958@oracle.com> Message-ID: <52573FFC.5060006@oracle.com> Thanks Lance for going through the changes! Joe On 10/10/2013 9:57 AM, Lance Andersen - Oracle wrote: > Hi Joe, > > I skimmed all of the changes and they look in line with the previous so +1 > > Best > Lance > On Oct 10, 2013, at 12:47 PM, huizhe wang wrote: > >> Hi Daniel, Lance, >> >> I've updated the webrev to include other resource bundles. The changes are the same. >> >> http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ >> >> Thanks, >> Joe >> >> >> On 10/9/2013 10:58 AM, Lance Andersen - Oracle wrote: >>> +1 >>> On Oct 9, 2013, at 1:35 PM, huizhe wang wrote: >>> >>>> Hi, >>>> >>>> These resource bundles in JAXP were refactored due to request by WPTG. Now that the WPTG tool has been approved to support the original format, I'm reverting the previous change back to the original format: >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk8/8003262/webrev/ >>>> >>>> Thanks, >>>> Joe >>> >>> 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 >>> > > > 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 Fri Oct 11 00:07:32 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Oct 2013 17:07:32 -0700 Subject: RFR: 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger In-Reply-To: <5256A792.1000305@oracle.com> References: <5256A792.1000305@oracle.com> Message-ID: <52574144.7020203@oracle.com> On 10/10/2013 6:11 AM, Daniel Fuchs wrote: > Hi, > > Please find below a patch for > 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger > https://bugs.openjdk.java.net/browse/JDK-8011638 > > > As the background, sun.util.logging.PlatformLogger is a private implementation class for the JDK classes to use to eliminate its dependency on j.u.logging and for startup performance improvement (that avoids the initialization of j.u.logging due to its reference but logging is disabled). PlatformLogger.Level was introduced JDK-8010309 and replacing the level constant types from int to PlatformLogger.enum broke JavaFX as its implementation also wants to avoid the logging initialization cost while logging any message for debugging purpose. JavaFX has now upgraded to use PlatformLogger.Level instead of primitive int type and these int constants and methods that take int level value are good to go. Daniel - the change looks good. The test case validating if there is a private static final field in PlatformLogger can simply be removed. jdk/test/tools/launcher/FXLauncherTest.java is one sanity test that can validate the jdk build with FX cobundled. Mandy From eric.mccorkle at oracle.com Fri Oct 11 00:12:41 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Fri, 11 Oct 2013 00:12:41 +0000 Subject: hg: jdk8/tl/langtools: 8008762: Type annotation on inner class in anonymous class show up as regular type annotations; ... Message-ID: <20131011001244.DCEAB62F49@hg.openjdk.java.net> Changeset: b1b4a6dcc282 Author: emc Date: 2013-10-10 20:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b1b4a6dcc282 8008762: Type annotation on inner class in anonymous class show up as regular type annotations 8015257: type annotation with TYPE_USE and FIELD attributed differently if repeated. 8013409: test failures for type annotations Summary: Fixes to address some problems in type annotations Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java + test/tools/javac/annotations/typeAnnotations/classfile/testanoninner.template ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java From jonathan.gibbons at oracle.com Fri Oct 11 00:14:53 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Oct 2013 00:14:53 +0000 Subject: hg: jdk8/tl/langtools: 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Message-ID: <20131011001456.7B35062F4A@hg.openjdk.java.net> Changeset: f068d235c4f7 Author: jjg Date: 2013-10-10 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f068d235c4f7 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Reviewed-by: darcy ! test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java From huizhe.wang at oracle.com Fri Oct 11 00:01:50 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 11 Oct 2013 00:01:50 +0000 Subject: hg: jdk8/tl/jaxp: 8003262: reverse translation required changes in xalan resource bundles Message-ID: <20131011000152.91BCF62F47@hg.openjdk.java.net> Changeset: b76629725522 Author: joehw Date: 2013-10-10 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b76629725522 8003262: reverse translation required changes in xalan resource bundles Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java From dan.xu at oracle.com Fri Oct 11 02:46:04 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 10 Oct 2013 19:46:04 -0700 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <525726D0.9030807@oracle.com> References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com> <52570CD6.6040602@oracle.com> <525726D0.9030807@oracle.com> Message-ID: <5257666C.3080104@oracle.com> Thanks for your clarification, Naoto. Here is the updated webrev, http://cr.openjdk.java.net/~dxu/8025712/webrev.01/. Please help review it. -Dan On 10/10/2013 03:14 PM, Naoto Sato wrote: > You could, but that part only relates to the @euro locales handling, > which is at this moment almost obsolete, let alone for MacOSX > platform. So the current code should work fine. > > Naoto > > On 10/10/13 1:23 PM, Dan Xu wrote: >> Good catch, Chris. >> >> Btw, according to the description, it seems the block in #ifndef >> __linux__ is the workaround only for Solaris. Shall we use a more strict >> macro here instead of #ifndef __linux__? Thanks! >> >> -Dan >> >> On 10/10/2013 02:22 AM, Chris Hegarty wrote: >>> Dan, >>> >>> Your changes look fine to me. >>> >>> While looking at this I notice that there is another potential leak. >>> If the malloc for temp fails, then we need to free lc ( for MAC only >>> ), right? >>> >>> -Chris. >>> >>> On 10/09/2013 07:51 PM, Dan Xu wrote: >>>> Hi All, >>>> >>>> This fix is to solve the memory leak issue in ParseLocale() >>>> function of >>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, >>>> lc, is copied into temp, it is not necessary to do the strdup(), which >>>> leads to the memery leak. The fix simply removes the line of strdup >>>> operation. Thanks! >>>> >>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 >>>> >>>> -Dan >> > From david.holmes at oracle.com Fri Oct 11 04:04:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 14:04:09 +1000 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> Message-ID: <525778B9.5040208@oracle.com> Ship it! :) Thanks, David On 11/10/2013 5:24 AM, Brian Burkhalter wrote: > > On Oct 10, 2013, at 11:21 AM, Brian Burkhalter wrote: > >> On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: >> >>>> Nit: In the test there are a few places where you have t on a line by itself: >>>> >>>> 65 t); >>>> >>>> but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + >>> >>> I don't see what you are referring to. >> >> Oh, sorry, now I do. Will update. > > I hope that as of now all nits have been picked. > > http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ > > Thanks, > > Brian > From lana.steuck at oracle.com Fri Oct 11 04:33:10 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:10 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20131011043340.3400362F56@hg.openjdk.java.net> Changeset: 17ee0d3e97fd Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/17ee0d3e97fd Added tag jdk8-b110 for changeset 4c84c5b447b0 ! .hgtags Changeset: 2107c9baa457 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2107c9baa457 Merge Changeset: cff4e3bf530a Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cff4e3bf530a Merge Changeset: a4622ff1462b Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a4622ff1462b Added tag jdk8-b111 for changeset 17ee0d3e97fd ! .hgtags Changeset: 46ccc5fbc523 Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/46ccc5fbc523 Merge From lana.steuck at oracle.com Fri Oct 11 04:33:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:03 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20131011043309.5879962F53@hg.openjdk.java.net> Changeset: 85c1c94e7235 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/85c1c94e7235 Added tag jdk8-b110 for changeset 3d2b7ce93c5c ! .hgtags Changeset: d7e478820c56 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d7e478820c56 Added tag jdk8-b111 for changeset 85c1c94e7235 ! .hgtags From lana.steuck at oracle.com Fri Oct 11 04:33:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:12 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131011043325.F1F5C62F54@hg.openjdk.java.net> Changeset: d49a8c2173f5 Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d49a8c2173f5 Merge Changeset: 75fd3486e584 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/75fd3486e584 Added tag jdk8-b110 for changeset d49a8c2173f5 ! .hgtags Changeset: fc2b6885e60e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fc2b6885e60e Added tag jdk8-b111 for changeset 75fd3486e584 ! .hgtags Changeset: f6263ae511c2 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f6263ae511c2 Merge From lana.steuck at oracle.com Fri Oct 11 04:33:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:00 +0000 Subject: hg: jdk8/tl: 12 new changesets Message-ID: <20131011043303.7C9E462F52@hg.openjdk.java.net> Changeset: 5ec3c4948863 Author: ksrini Date: 2013-09-27 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5ec3c4948863 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, erikj ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 72c2495c86c9 Author: katleman Date: 2013-10-01 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/72c2495c86c9 Merge Changeset: 0f704e36bc5d Author: ihse Date: 2013-10-01 10:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f704e36bc5d 8006661: Use LC_ALL=C instead of LANG=C compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 4faa09c7fe55 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4faa09c7fe55 Merge Changeset: 669e3e3d4459 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/669e3e3d4459 Added tag jdk8-b110 for changeset 4faa09c7fe55 ! .hgtags Changeset: feb4f2d97042 Author: ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/JavaCompilation.gmk Changeset: d23177734b28 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d23177734b28 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 9b102ab97693 Author: erikj Date: 2013-10-07 18:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9b102ab97693 8005924: Make it possible to set both --with-user-release-suffix and --with-build-number Reviewed-by: ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: d086227bfc45 Author: katleman Date: 2013-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d086227bfc45 Merge Changeset: 4d23143c676a Author: lana Date: 2013-10-10 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4d23143c676a Merge Changeset: 82a36c5c4eaf Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/82a36c5c4eaf Added tag jdk8-b111 for changeset d086227bfc45 ! .hgtags Changeset: fd3b32cc4b6e Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd3b32cc4b6e Merge From lana.steuck at oracle.com Fri Oct 11 04:33:07 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:07 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20131011043336.B9FD962F55@hg.openjdk.java.net> Changeset: 32edc7a2c866 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/32edc7a2c866 Added tag jdk8-b110 for changeset cc682329886b ! .hgtags Changeset: da77e343f458 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/da77e343f458 Merge Changeset: fc94ce4b899e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fc94ce4b899e Added tag jdk8-b111 for changeset 32edc7a2c866 ! .hgtags Changeset: 66a12ce67d3a Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/66a12ce67d3a Merge From lana.steuck at oracle.com Fri Oct 11 04:33:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:32 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20131011043353.0A54662F57@hg.openjdk.java.net> Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags Changeset: 8f293c710369 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f293c710369 Merge Changeset: bf33f4f81b40 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf33f4f81b40 Merge - test/tools/javac/diags/examples/DuplicateAnnotation.java From lana.steuck at oracle.com Fri Oct 11 04:34:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:34:22 +0000 Subject: hg: jdk8/tl/hotspot: 82 new changesets Message-ID: <20131011043729.093EC62F58@hg.openjdk.java.net> Changeset: 8a6a85321d3a Author: amurillo Date: 2013-09-20 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a6a85321d3a 8025127: new hotspot build - hs25-b52 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63147986a428 Author: dcubed Date: 2013-09-18 07:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63147986a428 8019835: Strings interned in different threads equal but does not == Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants. Reviewed-by: rdurbin, sspitsyn, coleenp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: dfae98867ee8 Author: dholmes Date: 2013-09-18 20:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dfae98867ee8 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps Reviewed-by: alanb, chegar, dholmes, ksrini Contributed-by: Mike Duigou ! src/share/vm/runtime/arguments.cpp Changeset: c1d7040a1183 Author: sgabdura Date: 2013-09-18 16:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1d7040a1183 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 8c84f04ff977 Author: kevinw Date: 2013-09-18 19:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c84f04ff977 Merge Changeset: 6eb908998b32 Author: kevinw Date: 2013-09-19 08:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6eb908998b32 Merge Changeset: 9ed97b511b26 Author: hseigel Date: 2013-09-19 11:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ed97b511b26 8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException Summary: Make sure CDS is off by default when running server compiler. Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CDSCompressedKPtrs/XShareAuto.java Changeset: 4f9a42c33738 Author: coleenp Date: 2013-09-20 09:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f9a42c33738 8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: dcubed, sspitsyn ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp Changeset: f201713502e0 Author: coleenp Date: 2013-09-20 09:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f201713502e0 Merge Changeset: 1b03bed31241 Author: allwin Date: 2013-09-17 17:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b03bed31241 7196151: ParserTest SEGv on solaris Reviewed-by: sla, coleenp, ctornqvi, dsamersoff ! src/share/vm/services/diagnosticArgument.cpp Changeset: e5a25e4ae509 Author: mgerdin Date: 2013-09-20 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5a25e4ae509 Merge Changeset: 7c29904fdfa2 Author: coleenp Date: 2013-09-20 18:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c29904fdfa2 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64 Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. Reviewed-by: hseigel, dcubed, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: df03413ad1a9 Author: coleenp Date: 2013-09-21 01:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df03413ad1a9 Merge Changeset: 0f37d1badced Author: dcubed Date: 2013-09-20 12:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f37d1badced Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a7609ec351d6 Author: dcubed Date: 2013-09-20 18:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7609ec351d6 Merge ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 8ddc26f62476 Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ddc26f62476 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: 1f42d3ec1759 Author: dsamersoff Date: 2013-09-22 18:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f42d3ec1759 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Summary: replace PT_LOAD segment with library segment when necessary Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ae2edb3df7fb Author: dsamersoff Date: 2013-09-22 18:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae2edb3df7fb Merge Changeset: 084b21cd0228 Author: iklam Date: 2013-09-23 08:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/084b21cd0228 8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: e8a0010ba69e Author: zgu Date: 2013-09-25 13:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8a0010ba69e Merge Changeset: 891687731b59 Author: anoll Date: 2013-09-24 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/891687731b59 7009641: Don't fail VM when CodeCache is full Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 1b64d46620a3 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b64d46620a3 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java Changeset: f637d4dc21bb Author: adlertz Date: 2013-09-26 08:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f637d4dc21bb Merge Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60a2d625db36 Merge Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3da9fad1391e Merge Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f0118ea584 Merge Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.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 Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags From masayoshi.okutsu at oracle.com Fri Oct 11 04:54:07 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 11 Oct 2013 13:54:07 +0900 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <5256ABDD.9060900@oracle.com> References: <5256ABDD.9060900@oracle.com> Message-ID: <5257846F.6020509@oracle.com> Hi Aleksej, Here are my review comments. - The copyright header of the data files shouldn't be removed. - TimeZoneNames.java: - "Middle Europe Time", "MET"}}, + "MET", "MET"}}, I don't think the long name should be changed. I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. Thanks, Masayoshi On 10/10/2013 10:30 PM, Aleksej Efimov wrote: > Hi, > > Please, review the changes [1] needed to address the tz data update in > JDK 8 from tzdata2013d to tzdata2013g. > > The brief list of changes: > 1. tzdata2013g data was integrated to tzdb data files > (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data > files (test/sun/util/calendar/zi/tzdata/* changes). > 2. a) Updates to long time zone names > b) Updates to short name changes to address corresponding changes > in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) > c) Removed unused ACT[] array > d) Added "Europe/Busingen" time zone name > All this changes a)->d) relates to > src/share/classes/sun/util/resources/TimeZoneNames*.java files > > The following tests were executed on JDK 8 with fix: > test/java/util/TimeZone > test/java/util/Calendar > test/java/util/Formatter > test/sun/util/calendar > test/java/time > > Testing result: All test passed > > Thanks! > Aleksej > > [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ > > From david.holmes at oracle.com Fri Oct 11 04:56:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 14:56:23 +1000 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> Message-ID: <525784F7.7050605@oracle.com> Karen, You can set the system property sun.reflect.inflationThreshold=N to change the magic value from 15. That makes testing easier. David On 11/10/2013 12:32 AM, Karen Kinnear wrote: > Joel, > > Thank you for the review. > > Actually, that is a very good question. > We will be adding the test case for this one to our vm side defmeth.PrivateMethodsTest, because > you have to create a classfile since private methods in interfaces are not supported by javac, they > are for internal use for Lambda support. So it was decided to not try to add them to the > java reflection tests. > > Good question - I brought this up once with Tristan and Amy who were writing reflection tests for lambda. > I will ask again about reflection coverage for invoking a method more than 15 times. > > thanks, > Karen > > On Oct 10, 2013, at 9:02 AM, Joel Borggren-Franck wrote: > >> Hi Karen, >> >> I agree with the others, the code looks good though I like Paul's >> suggestion. >> >> Silly question perhaps, do you know if we have good test coverage on >> actually reflectively invoking a Method more than 15 times? >> >> cheers >> /Joel >> >> On 2013-10-09, Karen Kinnear wrote: >>> >>> Please review: >>> >>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >>> >>> Summary: >>> Reflection generates code dynamically to speed up reflection processing after startup. The first >>> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >>> needs to use invokespecial on private methods in interfaces. >>> >>> Tested: >>> Test attached to the bug >>> >>> Also - all the 8011311 private method testing was run with this in the build: >>> Robert Field's TypeTest >>> 8025475 test >>> defmeth privatemethodstest with reflection >>> John Rose's intfbug >>> jtreg: java.util, java.lang >>> jck vm, lang >>> >>> thanks, >>> Karen >>> >>> > From david.holmes at oracle.com Fri Oct 11 04:57:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 14:57:20 +1000 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <83CA33BB-9F2D-4CC4-B6CB-21D31BBD6FCE@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <431737C3-8B89-4DEB-9594-5CFA578CA5CB@oracle.com> <83CA33BB-9F2D-4CC4-B6CB-21D31BBD6FCE@oracle.com> Message-ID: <52578530.4070207@oracle.com> On 11/10/2013 2:02 AM, Karen Kinnear wrote: > Updated webrev: >>>> webrev: http://cr.openjdk.java.net/~acorn/8026213.2/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 Still looks okay to me. David > > Testing: > Specific test for private methods (attached to bug) > jtreg jdk java.lang, sun.reflect > > thanks, > Karen > > p.s. this should look very much like Paul's suggestion - thank you again > > On Oct 10, 2013, at 9:47 AM, Karen Kinnear wrote: > >> Paul, >> >> Thank you so much for the review and suggestion. I will rewrite this this way and resend. >> >> thanks! >> Karen >> >> On Oct 10, 2013, at 5:13 AM, Paul Sandoz wrote: >> >>> >>> On Oct 10, 2013, at 12:13 AM, Karen Kinnear wrote: >>> >>>> >>>> Please review: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >>>> >>>> Summary: >>>> Reflection generates code dynamically to speed up reflection processing after startup. The first >>>> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >>>> needs to use invokespecial on private methods in interfaces. >>>> >>> >>> You don't need to pass modifiers as a parameter to emitInvoke since it is set as a field on AccessorGenerator and used, e.g. see isStatic(). >>> >>> So perhaps add the following method to AccessorGenerator: >>> >>> protected boolean isPrivate() { >>> return Modifier.isPrivate(modifiers); >>> } >>> >>> and do: >>> >>> 642 if (isInterface()) { >>> >>> 643 if (isPrivate()) { >>> 644 cb.opc_invokespecial(targetMethodRef, count, 0); >>> 645 } else { >>> >>> 646 cb.opc_invokeinterface(targetMethodRef, >>> 647 count, >>> 648 count, >>> 649 typeSizeInStackSlots(returnType)); >>> >>> 650 } >>> >>> 651 } else { >>> 652 cb.opc_invokevirtual(targetMethodRef, >>> 653 count, >>> 654 typeSizeInStackSlots(returnType)); >>> 655 } >>> 656 } >>> 657 } >>> >>> ? >>> >>> Paul. >>> >>>> Tested: >>>> Test attached to the bug >>>> >>>> Also - all the 8011311 private method testing was run with this in the build: >>>> Robert Field's TypeTest >>>> 8025475 test >>>> defmeth privatemethodstest with reflection >>>> John Rose's intfbug >>>> jtreg: java.util, java.lang >>>> jck vm, lang >>>> >>>> thanks, >>>> Karen >>>> >>>> >>> >> > From robert.field at oracle.com Fri Oct 11 06:27:37 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 11 Oct 2013 06:27:37 +0000 Subject: hg: jdk8/tl/langtools: 8012557: Implement lambda methods on interfaces as private; ... Message-ID: <20131011062740.CD92362F5F@hg.openjdk.java.net> Changeset: 1ce8405af5fe Author: rfield Date: 2013-10-10 23:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ce8405af5fe 8012557: Implement lambda methods on interfaces as private 8016320: Method reference in subinterface of type I.super::foo produces exception at runtime Summary: Now that the VM supports interface instance private methods, lambda methods and lambda bridges are always private. Access is now through invokespecial. Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/8012557/A.java + test/tools/javac/lambda/8012557/B.java + test/tools/javac/lambda/8012557/C.java + test/tools/javac/lambda/8012557/PrivateLambdas.java + test/tools/javac/lambda/8012557/SAM.java + test/tools/javac/lambda/8016320/IllegalBridgeModifier.java From lana.steuck at oracle.com Fri Oct 11 04:36:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:36:19 +0000 Subject: hg: jdk8/tl/jdk: 96 new changesets Message-ID: <20131011045629.B3ECD62F5A@hg.openjdk.java.net> Changeset: 529cd4de1823 Author: prr Date: 2013-09-26 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/529cd4de1823 7092764: java.awt.font.TransformAttribute.equals(null) throws NPE Reviewed-by: jgodinez, jchen ! src/share/classes/java/awt/font/TransformAttribute.java + test/java/awt/font/TransformAttribute/TransformEqualityTest.java Changeset: 1bcd48cfb7be Author: ceisserer Date: 2013-09-26 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1bcd48cfb7be 8024895: xrender MaskImage cache isn't accounting for change in alpha Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java + test/java/awt/image/DrawImage/EABlitTest.java Changeset: dae020405903 Author: lana Date: 2013-09-26 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dae020405903 Merge Changeset: 0151f12bd392 Author: malenkov Date: 2013-08-22 17:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0151f12bd392 8023536: Some regression tests have a wrong header Reviewed-by: alexsch ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/javax/swing/JTree/8013571/Test8013571.java Changeset: b71f112dab2a Author: malenkov Date: 2013-08-22 21:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b71f112dab2a 7057769: JScrollBar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/javax/swing/JScrollBar.java Changeset: f983fd18dd81 Author: malenkov Date: 2013-08-23 19:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f983fd18dd81 7080613: java.beans.DefaultPersistenceDelegate.instantiate(..) doesn't throw NPE Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 22ef5187a3e6 Author: dmarkov Date: 2013-08-26 17:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22ef5187a3e6 8023474: First mousepress doesn't start editing in JTree Reviewed-by: alexp, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java Changeset: abd068530590 Author: malenkov Date: 2013-08-27 12:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abd068530590 7195179: ClassCastException for null values in JComboBox Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/7195179/Test7195179.java Changeset: 92adff44c841 Author: malenkov Date: 2013-08-27 13:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92adff44c841 8021379: JFileChooser Create New Folder button enabled in write proteced directory Reviewed-by: alexsch ! src/share/classes/sun/swing/FilePane.java Changeset: 4bfcf9c5ced3 Author: malenkov Date: 2013-08-27 13:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bfcf9c5ced3 8022398: javax/swing/JFileChooser/8013442/Test8013442.java fails Reviewed-by: alexsch ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: e11ed7187b0c Author: lana Date: 2013-08-27 21:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e11ed7187b0c Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 43de418f1345 Author: ptbrunet Date: 2013-08-28 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43de418f1345 8011955: Lunar screen reader crashes intermittently in WindowsAccessBridge-32.DLL 6995891: JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue 8014738: Combobox menu items are not announced with JAWS 8011938: Java Ferret example corrupts JCombobox of the running application 8012011: JAB 2.0.2 incompletely shows kbd accelerator in menus 8022966: Java Access Bridge no longer usable with screen magnifiers Reviewed-by: raginip, tbell, erikj, art ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcMisc.gmk Changeset: 35644adc3269 Author: malenkov Date: 2013-08-28 17:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35644adc3269 6968363: ClassCastException while entering HINDI characters with CustomDocument Reviewed-by: alexsch ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/AbstractDocument/6968363/Test6968363.java Changeset: 6432f8749e1d Author: pchelko Date: 2013-08-30 11:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6432f8749e1d 8023966: JViewPort.BLIT_SCROLL_MODE does not work in JLightweightFrame Reviewed-by: anthony, ant ! src/share/classes/javax/swing/JViewport.java Changeset: 7151f08eeadf Author: alexsch Date: 2013-08-30 13:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7151f08eeadf 8022401: [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java Changeset: f2f614e31522 Author: malenkov Date: 2013-09-02 14:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2f614e31522 7156658: JTextComponent.setFocusAccelerator() spec does not state that focus accelerator is L&F dependent Reviewed-by: alexsch ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 6ffa2680e139 Author: art Date: 2013-09-02 16:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ffa2680e139 8022184: Fix static , Raw warnings in classes belonging to java.awt Reviewed-by: art, anthony Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/WaitDispatchSupport.java Changeset: b5ed8686cc01 Author: malenkov Date: 2013-09-03 11:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5ed8686cc01 6943780: JTabbedPane throws ArrayIndexOutOfBoundsException sometimes Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/plaf/basic/BasicTabbedPaneUI/Test6943780.java Changeset: 80a8c4ff3b51 Author: alexsch Date: 2013-09-03 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80a8c4ff3b51 8007156: [macosx] Wrong events in processKeyBinding of JTable Submit Date Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java Changeset: 2ad01ecbaf90 Author: malenkov Date: 2013-09-03 21:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ad01ecbaf90 7172865: PropertyDescriptor fails to work with setter method name if setter is non-void Reviewed-by: art, alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java + src/share/classes/java/beans/MethodRef.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7172865.java Changeset: ba711056009f Author: pchelko Date: 2013-09-04 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba711056009f 8021943: FileDialog getFile returns corrupted string after previous setFile Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: ba041df8a554 Author: mcherkas Date: 2013-09-04 18:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba041df8a554 8023565: JPG causes javax.imageio.IIOException: ICC APP2 encoutered without prior JFIF Reviewed-by: bae, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java Changeset: e4ba3d9ea041 Author: mcherkas Date: 2013-09-05 15:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ba3d9ea041 8023392: Swing text components printed with spaces between chars Reviewed-by: alexsch, alexp Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java + test/java/awt/print/bug8023392/bug8023392.html + test/java/awt/print/bug8023392/bug8023392.java Changeset: d267c066b006 Author: lana Date: 2013-09-06 15:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d267c066b006 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: fbb6f976d780 Author: alexsch Date: 2013-09-09 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbb6f976d780 8024413: Add tests for issues JDK-8002077 and JDK-7199708 Reviewed-by: malenkov, leonidr + test/javax/swing/JFileChooser/7199708/bug7199708.java + test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 3ea08767fc0d Author: alexsch Date: 2013-09-09 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ea08767fc0d 8020060: MoleculeViewerTest demo doesn't work due to SecurityPermissions Reviewed-by: malenkov, erikj ! makefiles/CompileDemos.gmk ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: fc5d16fec25f Author: serb Date: 2013-09-09 21:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc5d16fec25f 8023042: Inaccuracy in documentation in a sound area Reviewed-by: prr ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java Changeset: 9d0d961fb1cd Author: pchelko Date: 2013-09-10 11:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d0d961fb1cd 8024381: The test for 8020210 does not have @bug tag Reviewed-by: anthony, serb ! test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: 8b6dace81d6c Author: alexsch Date: 2013-09-10 14:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b6dace81d6c 8021253: JFileChooser does not react on pressing enter since java 7 Reviewed-by: malenkov ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8021253/bug8021253.java Changeset: 1daffcf035c4 Author: malenkov Date: 2013-09-10 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1daffcf035c4 7057770: (spec)Scrollbar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/java/awt/Scrollbar.java Changeset: eedb2b6d93ec Author: malenkov Date: 2013-09-10 17:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eedb2b6d93ec 8024407: [macosx] javax/swing/JScrollBar/7163696/Test7163696.java failed intermittently on macos Reviewed-by: alexsch ! test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: 0cc00c11e17e Author: leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 04fbd34fda7b Author: bagiras Date: 2013-09-12 14:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04fbd34fda7b 8003965: Toolkit.beep() documentation is ambiguous Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: def1fa9854f7 Author: bagiras Date: 2013-09-12 15:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def1fa9854f7 7064312: Cleanup: avoid using unsafe string function Reviewed-by: serb, pchelko ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_ole.cpp Changeset: 6321e4429a38 Author: serb Date: 2013-09-12 18:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6321e4429a38 7124537: [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 3213c388740a Author: dmarkov Date: 2013-09-12 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3213c388740a 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: ef2f0c15b332 Author: pchelko Date: 2013-09-13 11:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef2f0c15b332 8024170: [SwingNode] Implement cursor change Reviewed-by: anthony, ant ! src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java Changeset: 12788c245d67 Author: pchelko Date: 2013-09-13 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12788c245d67 8015453: java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java failed on windows with jdk8 since b86 Reviewed-by: art, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: df107b1f2f2e Author: pchelko Date: 2013-09-13 17:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df107b1f2f2e 8015371: The HTML text without tags does not appear inside the WordPad application, and we try to click the button, but the case exits. Reviewed-by: anthony, serb ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 40fdf56c09a9 Author: pchelko Date: 2013-09-13 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40fdf56c09a9 8015455: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java hangs on windows Reviewed-by: serb, anthony ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/javax/swing/TransferHandler.java Changeset: 915d13946f18 Author: mcherkas Date: 2013-09-13 17:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/915d13946f18 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: ad52e924c55a Author: kshefov Date: 2013-09-13 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad52e924c55a 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: alexsch, serb ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: c8a85165b725 Author: kshefov Date: 2013-09-13 17:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8a85165b725 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 17cc8f13e4e7 Author: pchelko Date: 2013-09-13 18:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17cc8f13e4e7 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS Reviewed-by: anthony, serb ! make/sun/lwawt/FILES_export_macosx.gmk - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: a46d22ee4d4b Author: alexsch Date: 2013-09-16 17:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a46d22ee4d4b 8008728: [macosx] Swing. JDialog. Modal dialog goes to background Reviewed-by: serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java Changeset: 8f5b4e7623cf Author: ant Date: 2013-09-16 18:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f5b4e7623cf 8022512: JLightweightFrame: the content pane should be transparent Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 49c7d299a504 Author: kshefov Date: 2013-09-16 19:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49c7d299a504 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: 98080e9367be Author: kshefov Date: 2013-09-16 19:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98080e9367be 8015588: [TEST_BUG] [macosx] Test java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java fails on MacOSX Reviewed-by: anthony, serb ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 04612a52e7bd Author: pchelko Date: 2013-09-16 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04612a52e7bd 8024779: [macosx] SwingNode crashes on exit Reviewed-by: anthony, ant ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 4e88bf592830 Author: pchelko Date: 2013-09-16 19:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e88bf592830 8024485: For 5-1 step: if input something into the 'File:' and 'Dir:', the dir output isn't empty in the output window after showing and canceling the file dialog Reviewed-by: serb, anthony ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 8530456e0091 Author: omajid Date: 2013-09-16 15:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8530456e0091 8024863: X11: Support GNOME Shell as mutter Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWM.java Changeset: 4899f6734a14 Author: ant Date: 2013-09-18 12:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4899f6734a14 8024839: [Unified Swing/Fx threading] don't schedule an event dispatching from the event dispatch thread Reviewed-by: anthony, pchelko ! src/share/classes/java/awt/EventQueue.java Changeset: cc7a15f4c735 Author: mcherkas Date: 2013-09-18 15:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc7a15f4c735 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: 2c240454c192 Author: leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 20b1135647fa Author: lana Date: 2013-09-18 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20b1135647fa Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/windows/native/sun/windows/awt_PrintControl.cpp - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: e292d504ad68 Author: leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potochkin at oracle.com ! src/macosx/classes/sun/lwawt/LWChoicePeer.java Changeset: 602e5d0141d3 Author: leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: c04e55e17066 Author: kshefov Date: 2013-09-20 17:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c04e55e17066 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 6c1f9468f3de Author: kshefov Date: 2013-09-20 17:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c1f9468f3de 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: f139aef966fd Author: kshefov Date: 2013-09-20 17:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f139aef966fd 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: abebe03818f6 Author: malenkov Date: 2013-09-20 18:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abebe03818f6 7024235: Nimbus L&F: wrong "packing" of a frame containing tabbed pane Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7024235/Test7024235.java Changeset: 2ac59698de38 Author: kshefov Date: 2013-09-23 16:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ac59698de38 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: eac52fe3990c Author: serb Date: 2013-09-23 16:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eac52fe3990c 8005255: [macosx] Cleanup warnings in sun.lwawt Reviewed-by: alexsch, anthony ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java - src/macosx/classes/sun/lwawt/SelectionClearListener.java Changeset: 2684fd4e9f3b Author: serb Date: 2013-09-23 17:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2684fd4e9f3b 7172833: For default java.awt.Toolkit impl methods java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: alexsch, anthony ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: d73d3a29065c Author: serb Date: 2013-09-23 21:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d73d3a29065c 8019282: keyRelesed is reached even though key was NOT released Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! make/sun/xawt/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 8c0b943a0090 Author: yan Date: 2013-09-24 12:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c0b943a0090 8025114: Eliminate doclint errors in java.awt.dnd package javadoc Reviewed-by: serb, alexsch ! 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 Changeset: 1303823e89da Author: yan Date: 2013-09-24 16:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1303823e89da 8025230: [cleanup] some more javadoc formatting fixes for swing Reviewed-by: alexsch ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.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/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/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.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/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java Changeset: d580e0bc85d9 Author: yan Date: 2013-09-24 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d580e0bc85d9 8025117: [cleanup] Eliminate doclint errors in javax/swing/text classes Reviewed-by: alexsch ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.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/DefaultEditorKit.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/FieldView.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/NavigationFilter.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/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/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.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/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 58178aec7e81 Author: kshefov Date: 2013-09-24 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58178aec7e81 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: f500844c2253 Author: kshefov Date: 2013-09-24 17:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f500844c2253 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 967557d5b90a Author: kshefov Date: 2013-09-24 18:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/967557d5b90a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 3982dd1210ba Author: kshefov Date: 2013-09-24 18:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3982dd1210ba 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 2ed1584d62c5 Author: leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java Changeset: a284da808700 Author: malenkov Date: 2013-09-25 14:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a284da808700 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: art, sfriberg ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 10e66428ddb0 Author: alexsch Date: 2013-09-25 16:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10e66428ddb0 8007155: [macosx] Disabled panel takes mouse input in JLayeredPane Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/windows/classes/sun/awt/windows/WGlobalCursorManager.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h ! src/windows/native/sun/windows/awt_Cursor.cpp + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.html + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.java Changeset: 7cad8ef127a9 Author: pchelko Date: 2013-09-25 16:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cad8ef127a9 8024987: Copy/paste regression since JDK8 b86 Reviewed-by: serb, anthony ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: cff4f079fa3f Author: kshefov Date: 2013-09-25 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cff4f079fa3f 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 681ac9f9c452 Author: alexsch Date: 2013-09-25 17:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/681ac9f9c452 8025070: [javadoc] fix some javadoc errors in javax/swing/plaf/synth Reviewed-by: serb, alexsch Contributed-by: Alexander Stepanov ! 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/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/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/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 Changeset: 2f8803ebd98c Author: yan Date: 2013-09-25 17:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f8803ebd98c 8025085: [javadoc] some errors in javax/swing Reviewed-by: alexsch Contributed-by: Dmitry Zinkevich ! 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/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.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/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/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/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/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.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/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.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/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/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.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/synth/Region.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.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/StyleSheet.java ! 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/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.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/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: c40ed21f2939 Author: alexsch Date: 2013-09-25 17:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c40ed21f2939 7083457: Incomplete specification for javax/swing/text/DefaultCaret.html#setVisible(boolean) Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/7083457/bug7083457.java Changeset: 09fb25645717 Author: ptbrunet Date: 2013-09-26 10:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09fb25645717 8025160: Recent Java Accessibility Bridge push has make failures Reviewed-by: tbell, erikj ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 0270e9b0891b Author: yan Date: 2013-09-26 16:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0270e9b0891b 8025218: [javadoc] some errors in java/awt classes Reviewed-by: yan Contributed-by: Dmitry Zinkevich ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/Component.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/Frame.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/KeyboardFocusManager.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/event/MouseMotionListener.java Changeset: 3b22833f2695 Author: lana Date: 2013-09-26 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b22833f2695 Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/719befd87c7b Merge Changeset: a1d91e198ddf Author: lana Date: 2013-10-10 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1d91e198ddf Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/sun/security/tools/keytool/autotest.sh Changeset: 1863a7e3a1c9 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1863a7e3a1c9 Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags Changeset: 1a067bc31098 Author: lana Date: 2013-10-10 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a067bc31098 Merge From mandy.chung at oracle.com Fri Oct 11 07:08:18 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Oct 2013 00:08:18 -0700 Subject: Review request for jdeps option rename to Java-style and enhancements to output dot file format Message-ID: <5257A3E2.6050305@oracle.com> There were some discussion of jdeps CLI to follow GNU style option or the traditional Java style. As there will be plans to upgrade the JDK tools to GNU style options, it'd be desirable to keep jdeps be consistent with other langtools and be upgraded to GNU style in a unified manner. This patch includes the fixes for: JDK-8015912: jdeps output in dot graph format and option to find API dependences JDK-8026255: Switch jdeps to follow traditional Java option style Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ It includes 3 new options in addition to the option renaming: 1) -dotoutput

Destination directory for DOT file output (Note that this is different than the patch I post a few months ago). If specified, the dependencies will be output in dot graph format in the given directory. It will generate a summary file named "summary.dot" to list the dependencies among the archives (.class file, directory, or JAR file specified in the command line). For each archive, there will also be a dot file listing the package-level or class-level dependencies named ".dot" The output will be like: digraph "archive name" { "from" -> "to"; } where from and to can be a package name, class name or the filename being processed depending on the verbose mode. 2) Restrict analysis on public APIs only -apionly Restrict analysis to APIs i.e. dependences from the signature of public and protected members of public classes including field type, method parameter types, returned type, checked exception types etc 3) -include to restrict the analysis to classes matching the given regular expression This option filters the list of classes to be analyzed. It can be used together with -p and -e which apply the pattern to the dependences. --------------- Usage: jdeps where can be a pathname to a .class file, a directory, a JAR file, or a fully-qualified class name. Possible options include: -dotoutput Destination directory for DOT file output -s -summary Print dependency summary only -v -verbose Print all class level dependencies -verbose:package Print package-level dependencies excluding dependencies within the same archive -verbose:class Print class-level dependencies excluding dependencies within the same archive -cp -classpath Specify where to find class files -p -package Finds dependences in the given package (may be given multiple times) -e -regex Finds dependences in packages matching pattern (-p and -e are exclusive) -include Restrict analysis to classes matching pattern This option filters the list of classes to be analyzed. It can be used together with -p and -e which apply pattern to the dependences -P -profile Show profile or the file containing a package -apionly Restrict analysis to APIs i.e. dependences from the signature of public and protected members of public classes including field type, method parameter types, returned type, checked exception types etc -recursive Recursively traverse all dependencies -version Version information From peter.levart at gmail.com Fri Oct 11 08:14:53 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Oct 2013 10:14:53 +0200 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <525784F7.7050605@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> <525784F7.7050605@oracle.com> Message-ID: <5257B37D.7080906@gmail.com> On 10/11/2013 06:56 AM, David Holmes wrote: > Karen, > > You can set the system property sun.reflect.inflationThreshold=N to > change the magic value from 15. That makes testing easier. Or, alternatively, you can set sun.reflect.noInflation=true, which generates code straight away, so that even 1st invocation goes throught the generated accessor. Contrasting this with sun.reflect.inflationThreshold=0 where accessor is generated on 1st invocation, but 1st invocation still goes via native accessor. Regards, Peter > > David > > On 11/10/2013 12:32 AM, Karen Kinnear wrote: >> Joel, >> >> Thank you for the review. >> >> Actually, that is a very good question. >> We will be adding the test case for this one to our vm side >> defmeth.PrivateMethodsTest, because >> you have to create a classfile since private methods in interfaces >> are not supported by javac, they >> are for internal use for Lambda support. So it was decided to not try >> to add them to the >> java reflection tests. >> >> Good question - I brought this up once with Tristan and Amy who were >> writing reflection tests for lambda. >> I will ask again about reflection coverage for invoking a method more >> than 15 times. >> >> thanks, >> Karen >> >> On Oct 10, 2013, at 9:02 AM, Joel Borggren-Franck wrote: >> >>> Hi Karen, >>> >>> I agree with the others, the code looks good though I like Paul's >>> suggestion. >>> >>> Silly question perhaps, do you know if we have good test coverage on >>> actually reflectively invoking a Method more than 15 times? >>> >>> cheers >>> /Joel >>> >>> On 2013-10-09, Karen Kinnear wrote: >>>> >>>> Please review: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >>>> >>>> Summary: >>>> Reflection generates code dynamically to speed up reflection >>>> processing after startup. The first >>>> 15 runs of a reflection call use the vm code path, after that we >>>> use the generated code path, which >>>> needs to use invokespecial on private methods in interfaces. >>>> >>>> Tested: >>>> Test attached to the bug >>>> >>>> Also - all the 8011311 private method testing was run with this in >>>> the build: >>>> Robert Field's TypeTest >>>> 8025475 test >>>> defmeth privatemethodstest with reflection >>>> John Rose's intfbug >>>> jtreg: java.util, java.lang >>>> jck vm, lang >>>> >>>> thanks, >>>> Karen >>>> >>>> >> From sundararajan.athijegannathan at oracle.com Fri Oct 11 08:20:24 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 08:20:24 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20131011082034.ECA2662F63@hg.openjdk.java.net> Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/34f7a699cdef 8026162: "this" in SAM adapter functions is wrong Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java + test/script/basic/JDK-8026162.js Changeset: ed3da7a574a0 Author: lagergren Date: 2013-10-10 16:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ed3da7a574a0 8026250: Logging nullpointer bugfix and javadoc warnings Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java Changeset: a781ea074521 Author: sundar Date: 2013-10-10 21:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a781ea074521 8026264: Getter, setter function name mangling issues Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8026264.js Changeset: 375c2f2d41c8 Author: sundar Date: 2013-10-11 06:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/375c2f2d41c8 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Reviewed-by: jlaskey ! test/script/basic/JDK-8025488.js Changeset: 56be5161f0d2 Author: sundar Date: 2013-10-11 09:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/56be5161f0d2 Merge From paul.sandoz at oracle.com Fri Oct 11 08:44:31 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Oct 2013 10:44:31 +0200 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <83CA33BB-9F2D-4CC4-B6CB-21D31BBD6FCE@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <431737C3-8B89-4DEB-9594-5CFA578CA5CB@oracle.com> <83CA33BB-9F2D-4CC4-B6CB-21D31BBD6FCE@oracle.com> Message-ID: <2A53B413-4543-4B54-BF13-0AB9804B7AA7@oracle.com> On Oct 10, 2013, at 6:02 PM, Karen Kinnear wrote: > Updated webrev: >>>> webrev: http://cr.openjdk.java.net/~acorn/8026213.2/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 > > +1 Paul. > Testing: > Specific test for private methods (attached to bug) > jtreg jdk java.lang, sun.reflect > > thanks, > Karen > > p.s. this should look very much like Paul's suggestion - thank you again From daniel.fuchs at oracle.com Fri Oct 11 09:32:47 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Oct 2013 11:32:47 +0200 Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles In-Reply-To: <524ED45A.9080105@oracle.com> References: <523C4097.10200@oracle.com> <52449684.2080609@oracle.com> <524D8398.4000005@oracle.com> <524D8E0A.30404@oracle.com> <524D93BB.20501@oracle.com> <524DC583.8060104@oracle.com> <524ED45A.9080105@oracle.com> Message-ID: <5257C5BF.2020005@oracle.com> On 10/4/13 4:44 PM, Daniel Fuchs wrote: > Hi Mandy, > > On 10/3/13 9:29 PM, Mandy Chung wrote: >> >> test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >> >> >> 109 return new Vector(java.util.Arrays.asList( >> 110 new String[] {"dummy"})).elements(); >> >> Could you use Collections.enumeration? > > Excellent! Yes I will. > >> test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java >> >> 194 if (foobaz.getResourceBundleName() != null) { >> 195 throw new RuntimeException("Unexpected bundle: " >> 196 + foobar.getResourceBundle()); >> 197 } >> >> I guess you meant to print foobar.getResourceBundleName() in line 196. > > Oops - yes - thanks for catching that. > >> The test cases are good. It'd be good to add some comments to >> describe what each case verifies when appropriate. >> >> You can make these changes before you push. No need for a new webrev. Thanks Mandy! For the record, here is the new webrev, with your comments included. I also clarified the fact that ResourceBundle.getBaseBundleName() will return null if the base name is not known. best regards, -- daniel > > OK - thanks > > -- daniel > >> >> thanks >> Mandy >> > From aleksej.efimov at oracle.com Fri Oct 11 09:37:20 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 11 Oct 2013 13:37:20 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <5257846F.6020509@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> Message-ID: <5257C6D0.9060404@oracle.com> Hi Masayoshi, Thank you for your comments. Replies are below. On 10/11/2013 08:54 AM, Masayoshi Okutsu wrote: > Hi Aleksej, > > Here are my review comments. > > - The copyright header of the data files shouldn't be removed. The copyright header is absent in raw tzdata2013g release (in tzdata2013g.tar.gz). I didn't do any modification to it. > > - TimeZoneNames.java: > - "Middle Europe Time", "MET"}}, > + "MET", "MET"}}, > I don't think the long name should be changed. Agree, will change it back. > > I didn't review the localized TimeZoneNames_*.java files. If L10N Team > is OK with them, I'm fine. > > Thanks, > Masayoshi > > On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >> Hi, >> >> Please, review the changes [1] needed to address the tz data update >> in JDK 8 from tzdata2013d to tzdata2013g. >> >> The brief list of changes: >> 1. tzdata2013g data was integrated to tzdb data files >> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test >> data files (test/sun/util/calendar/zi/tzdata/* changes). >> 2. a) Updates to long time zone names >> b) Updates to short name changes to address corresponding changes >> in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >> c) Removed unused ACT[] array >> d) Added "Europe/Busingen" time zone name >> All this changes a)->d) relates to >> src/share/classes/sun/util/resources/TimeZoneNames*.java files >> >> The following tests were executed on JDK 8 with fix: >> test/java/util/TimeZone >> test/java/util/Calendar >> test/java/util/Formatter >> test/sun/util/calendar >> test/java/time >> >> Testing result: All test passed >> >> Thanks! >> Aleksej >> >> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >> >> > From chris.hegarty at oracle.com Fri Oct 11 09:44:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Oct 2013 10:44:09 +0100 Subject: RFR: 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger In-Reply-To: <5256A792.1000305@oracle.com> References: <5256A792.1000305@oracle.com> Message-ID: <5257C869.5090907@oracle.com> Looks good to me Daniel. -Chris. On 10/10/2013 14:11, Daniel Fuchs wrote: > Hi, > > Please find below a patch for > 8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger > https://bugs.openjdk.java.net/browse/JDK-8011638 > > > > best regards, > > -- daniel From chris.hegarty at oracle.com Fri Oct 11 10:48:06 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Oct 2013 11:48:06 +0100 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <5257666C.3080104@oracle.com> References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com> <52570CD6.6040602@oracle.com> <525726D0.9030807@oracle.com> <5257666C.3080104@oracle.com> Message-ID: <5257D766.30408@oracle.com> Thanks Dan, looks good to me. -Chris. On 11/10/2013 03:46, Dan Xu wrote: > Thanks for your clarification, Naoto. > > Here is the updated webrev, > http://cr.openjdk.java.net/~dxu/8025712/webrev.01/. Please help review it. > > -Dan > > On 10/10/2013 03:14 PM, Naoto Sato wrote: >> You could, but that part only relates to the @euro locales handling, >> which is at this moment almost obsolete, let alone for MacOSX >> platform. So the current code should work fine. >> >> Naoto >> >> On 10/10/13 1:23 PM, Dan Xu wrote: >>> Good catch, Chris. >>> >>> Btw, according to the description, it seems the block in #ifndef >>> __linux__ is the workaround only for Solaris. Shall we use a more strict >>> macro here instead of #ifndef __linux__? Thanks! >>> >>> -Dan >>> >>> On 10/10/2013 02:22 AM, Chris Hegarty wrote: >>>> Dan, >>>> >>>> Your changes look fine to me. >>>> >>>> While looking at this I notice that there is another potential leak. >>>> If the malloc for temp fails, then we need to free lc ( for MAC only >>>> ), right? >>>> >>>> -Chris. >>>> >>>> On 10/09/2013 07:51 PM, Dan Xu wrote: >>>>> Hi All, >>>>> >>>>> This fix is to solve the memory leak issue in ParseLocale() >>>>> function of >>>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, >>>>> lc, is copied into temp, it is not necessary to do the strdup(), which >>>>> leads to the memery leak. The fix simply removes the line of strdup >>>>> operation. Thanks! >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 >>>>> >>>>> -Dan >>> >> > From karen.kinnear at oracle.com Fri Oct 11 12:06:28 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 11 Oct 2013 08:06:28 -0400 Subject: RFR: Lambda 8026213: Reflection support for private methods in interfaces In-Reply-To: <525784F7.7050605@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> <525784F7.7050605@oracle.com> Message-ID: <34EDD366-B93B-435C-B96E-BBC2A1F62C3B@oracle.com> Thank you David - that will be helpful. And thanks for the re-review. thanks, Karen On Oct 11, 2013, at 12:56 AM, David Holmes wrote: > Karen, > > You can set the system property sun.reflect.inflationThreshold=N to change the magic value from 15. That makes testing easier. > > David > > On 11/10/2013 12:32 AM, Karen Kinnear wrote: >> Joel, >> >> Thank you for the review. >> >> Actually, that is a very good question. >> We will be adding the test case for this one to our vm side defmeth.PrivateMethodsTest, because >> you have to create a classfile since private methods in interfaces are not supported by javac, they >> are for internal use for Lambda support. So it was decided to not try to add them to the >> java reflection tests. >> >> Good question - I brought this up once with Tristan and Amy who were writing reflection tests for lambda. >> I will ask again about reflection coverage for invoking a method more than 15 times. >> >> thanks, >> Karen >> >> On Oct 10, 2013, at 9:02 AM, Joel Borggren-Franck wrote: >> >>> Hi Karen, >>> >>> I agree with the others, the code looks good though I like Paul's >>> suggestion. >>> >>> Silly question perhaps, do you know if we have good test coverage on >>> actually reflectively invoking a Method more than 15 times? >>> >>> cheers >>> /Joel >>> >>> On 2013-10-09, Karen Kinnear wrote: >>>> >>>> Please review: >>>> >>>> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >>>> >>>> Summary: >>>> Reflection generates code dynamically to speed up reflection processing after startup. The first >>>> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >>>> needs to use invokespecial on private methods in interfaces. >>>> >>>> Tested: >>>> Test attached to the bug >>>> >>>> Also - all the 8011311 private method testing was run with this in the build: >>>> Robert Field's TypeTest >>>> 8025475 test >>>> defmeth privatemethodstest with reflection >>>> John Rose's intfbug >>>> jtreg: java.util, java.lang >>>> jck vm, lang >>>> >>>> thanks, >>>> Karen >>>> >>>> >> From joel.franck at oracle.com Fri Oct 11 12:26:25 2013 From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=) Date: Fri, 11 Oct 2013 14:26:25 +0200 Subject: RFR: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays In-Reply-To: <5256B208.1060406@oracle.com> References: <20131010124622.GS1969@jfranck-desktop.jrpg.bea.com> <5088349C-ED02-433F-81E4-16413DF991EF@oracle.com> <5256B208.1060406@oracle.com> Message-ID: <20131011122625.GW1969@jfranck-desktop.jrpg.bea.com> Thanks for the reviews, fix has been pushed. cheers /Joel On 2013-10-10, Joe Darcy wrote: > Looks fine; thanks, > > -Joe > > On 10/10/2013 5:56 AM, Paul Sandoz wrote: > >On Oct 10, 2013, at 2:46 PM, Joel Borggren-Franck wrote: > > > >>Hi, > >> > >>Joe, Paul, agreed the test could be better. Improved it (without using > >>streams) and also added a bug id tag to the old Arrays.newInstance test. > >> > >>Thanks for the comments. > >> > >>Webrev here: http://cr.openjdk.java.net/~jfranck/7044282/webrev.01/ > >> > >Looks OK. > > > >Paul. > From sundararajan.athijegannathan at oracle.com Fri Oct 11 12:28:37 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 12:28:37 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131011122842.3823862F6C@hg.openjdk.java.net> Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1c154cee43d9 8026292: Megamorphic setter fails with boolean value Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8026292.js Changeset: fb091f9052a6 Author: sundar Date: 2013-10-11 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fb091f9052a6 8026302: source representation of getter and setter methods is wrong Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8026302.js + test/script/basic/JDK-8026302.js.EXPECTED ! test/script/basic/objects.js.EXPECTED Changeset: 062579f50371 Author: sundar Date: 2013-10-11 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/062579f50371 8026317: $ in the function name results in wrong function being invoked Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/Namespace.java + test/script/basic/JDK-8026317.js + test/script/basic/JDK-8026317.js.EXPECTED Changeset: b35d175207f6 Author: sundar Date: 2013-10-11 14:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b35d175207f6 Merge From aleksej.efimov at oracle.com Fri Oct 11 13:46:58 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 11 Oct 2013 17:46:58 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <5257C6D0.9060404@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <5257C6D0.9060404@oracle.com> Message-ID: <52580152.90801@oracle.com> Hi Masayoshi, The new webrev with addressed review comments: http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.01/ The list of changes: 1. "Middle Europe Time" remained untouched. 2. The copyright headers were added. Best Regards, Aleksej On 10/11/2013 01:37 PM, Aleksej Efimov wrote: > Hi Masayoshi, > Thank you for your comments. Replies are below. > > On 10/11/2013 08:54 AM, Masayoshi Okutsu wrote: >> Hi Aleksej, >> >> Here are my review comments. >> >> - The copyright header of the data files shouldn't be removed. > The copyright header is absent in raw tzdata2013g release (in > tzdata2013g.tar.gz). I didn't do any modification to it. >> >> - TimeZoneNames.java: >> - "Middle Europe Time", "MET"}}, >> + "MET", "MET"}}, >> I don't think the long name should be changed. > > Agree, will change it back. > >> >> I didn't review the localized TimeZoneNames_*.java files. If L10N >> Team is OK with them, I'm fine. >> >> Thanks, >> Masayoshi >> >> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>> Hi, >>> >>> Please, review the changes [1] needed to address the tz data update >>> in JDK 8 from tzdata2013d to tzdata2013g. >>> >>> The brief list of changes: >>> 1. tzdata2013g data was integrated to tzdb data files >>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test >>> data files (test/sun/util/calendar/zi/tzdata/* changes). >>> 2. a) Updates to long time zone names >>> b) Updates to short name changes to address corresponding >>> changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>> c) Removed unused ACT[] array >>> d) Added "Europe/Busingen" time zone name >>> All this changes a)->d) relates to >>> src/share/classes/sun/util/resources/TimeZoneNames*.java files >>> >>> The following tests were executed on JDK 8 with fix: >>> test/java/util/TimeZone >>> test/java/util/Calendar >>> test/java/util/Formatter >>> test/sun/util/calendar >>> test/java/time >>> >>> Testing result: All test passed >>> >>> Thanks! >>> Aleksej >>> >>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >>> >>> >> > From sean.mullan at oracle.com Fri Oct 11 13:45:57 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 11 Oct 2013 13:45:57 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131011134659.CE0C062F6F@hg.openjdk.java.net> Changeset: 4ad76262bac8 Author: mullan Date: 2013-10-11 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad76262bac8 8007292: Add JavaFX internal packages to package.access Summary: build hooks to allow closed restricted packages to be added to java.security file Reviewed-by: erikj, dholmes, tbell ! make/java/security/Makefile ! make/tools/Makefile + make/tools/addtorestrictedpkgs/Makefile + make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java ! makefiles/CopyFiles.gmk ! makefiles/Tools.gmk ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 76df579c0b93 Author: mullan Date: 2013-10-11 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76df579c0b93 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java From jan.lahoda at oracle.com Fri Oct 11 13:59:32 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Oct 2013 13:59:32 +0000 Subject: hg: jdk8/tl/langtools: 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Message-ID: <20131011135935.3C31862F73@hg.openjdk.java.net> Changeset: 872c4a898b38 Author: jlahoda Date: 2013-10-11 15:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/872c4a898b38 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Reviewed-by: darcy, jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.out From aleksej.efimov at oracle.com Fri Oct 11 14:06:10 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 11 Oct 2013 18:06:10 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Message-ID: <525805D2.2040003@oracle.com> Hi, I need help in reviewing the fix for this one bug: 8008733. It was firstly observed in JDK 6 and already fixed there. The problem and the fix [1] looks trivial: There is a performance regression in XPathContext class constructor and it's caused by double initialization of 'm_dtmManager' field: one in the variable initializer and another in the XPathContext constructor. The fix is to remove the variable initializer. I don't think we need a regression test for it, but we need to make sure the regression is gone. In attempt to prove it, I have done two simple hprof run [2] on a test app [3] that creates 100000 instances of XPathContext in a cycle. And I've got the following results: 1. Without fix: The call count to 'com.sun.org.apache.xml.internal.dtm.DTMManager.newInstance' is 200000. The average execution time was 20400 ms. 2. With fix: Call count = 100000. The average execution time = 15200 ms. According to this data the performance regression is gone. Thanks, -Aleksej [1] http://cr.openjdk.java.net/~aefimov/8008733/webrev.00/ [2] Without fix: http://cr.openjdk.java.net/~aefimov/8008733/hprof_nofix.txt With fix: http://cr.openjdk.java.net/~aefimov/8008733/hprof_withfix.txt [3] http://cr.openjdk.java.net/~aefimov/8008733/XPathContextPerformance.java From aleksey.shipilev at oracle.com Fri Oct 11 14:30:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Oct 2013 18:30:27 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <525805D2.2040003@oracle.com> References: <525805D2.2040003@oracle.com> Message-ID: <52580B83.9050104@oracle.com> On 10/11/2013 06:06 PM, Aleksej Efimov wrote: > I don't think we need a regression test for it, but we need to make sure > the regression is gone. In attempt to prove it, I have done two simple > hprof run [2] on a test app [3] that creates 100000 instances of > XPathContext in a cycle. While I agree with the fix, profiling is the no-go way to confirm the performance regression and the fix, especially with the broken test you have in [3]. You need to build targeted benchmarks, see e.g. jmh: http://openjdk.java.net/projects/code-tools/jmh/ > [1] http://cr.openjdk.java.net/~aefimov/8008733/webrev.00/ Looks good. What a mess is that code anyway! > [3] > http://cr.openjdk.java.net/~aefimov/8008733/XPathContextPerformance.java -Aleksey. From andrey.x.nazarov at oracle.com Fri Oct 11 14:56:19 2013 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 11 Oct 2013 18:56:19 +0400 Subject: Review: demos for jdk8 In-Reply-To: <52326F0F.9010707@oracle.com> References: <52326F0F.9010707@oracle.com> Message-ID: <52581193.3020606@oracle.com> Hi guys, Did you have a chance to review our jdk8 demos? http://cr.openjdk.java.net/~anazarov/try-with-resources/ http://cr.openjdk.java.net/~anazarov/repeating-annotations/ http://cr.openjdk.java.net/~anazarov/jdk8-demo-bulkoperations/ http://cr.openjdk.java.net/~anazarov/extension-methods/ -- Andrey. On 13.09.2013 5:49, Andrey Nazarov wrote: > I've fixed subject > --- > Hi guys, > > We want to push our demo code for try-with-resources feature > Could you please review this code? > http://cr.openjdk.java.net/~anazarov/try-with-resources/ > > > --Andrey. > From pbenedict at apache.org Fri Oct 11 15:04:07 2013 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 11 Oct 2013 10:04:07 -0500 Subject: Review: demos for jdk8 In-Reply-To: <52581193.3020606@oracle.com> References: <52326F0F.9010707@oracle.com> <52581193.3020606@oracle.com> Message-ID: I think there may be a problem with Console::close(). Even though the Console instance will be disposed in a try-with-resources construct, that doesn't the reader and writer are guaranteed to close together. Currently, if the reader fails to close, the writer will be left dangling. What do you think of putting a try/catch in close() (and maybe suppressing one of them)? On Fri, Oct 11, 2013 at 9:56 AM, Andrey Nazarov wrote: > Hi guys, > > Did you have a chance to review our jdk8 demos? > > http://cr.openjdk.java.net/~anazarov/try-with-resources/ > http://cr.openjdk.java.net/~anazarov/repeating-annotations/ > http://cr.openjdk.java.net/~anazarov/jdk8-demo-bulkoperations/ > http://cr.openjdk.java.net/~anazarov/extension-methods/ > > > -- Andrey. > > On 13.09.2013 5:49, Andrey Nazarov wrote: > > I've fixed subject > > --- > > Hi guys, > > > > We want to push our demo code for try-with-resources feature > > Could you please review this code? > > http://cr.openjdk.java.net/~anazarov/try-with-resources/ > > > > > > --Andrey. > > > > > -- Cheers, Paul From brian.burkhalter at oracle.com Fri Oct 11 15:15:06 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Oct 2013 08:15:06 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <525778B9.5040208@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> Message-ID: <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> Thanks. Any further comments from anyone else? Brian On Oct 10, 2013, at 9:04 PM, David Holmes wrote: > Ship it! :) > > Thanks, > David > > On 11/10/2013 5:24 AM, Brian Burkhalter wrote: >> >> On Oct 10, 2013, at 11:21 AM, Brian Burkhalter wrote: >> >>> On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: >>> >>>>> Nit: In the test there are a few places where you have t on a line by itself: >>>>> >>>>> 65 t); >>>>> >>>>> but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + >>>> >>>> I don't see what you are referring to. >>> >>> Oh, sorry, now I do. Will update. >> >> I hope that as of now all nits have been picked. >> >> http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ >> >> Thanks, >> >> Brian >> From chris.hegarty at oracle.com Fri Oct 11 15:31:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Oct 2013 16:31:28 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <525778B9.5040208@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> Message-ID: <525819D0.4060302@oracle.com> On 11/10/2013 05:04, David Holmes wrote: > Ship it! :) +1 -Chris. > > Thanks, > David > > On 11/10/2013 5:24 AM, Brian Burkhalter wrote: >> >> On Oct 10, 2013, at 11:21 AM, Brian Burkhalter wrote: >> >>> On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: >>> >>>>> Nit: In the test there are a few places where you have t on a line >>>>> by itself: >>>>> >>>>> 65 t); >>>>> >>>>> but it can go on the previous line and not exceed the length of >>>>> other lines nearby. Also "+ should be " + >>>> >>>> I don't see what you are referring to. >>> >>> Oh, sorry, now I do. Will update. >> >> I hope that as of now all nits have been picked. >> >> http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ >> >> Thanks, >> >> Brian >> From michael.x.mcmahon at oracle.com Fri Oct 11 15:31:36 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 11 Oct 2013 16:31:36 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> Message-ID: <525819D8.4000400@oracle.com> Looks fine to me. Michael On 11/10/13 16:15, Brian Burkhalter wrote: > Thanks. > > Any further comments from anyone else? > > Brian > > On Oct 10, 2013, at 9:04 PM, David Holmes wrote: > >> Ship it! :) >> >> Thanks, >> David >> >> On 11/10/2013 5:24 AM, Brian Burkhalter wrote: >>> On Oct 10, 2013, at 11:21 AM, Brian Burkhalter wrote: >>> >>>> On Oct 10, 2013, at 11:05 AM, Brian Burkhalter wrote: >>>> >>>>>> Nit: In the test there are a few places where you have t on a line by itself: >>>>>> >>>>>> 65 t); >>>>>> >>>>>> but it can go on the previous line and not exceed the length of other lines nearby. Also "+ should be " + >>>>> I don't see what you are referring to. >>>> Oh, sorry, now I do. Will update. >>> I hope that as of now all nits have been picked. >>> >>> http://cr.openjdk.java.net/~bpb/7179567/webrev.5/ >>> >>> Thanks, >>> >>> Brian >>> From Alan.Bateman at oracle.com Fri Oct 11 15:42:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Oct 2013 16:42:29 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> Message-ID: <52581C65.9070309@oracle.com> On 11/10/2013 16:15, Brian Burkhalter wrote: > Thanks. > > Any further comments from anyone else? > > Brian > I'm happy to see getPermissions changed to just specify long standing behavior (the original proposal was unlikely to break anyone but it was surprising). So I think what you have is fine now. -Alan. From brian.burkhalter at oracle.com Fri Oct 11 15:45:46 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Oct 2013 08:45:46 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <52581C65.9070309@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <9DFFEEBD-1BF6-468D-A952-FB81DADEFD8A@oracle.com> <52581C65.9070309@oracle.com> Message-ID: <45C4F230-45B9-44BC-B721-BAF700D5FACC@oracle.com> On Oct 11, 2013, at 8:42 AM, Alan Bateman wrote: > On 11/10/2013 16:15, Brian Burkhalter wrote: >> Thanks. >> >> Any further comments from anyone else? >> >> Brian >> > I'm happy to see getPermissions changed to just specify long standing behavior (the original proposal was unlikely to break anyone but it was surprising). So I think what you have is fine now. Great! Thanks everyone for the comments. I'll file the CCC request today. Brian From dan.xu at oracle.com Fri Oct 11 16:48:01 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 11 Oct 2013 16:48:01 +0000 Subject: hg: jdk8/tl/jdk: 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Message-ID: <20131011164853.6499F62F86@hg.openjdk.java.net> Changeset: cb373cf43294 Author: dxu Date: 2013-10-11 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb373cf43294 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Reviewed-by: naoto, chegar ! src/solaris/native/java/lang/java_props_md.c From michael.fang at oracle.com Fri Oct 11 17:41:38 2013 From: michael.fang at oracle.com (Michael Fang) Date: Fri, 11 Oct 2013 10:41:38 -0700 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <5257846F.6020509@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> Message-ID: <52583852.3010004@oracle.com> Hi Aleksej, I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... I think we can file a separate bug to track that issue. thanks, -michael On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: > Hi Aleksej, > > Here are my review comments. > > - The copyright header of the data files shouldn't be removed. > > - TimeZoneNames.java: > > - "Middle Europe Time", "MET"}}, > + "MET", "MET"}}, > > I don't think the long name should be changed. > > I didn't review the localized TimeZoneNames_*.java files. If L10N Team > is OK with them, I'm fine. > > Thanks, > Masayoshi > > On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >> Hi, >> >> Please, review the changes [1] needed to address the tz data update >> in JDK 8 from tzdata2013d to tzdata2013g. >> >> The brief list of changes: >> 1. tzdata2013g data was integrated to tzdb data files >> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test >> data files (test/sun/util/calendar/zi/tzdata/* changes). >> 2. a) Updates to long time zone names >> b) Updates to short name changes to address corresponding changes in >> tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >> c) Removed unused ACT[] array >> d) Added "Europe/Busingen" time zone name >> All this changes a)->d) relates to >> src/share/classes/sun/util/resources/TimeZoneNames*.java files >> >> The following tests were executed on JDK 8 with fix: >> test/java/util/TimeZone >> test/java/util/Calendar >> test/java/util/Formatter >> test/sun/util/calendar >> test/java/time >> >> Testing result: All test passed >> >> Thanks! >> Aleksej >> >> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >> >> > From naoto.sato at oracle.com Fri Oct 11 18:06:14 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 11 Oct 2013 11:06:14 -0700 Subject: RFR: JDK-8025712, , (props) Possible memory leak in java_props_md.c / ParseLocale In-Reply-To: <5257666C.3080104@oracle.com> References: <5255A597.9030007@oracle.com> <525671CA.5080904@oracle.com> <52570CD6.6040602@oracle.com> <525726D0.9030807@oracle.com> <5257666C.3080104@oracle.com> Message-ID: <52583E16.7030100@oracle.com> Looks good. Thank you for fixing this. Naoto On 10/10/13 7:46 PM, Dan Xu wrote: > Thanks for your clarification, Naoto. > > Here is the updated webrev, > http://cr.openjdk.java.net/~dxu/8025712/webrev.01/. Please help review it. > > -Dan > > On 10/10/2013 03:14 PM, Naoto Sato wrote: >> You could, but that part only relates to the @euro locales handling, >> which is at this moment almost obsolete, let alone for MacOSX >> platform. So the current code should work fine. >> >> Naoto >> >> On 10/10/13 1:23 PM, Dan Xu wrote: >>> Good catch, Chris. >>> >>> Btw, according to the description, it seems the block in #ifndef >>> __linux__ is the workaround only for Solaris. Shall we use a more strict >>> macro here instead of #ifndef __linux__? Thanks! >>> >>> -Dan >>> >>> On 10/10/2013 02:22 AM, Chris Hegarty wrote: >>>> Dan, >>>> >>>> Your changes look fine to me. >>>> >>>> While looking at this I notice that there is another potential leak. >>>> If the malloc for temp fails, then we need to free lc ( for MAC only >>>> ), right? >>>> >>>> -Chris. >>>> >>>> On 10/09/2013 07:51 PM, Dan Xu wrote: >>>>> Hi All, >>>>> >>>>> This fix is to solve the memory leak issue in ParseLocale() >>>>> function of >>>>> jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale, >>>>> lc, is copied into temp, it is not necessary to do the strdup(), which >>>>> leads to the memery leak. The fix simply removes the line of strdup >>>>> operation. Thanks! >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~dxu/8025712/webrev/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025712 >>>>> >>>>> -Dan >>> >> > From brian.burkhalter at oracle.com Fri Oct 11 19:17:19 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Oct 2013 12:17:19 -0700 Subject: Label for JDK 8 issue affecting JCK? In-Reply-To: <52584E69.8000005@oracle.com> References: <52584E69.8000005@oracle.com> Message-ID: <1C9A7B1E-3404-49F9-A7CF-216B96E071E5@oracle.com> On Oct 11, 2013, at 12:15 PM, Alan Bateman wrote: > Is there a CCC for this? Literally typing in that request now. > If so then JCK will create a bug in the JCK project (you don't have to do it). OK - thanks. Brian From aleksej.efimov at oracle.com Fri Oct 11 19:20:41 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 11 Oct 2013 23:20:41 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <52583852.3010004@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> Message-ID: <52584F89.3030007@oracle.com> Hi Michael, As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? Thanks and Best Regards, Aleksej On 11.10.2013 21:41, Michael Fang wrote: > Hi Aleksej, > > I took a look at the localized TimeZoneNames_*.java files. They do not > contain generic time zone names for JSR310... > > I think we can file a separate bug to track that issue. > > thanks, > > -michael > > On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >> Hi Aleksej, >> >> Here are my review comments. >> >> - The copyright header of the data files shouldn't be removed. >> >> - TimeZoneNames.java: >> >> - "Middle Europe Time", "MET"}}, >> + "MET", "MET"}}, >> >> I don't think the long name should be changed. >> >> I didn't review the localized TimeZoneNames_*.java files. If L10N >> Team is OK with them, I'm fine. >> >> Thanks, >> Masayoshi >> >> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>> Hi, >>> >>> Please, review the changes [1] needed to address the tz data update >>> in JDK 8 from tzdata2013d to tzdata2013g. >>> >>> The brief list of changes: >>> 1. tzdata2013g data was integrated to tzdb data files >>> (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test >>> data files (test/sun/util/calendar/zi/tzdata/* changes). >>> 2. a) Updates to long time zone names >>> b) Updates to short name changes to address corresponding changes in >>> tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>> c) Removed unused ACT[] array >>> d) Added "Europe/Busingen" time zone name >>> All this changes a)->d) relates to >>> src/share/classes/sun/util/resources/TimeZoneNames*.java files >>> >>> The following tests were executed on JDK 8 with fix: >>> test/java/util/TimeZone >>> test/java/util/Calendar >>> test/java/util/Formatter >>> test/sun/util/calendar >>> test/java/time >>> >>> Testing result: All test passed >>> >>> Thanks! >>> Aleksej >>> >>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >>> >>> >> > From brian.burkhalter at oracle.com Fri Oct 11 19:40:26 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 11 Oct 2013 12:40:26 -0700 Subject: Label for JDK 8 issue affecting JCK? In-Reply-To: <1C9A7B1E-3404-49F9-A7CF-216B96E071E5@oracle.com> References: <52584E69.8000005@oracle.com> <1C9A7B1E-3404-49F9-A7CF-216B96E071E5@oracle.com> Message-ID: <3E6D7F30-F63A-4F18-8159-3D37EB7F17F9@oracle.com> Wrong mailing list - please ignore. On Oct 11, 2013, at 12:17 PM, Brian Burkhalter wrote: > On Oct 11, 2013, at 12:15 PM, Alan Bateman wrote: > >> Is there a CCC for this? > > Literally typing in that request now. > >> If so then JCK will create a bug in the JCK project (you don't have to do it). > > OK - thanks. > > Brian From ivan.gerasimov at oracle.com Fri Oct 11 19:45:36 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Oct 2013 23:45:36 +0400 Subject: RFR [8024521] (process) Async close issues with Process InputStream Message-ID: <52585560.6080904@oracle.com> Hello all! Would you please help review a fix? http://bugs.sun.com/view_bug.do?bug_id=8024521 As of JDK 1.7, ProcessPipeInputStream tries to drain the InputStream when the process exits. However, it is racing with application code that could be closing the inputstream at the same time. This can lead to processExited() operating on the wrong underlying file. The test included into the webrev demonstrates exactly that: Due to the race, the draining thread can suddenly start to read a huge file which will cause OutOfMemoryException. Here's the webrev with a simple fix, which synchronizes close() and processExited(): http://cr.openjdk.java.net/~igerasim/8024521/0/webrev/ It's important to note that this simple fix isn't complete. It only protects from the race when the file descriptor is closed by a call to Process#getInputStream().close(). The file descriptor can still be asynchronously closed in some other way, for example by calling to the native close() function. Sincerely yours, Ivan Gerasimov From mike.duigou at oracle.com Fri Oct 11 19:46:55 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Oct 2013 12:46:55 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> Message-ID: On Oct 10 2013, at 06:37 , Paul Sandoz wrote: > Hi Mike, > > This looks like a good direction. Need to look more closely. > > I wonder if we even require such detailed support to throw CME? Some additional CME will be thrown indirectly by iteration. This applies to forEach/replaceAll. Virtually all the cases where CME is thrown in the "new" Map defaults are the points where previously the implementation would have looped/retried. > For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. Understood. The alternative would be to GIGO these situations, return and ignore them. > For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". Modification of any other entry may have the same result. I suspect that modification by some other thread is as likely to be a problem as modification by the function. Any thoughts Doug? Is this advancing or retreating from the right direction? Mike > > Paul. > > On Oct 10, 2013, at 5:46 AM, Mike Duigou wrote: > >> >> On Oct 8 2013, at 01:27 , Paul Sandoz wrote: >> >>> Hi Mike, >>> >>> I am probably going over old ground here... >>> >>> Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry, or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. >>> >>> Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? >> >> I have created a prototype renovated Map and ConcurrentMap to provide (mostly) separate implementations. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024688.2/0/webrev/ >> >> This passes all of the existing regression tests and I believe is performance neutral. The implementations are now more relatively correct for both flavours. ie. Map defaults don't retry and throw CME when they detect that something changed unexpectedly. The ConcurrentMap defaults were mostly just moving over the prior Map defaults but I also removed a few cases of null value handling that were no longer needed. >> >> I've wanted to explore this for a while (since June) but haven't previously had a chance. I'm somewhat convinced that this is the right direction to be going but I am sure further refinement is possible (particularly in regards to the spec). >> >>> The defaults on Map could state they are not suitable for maps that can be concurrently modified, if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) >>> >>> I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? >> >> I realized that some of the statements about "implementations must document how they handle nulls with this method" were no longer relevant. The null handling behaviour was entirely covered by the class documentation and the method specification. This is mostly a consequence of having added "or is mapped to null value" in couple of cases later on in the process. >> >> Thanks for pushing on this point (and David Holmes for earlier suggestion that this might be important) >> >> Mike >> >>> Paul. >>> >>> On Oct 4, 2013, at 5:35 AM, Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. >>>> >>>> The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ >>>> >>>> Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. >>>> >>>> Mike >>> >> > From Alan.Bateman at oracle.com Fri Oct 11 19:57:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Oct 2013 20:57:10 +0100 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <52580B83.9050104@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> Message-ID: <52585816.2090907@oracle.com> On 11/10/2013 15:30, Aleksey Shipilev wrote: > : > While I agree with the fix, profiling is the no-go way to confirm the > performance regression and the fix, especially with the broken test you > have in [3]. You need to build targeted benchmarks, see e.g. jmh: > http://openjdk.java.net/projects/code-tools/jmh/ > >> [1] http://cr.openjdk.java.net/~aefimov/8008733/webrev.00/ > Looks good. What a mess is that code anyway! I don't know this code but I see that m_dtmManager is initialized in the init method (invoked by the constructor). Also there doesn't seem to be serializable involved. So the change looks okay. Do you have a sponsor to help you get this in? Also will the benchmarks or tests to verify the performance be going anywhere (this might be a question for Aleksey as ideally we should be building up a suite a good micro benchmarks as we fix or improve things). -Alan. From alan.bateman at oracle.com Fri Oct 11 19:59:42 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Oct 2013 19:59:42 +0000 Subject: hg: jdk8/tl/jdk: 8019526: (fs) Files.lines, etc without Charset parameter Message-ID: <20131011195954.DFDAC62FA3@hg.openjdk.java.net> Changeset: 9632de07d963 Author: alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9632de07d963 8019526: (fs) Files.lines, etc without Charset parameter Reviewed-by: psandoz, henryjen ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java ! test/java/nio/file/Files/StreamTest.java From michael.fang at oracle.com Fri Oct 11 20:43:08 2013 From: michael.fang at oracle.com (Michael Fang) Date: Fri, 11 Oct 2013 13:43:08 -0700 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <52584F89.3030007@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> Message-ID: Hi Aleksej, Yes, you are right. They can be handled separately. Thanks! Regards, Michael Sent from my iPhone On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: > Hi Michael, > As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. > But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? > > Thanks and Best Regards, > Aleksej > > On 11.10.2013 21:41, Michael Fang wrote: >> Hi Aleksej, >> >> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >> >> I think we can file a separate bug to track that issue. >> >> thanks, >> >> -michael >> >> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>> Hi Aleksej, >>> >>> Here are my review comments. >>> >>> - The copyright header of the data files shouldn't be removed. >>> >>> - TimeZoneNames.java: >>> >>> - "Middle Europe Time", "MET"}}, >>> + "MET", "MET"}}, >>> >>> I don't think the long name should be changed. >>> >>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>> >>> Thanks, >>> Masayoshi >>> >>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>> >>>> The brief list of changes: >>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>> 2. a) Updates to long time zone names >>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>> c) Removed unused ACT[] array >>>> d) Added "Europe/Busingen" time zone name >>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>> >>>> The following tests were executed on JDK 8 with fix: >>>> test/java/util/TimeZone >>>> test/java/util/Calendar >>>> test/java/util/Formatter >>>> test/sun/util/calendar >>>> test/java/time >>>> >>>> Testing result: All test passed >>>> >>>> Thanks! >>>> Aleksej >>>> >>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ > From aleksey.shipilev at oracle.com Fri Oct 11 20:47:19 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Oct 2013 00:47:19 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <52585816.2090907@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> <52585816.2090907@oracle.com> Message-ID: <525863D7.1000908@oracle.com> On 10/11/2013 11:57 PM, Alan Bateman wrote: > (this might be a question for Aleksey as ideally we should be > building up a suite a good micro benchmarks as we fix or improve > things). Working on it separately for some time now. It would help to have the benchmark for particular issue anyway. -Aleksey. From vincent.x.ryan at oracle.com Fri Oct 11 19:47:42 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 11 Oct 2013 19:47:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131011194840.ADE9462FA1@hg.openjdk.java.net> Changeset: d23247aa7462 Author: vinnie Date: 2013-10-11 20:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d23247aa7462 8026301: DomainKeyStore doesn't cleanup correctly when storing to keystore Reviewed-by: mullan ! src/share/classes/sun/security/provider/DomainKeyStore.java Changeset: 94493b5800bb Author: vinnie Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94493b5800bb Merge From robert.field at oracle.com Fri Oct 11 22:22:03 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 11 Oct 2013 22:22:03 +0000 Subject: hg: jdk8/tl/jdk: 8026213: Reflection support for private interface methods Message-ID: <20131011222240.638D362FAB@hg.openjdk.java.net> Changeset: 4561460bf570 Author: rfield Date: 2013-10-11 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4561460bf570 8026213: Reflection support for private interface methods Reviewed-by: forax, psandoz, dholmes, jfranck Contributed-by: karen.kinnear at oracle.com ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java + test/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java From mike.duigou at oracle.com Fri Oct 11 22:31:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 11 Oct 2013 22:31:33 +0000 Subject: hg: jdk8/tl: 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Message-ID: <20131011223133.8194662FAC@hg.openjdk.java.net> Changeset: 3f9873789d44 Author: mduigou Date: 2013-10-11 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3f9873789d44 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Reviewed-by: mduigou Contributed-by: Dmitry Samersoff ! common/bin/hgforest.sh From david.r.chase at oracle.com Sat Oct 12 05:14:48 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 12 Oct 2013 01:14:48 -0400 Subject: RFR: 8022718 : Runtime accessibility checking: protected class, if extended, should be accessible from another package In-Reply-To: <73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com> References: <97248223-77FF-48FA-A0ED-978268962952@oracle.com> <73BAFD52-A7D5-4DF9-996F-9FC5041E7B43@oracle.com> Message-ID: <37F24081-8D9E-4A8A-8AFA-05ACDA544230@oracle.com> Further revised after consulting with John Rose on details of fix: webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.02/ tests: jtreg of jdk/lambda java/lang/invoke java/util/stream defmeth (a/b testing) jprt in progress (assuming I got the incantation right) David From aleksej.efimov at oracle.com Sun Oct 13 10:00:58 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sun, 13 Oct 2013 14:00:58 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <525863D7.1000908@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> <52585816.2090907@oracle.com> <525863D7.1000908@oracle.com> Message-ID: <525A6F5A.9080506@oracle.com> Aleksey, Thank you for your comments and JMH reference. I have created a benchmark to measure an average time of XPathContext object creation. The benchmark code: @GenerateMicroBenchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) public void testMethod(BlackHole bh) { bh.consume( new XPathContext() ); } Benchmark results: Without proposed fix: 9,496 us/op With proposed fix: 8,570 us/op Alan, No, I don't have sponsor and I'll be very appreciate if you'll sponsor this commit. The changeset is located here: h ttp://cr.openjdk.java.net/~aefimov/8008733/8008733_hg.export . But I suppose, we will need another one formal review from a JDK8 reviewer. Thank you, Aleksej On 10/12/2013 12:47 AM, Aleksey Shipilev wrote: > On 10/11/2013 11:57 PM, Alan Bateman wrote: >> (this might be a question for Aleksey as ideally we should be >> building up a suite a good micro benchmarks as we fix or improve >> things). > Working on it separately for some time now. > It would help to have the benchmark for particular issue anyway. > > -Aleksey. From aleksej.efimov at oracle.com Sun Oct 13 10:23:47 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sun, 13 Oct 2013 14:23:47 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> Message-ID: <525A74B3.6040300@oracle.com> Michael, Masayoshi, Looks like, we can commit this changes with following items in mind: 1. Generic names in TimeZoneNames_*.java should be added as part of JDK-8025051 resolution. 2. I need another one approval from a JDK 8 reviewer for this one. Anyway, the hg changeset patch can be found here: http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch Best Regards, Aleksej On 10/12/2013 12:43 AM, Michael Fang wrote: > Hi Aleksej, > > Yes, you are right. They can be handled separately. Thanks! > > Regards, > > Michael > Sent from my iPhone > > On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: > >> Hi Michael, >> As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. >> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? >> >> Thanks and Best Regards, >> Aleksej >> >> On 11.10.2013 21:41, Michael Fang wrote: >>> Hi Aleksej, >>> >>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >>> >>> I think we can file a separate bug to track that issue. >>> >>> thanks, >>> >>> -michael >>> >>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>>> Hi Aleksej, >>>> >>>> Here are my review comments. >>>> >>>> - The copyright header of the data files shouldn't be removed. >>>> >>>> - TimeZoneNames.java: >>>> >>>> - "Middle Europe Time", "MET"}}, >>>> + "MET", "MET"}}, >>>> >>>> I don't think the long name should be changed. >>>> >>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>>> Hi, >>>>> >>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>>> >>>>> The brief list of changes: >>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>>> 2. a) Updates to long time zone names >>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>>> c) Removed unused ACT[] array >>>>> d) Added "Europe/Busingen" time zone name >>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>>> >>>>> The following tests were executed on JDK 8 with fix: >>>>> test/java/util/TimeZone >>>>> test/java/util/Calendar >>>>> test/java/util/Formatter >>>>> test/sun/util/calendar >>>>> test/java/time >>>>> >>>>> Testing result: All test passed >>>>> >>>>> Thanks! >>>>> Aleksej >>>>> >>>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ From aleksey.shipilev at oracle.com Sun Oct 13 15:12:07 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sun, 13 Oct 2013 19:12:07 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <525A6F5A.9080506@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> <52585816.2090907@oracle.com> <525863D7.1000908@oracle.com> <525A6F5A.9080506@oracle.com> Message-ID: <525AB847.6020008@oracle.com> Hi Aleksej, On 10/13/2013 02:00 PM, Aleksej Efimov wrote: > The benchmark code: > @GenerateMicroBenchmark > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.MICROSECONDS) > public void testMethod(BlackHole bh) { > bh.consume( new XPathContext() ); > } Not bad. The syntactic nit: you can "just" return the value and JMH will feed it to the blackhole implicitly: @GenerateMicroBenchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) public XPathContext testMethod() { return new XPathContext(); } > Benchmark results: > Without proposed fix: 9,496 us/op > With proposed fix: 8,570 us/op Whoa, 8.5 us to create the XPathContext seems a lot. If the change in performance for 8.5 -> 9.5 us/op was reported as performance regression, I wonder if we should optimize XPathContext further. (Not in the scope of this change of course). -Aleksey. From Alan.Bateman at oracle.com Sun Oct 13 20:31:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Oct 2013 21:31:08 +0100 Subject: Review request for jdeps option rename to Java-style and enhancements to output dot file format In-Reply-To: <5257A3E2.6050305@oracle.com> References: <5257A3E2.6050305@oracle.com> Message-ID: <525B030C.6000704@oracle.com> On 11/10/2013 08:08, Mandy Chung wrote: > There were some discussion of jdeps CLI to follow GNU style option > or the traditional Java style. As there will be plans to upgrade > the JDK tools to GNU style options, it'd be desirable to keep jdeps > be consistent with other langtools and be upgraded to GNU style in > a unified manner. > > This patch includes the fixes for: > JDK-8015912: jdeps output in dot graph format and option to find API > dependences > JDK-8026255: Switch jdeps to follow traditional Java option style > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ Command line options are somewhat subjective, I think what you have is reasonable. I thought the GNU style that were in the original version were okay too (just takes getting used to) but keeping them consistent with similarly named options in the other tools is important tool. One change that I didn't quite understand is dropping -R for recursive, that one seemed intuitive (to me). Anyway, on the changes then I went through the webrev and I didn't see anything obviously wrong. A few comments: - In PlatformClassPath then alt-rt is special-cased and I think that can be removed now. - Also in PlatformClassPath is special handling of jfxrt.jar (if it is present) isn't clear. I recall this came up before and maybe it just needs a more detailed comment to explain why it is needed. - In Analyzer then I think I missed why the results are a LinkedHashMap, wouldn't HashMap do? - A minor comment in JdepsTask but I assume the OutputWriter interface can be private -Alan From Alan.Bateman at oracle.com Sun Oct 13 20:33:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Oct 2013 21:33:47 +0100 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <525A6F5A.9080506@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> <52585816.2090907@oracle.com> <525863D7.1000908@oracle.com> <525A6F5A.9080506@oracle.com> Message-ID: <525B03AB.3020307@oracle.com> On 13/10/2013 11:00, Aleksej Efimov wrote: > : > > Alan, > No, I don't have sponsor and I'll be very appreciate if you'll sponsor > this commit. The changeset is located here: h > ttp://cr.openjdk.java.net/~aefimov/8008733/8008733_hg.export > . But > I suppose, we will need another one formal review from a JDK8 reviewer. > Okay, I will push it for you on Monday. For the change-set then Aleksey can also be listed on the Reviewed-by line (it's okay to list non-Reviewers once you have at least one Reviewer). -Alan From xuelei.fan at oracle.com Mon Oct 14 04:12:08 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 Oct 2013 04:12:08 +0000 Subject: hg: jdk8/tl/jdk: 8026119: Regression test DHEKeySizing.java failing intermittently Message-ID: <20131014041308.02D8E62FFD@hg.openjdk.java.net> Changeset: fb202a8e83c9 Author: xuelei Date: 2013-10-13 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb202a8e83c9 8026119: Regression test DHEKeySizing.java failing intermittently Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java From Alan.Bateman at oracle.com Mon Oct 14 08:08:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Oct 2013 09:08:12 +0100 Subject: Demo for Parallel Core Collection API In-Reply-To: References: Message-ID: <525BA66C.4060907@oracle.com> On 14/10/2013 04:27, Tristan Yan wrote: > Hi all > > > > Could you please help to review the demo code for parallel core collection API? > > http://cr.openjdk.java.net/~pzhang/Tristan/8023555/webrev/ > A drive-by comment/question (I have not studied the code in the webrev) but are you planning to include a README or something to explain the demo? At the moment it's just a code in a directory and it's not clear where someone should start, at least I don't see an IDE project or other inviting file. I would also suggest getting advice on the appropriate copyright header to use. At the moment you have GPL but I thought that the sample and demo code gets the BSD headers. -Alan From daniel.fuchs at oracle.com Mon Oct 14 08:45:52 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 14 Oct 2013 08:45:52 +0000 Subject: hg: jdk8/tl/jdk: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Message-ID: <20131014084627.8B1D662361@hg.openjdk.java.net> Changeset: 9f8bfdd99129 Author: dfuchs Date: 2013-10-14 10:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8bfdd99129 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Reviewed-by: alanb, psandoz, mchung ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/ServiceLoader.java From paul.sandoz at oracle.com Mon Oct 14 08:50:11 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 10:50:11 +0200 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: <52585560.6080904@oracle.com> References: <52585560.6080904@oracle.com> Message-ID: Hi Ivan, Why do you require closeLock? is it not sufficient leave processExited as is and just add: public synchronized void close() throws IOException { super.close(); } Plus there was already some logic checking if close was asynchronously called (see BufferedInputStream.close): 372 if (buf == null) // asynchronous close()? 373 this.in = null; and this would no longer be required I am somewhat struggling to understand the test (not too familiar with this area). Requires a more expert eye in this area than I. IIUC you are trying to induce the the output process fd of ExecLoop to "flip" to another fd opened by OpenLoop. The test concerns me since it is gonna use up loads of resources and proceed for 10 minutes until deciding beyond reasonable doubt that there is no issue. Paul. On Oct 11, 2013, at 9:45 PM, Ivan Gerasimov wrote: > Hello all! > > Would you please help review a fix? > http://bugs.sun.com/view_bug.do?bug_id=8024521 > > As of JDK 1.7, ProcessPipeInputStream tries to drain the InputStream when the process exits. > However, it is racing with application code that could be closing the inputstream at the same time. > This can lead to processExited() operating on the wrong underlying file. > > The test included into the webrev demonstrates exactly that: Due to the race, the draining thread can suddenly start to read a huge file which will cause OutOfMemoryException. > > Here's the webrev with a simple fix, which synchronizes close() and processExited(): > http://cr.openjdk.java.net/~igerasim/8024521/0/webrev/ > > It's important to note that this simple fix isn't complete. > It only protects from the race when the file descriptor is closed by a call to Process#getInputStream().close(). > The file descriptor can still be asynchronously closed in some other way, for example by calling to the native close() function. > > Sincerely yours, > Ivan Gerasimov > From Alan.Bateman at oracle.com Mon Oct 14 08:58:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Oct 2013 09:58:08 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> Message-ID: <525BB220.1090100@oracle.com> On 10/10/2013 21:24, Brian Burkhalter wrote:On 10/10/2013 21:24, Brian Burkhalter wrote: > : > Assuming that the general idea is correct, there are a few possible alternatives for a final version for Windows. I am not concerned in this discussion about picky details including naming which can be fine tuned at the end. > > 1) In net_util_mh.c/NET_ThrowUnknownHostExceptionWithGaiError replace gai_strerror() with FormatMessage(). > > 2) In Inet4AddressImpl.c and Inet6AddressImpl.c replace NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowByNameWithLastError (see net_md_util.c). > > 3) In net_md_util.c change (line 97 in http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ version) > > { WSATRY_AGAIN, 0, "Nonauthoritative host not found" }, > > to > > { WSATRY_AGAIN, "UnknownHostException", "Nonauthoritative host not found" }, > > and in Inet4AddressImpl.c and Inet6AddressImpl.c replace NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowNew(). > > 4) In NET_ThrowUnknownHostExceptionWithGaiError instead of using gai_strerror() use the hard-coded error message "Nonauthoritative host not found". > > The pros and/or cons for each, respectively, are > > 1) Most closely matches the Unix version and avoids hard-coded messages. > > 2) Simple and obviates the need for NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message has a different format from the Unix version and contains the error code instead of an error string. > > 3) Simple and obviates the need for NET_ThrowUnknownHostExceptionWithGaiError(), but the exception message format is slightly different from the Unix version and the change could have the undesirable (and unpredictable) side effect of an UnknownHostException being thrown somewhere else where a SocketException used to be thrown. > > 4) Simplest option but has distasteful hard-coding (as do option 3 indirectly and NET_ThrowNew() for that matter). > > If the "con" of option 2 is acceptable then I think that would be the best way to go, otherwise option 1. > Option #2 seems reasonable, the exception messages for similar network conditions are rarely the same on Windows and Unix anyway. However I think it's important to have verified it with one or two errors to be confident that the errors translate as expected. One other thing to add is that winsock_errors dates from early versions of Windows whether there wasn't a means to translate Windows Sockets errors. We should look at eliminating it (not for JDK 8 of course, it's too late) so that all errors are handle translated consistently. -Alan From paul.sandoz at oracle.com Mon Oct 14 09:32:25 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 11:32:25 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> Message-ID: <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> On Oct 11, 2013, at 9:46 PM, Mike Duigou wrote: > > On Oct 10 2013, at 06:37 , Paul Sandoz wrote: > >> Hi Mike, >> >> This looks like a good direction. Need to look more closely. >> >> I wonder if we even require such detailed support to throw CME? > > Some additional CME will be thrown indirectly by iteration. This applies to forEach/replaceAll. Yes, that is OK (catching IllegalStateException). It is the explicit cases in other non-traversing methods i am referring to. > Virtually all the cases where CME is thrown in the "new" Map defaults are the points where previously the implementation would have looped/retried. > >> For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. > > Understood. The alternative would be to GIGO these situations, return and ignore them. > Yeah, unnecessarily complicates the code. >> For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". > > Modification of any other entry may have the same result. Yes, although IIUC modification, by the function value, of other entries will not interfere with that of operating on the entry under computation. A more general recommendation is the function values should be stateless. > I suspect that modification by some other thread is as likely to be a problem as modification by the function. > And under concurrent modification we cannot deterministically detect. CME in the non-concurrent collections is only useful for detecting serial modification due to inversion of control, and in these particular cases it is really very limited as to what it detects. Paul. > Any thoughts Doug? Is this advancing or retreating from the right direction? > > Mike From aleksej.efimov at oracle.com Mon Oct 14 09:36:02 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 14 Oct 2013 13:36:02 +0400 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <525A74B3.6040300@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> <525A74B3.6040300@oracle.com> Message-ID: <525BBB02.9060805@oracle.com> Hi, The second item is dropped - I was informed in a parallel review thread, that I can have one approval from a Reviewer and another approval[s] from members. The hg patch was updated and located here: http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch Can I ask for a sponsor help to push this fix? Thank you and Best Regards, Aleksej On 10/13/2013 02:23 PM, Aleksej Efimov wrote: > Michael, Masayoshi, > > Looks like, we can commit this changes with following items in mind: > 1. Generic names in TimeZoneNames_*.java should be added as part of > JDK-8025051 resolution. > 2. I need another one approval from a JDK 8 reviewer for this one. > > Anyway, the hg changeset patch can be found here: > http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch > > Best Regards, > Aleksej > > On 10/12/2013 12:43 AM, Michael Fang wrote: >> Hi Aleksej, >> >> Yes, you are right. They can be handled separately. Thanks! >> >> Regards, >> >> Michael >> Sent from my iPhone >> >> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: >> >>> Hi Michael, >>> As I can see this topic was touched a little here: http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task: https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. >>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? >>> >>> Thanks and Best Regards, >>> Aleksej >>> >>> On 11.10.2013 21:41, Michael Fang wrote: >>>> Hi Aleksej, >>>> >>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >>>> >>>> I think we can file a separate bug to track that issue. >>>> >>>> thanks, >>>> >>>> -michael >>>> >>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>>>> Hi Aleksej, >>>>> >>>>> Here are my review comments. >>>>> >>>>> - The copyright header of the data files shouldn't be removed. >>>>> >>>>> - TimeZoneNames.java: >>>>> >>>>> - "Middle Europe Time", "MET"}}, >>>>> + "MET", "MET"}}, >>>>> >>>>> I don't think the long name should be changed. >>>>> >>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>>>> Hi, >>>>>> >>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>>>> >>>>>> The brief list of changes: >>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>>>> 2. a) Updates to long time zone names >>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>>>> c) Removed unused ACT[] array >>>>>> d) Added "Europe/Busingen" time zone name >>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>>>> >>>>>> The following tests were executed on JDK 8 with fix: >>>>>> test/java/util/TimeZone >>>>>> test/java/util/Calendar >>>>>> test/java/util/Formatter >>>>>> test/sun/util/calendar >>>>>> test/java/time >>>>>> >>>>>> Testing result: All test passed >>>>>> >>>>>> Thanks! >>>>>> Aleksej >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ From ivan.gerasimov at oracle.com Mon Oct 14 09:36:53 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Oct 2013 13:36:53 +0400 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: References: <52585560.6080904@oracle.com> Message-ID: <525BBB35.4030701@oracle.com> Hi Paul, Thank you for looking at the webrev! On 14.10.2013 12:50, Paul Sandoz wrote: > Hi Ivan, > > Why do you require closeLock? is it not sufficient leave processExited as is and just add: > > public synchronized void close() throws IOException { > super.close(); > } I want to limit the impact on the code, that's why I synchronize close() with only processExited(). If I made close() synchronized with all the stream's methods, then I think it could introduce some unpredictable drawback. > Plus there was already some logic checking if close was asynchronously called (see BufferedInputStream.close): > > 372 if (buf == null) // asynchronous close()? > 373 this.in = null; > > and this would no longer be required Yes, you're right and these two lines can be removed. I wouldn't remove the surrounding try {} catch (IOException) though, as the stream can still be closed asynchronously. > I am somewhat struggling to understand the test (not too familiar with this area). Requires a more expert eye in this area than I. > > IIUC you are trying to induce the the output process fd of ExecLoop to "flip" to another fd opened by OpenLoop. Yes. I actually adopted a testcase provided by the reporter of the problem. I only changed the test in such a way that it can be run in an automated mode. Below is the exact comment from the original testcase. It may be a good idea to include it in the regtest. /* Following code is a test case that demonstrates a close race in ProcessPipeInputStream. *. * A snippet of the offending code within ProcessPipeInputStream:. * // Called by the process reaper thread when the process exits.. * synchronized void processExited() { * // Most BufferedInputStream methods are synchronized, but close() * // is not, and so we have to handle concurrent racing close(). * try { * InputStream in = this.in; * if (in != null) { * byte[] stragglers = drainInputStream(in); * in.close(); * * The comment even talks about the race. However, the code is not adequately * protecting against it. drainInputStream() (available() in particular) is not * threadsafe when a close happens in parallel. What's worse is that a subsequent * open() is likely to reassign the closed fd so drainInputStream ends up draining * the wrong fd! This can cause OOMs, data corruption on other fds, and other very * bad things. *. * Notes:. * - Test creates a large sparse file in /tmp/bigsparsefile * - Test uses "/proc/meminfo" for simple input.. * - Invoke using "-Xmx128m" to insure file size of 1G is greater than heap size * - Test will run forever, if successful there will not be any OOM exceptions * (on my test system they occur about 1 per minute) * - You need multiple cores (I use 2 x Xeon E5620 = 8 cores, 16 threads). *.. * The basic premise of the test is to create a 1GB sparse file. Then have lots * of threads opening and closing this file. In a loop within a separate thread use UNIXprocess * to run a simple command. We read the output of the command, make sure the process * has exited and then close the inputstream. When the bug happens, processExited() * will use FIONREAD to figure out how much data to drain BUT the fd it is checking * will be closed and reopened (now referring to /tmp/bigsparsefile) so it will * see the size as 1GB and then attempt to allocate a buffer of that size and. * then OOM.. */ > The test concerns me since it is gonna use up loads of resources and proceed for 10 minutes until deciding beyond reasonable doubt that there is no issue. When I ran the test across different machines (with the unpatched jdk) it reported from one to five races during 10 minutes. We can surely decrease the timeout for the price of higher probability of a false positive result. Sincerely yours, Ivan > Paul. > > On Oct 11, 2013, at 9:45 PM, Ivan Gerasimov wrote: > >> Hello all! >> >> Would you please help review a fix? >> http://bugs.sun.com/view_bug.do?bug_id=8024521 >> >> As of JDK 1.7, ProcessPipeInputStream tries to drain the InputStream when the process exits. >> However, it is racing with application code that could be closing the inputstream at the same time. >> This can lead to processExited() operating on the wrong underlying file. >> >> The test included into the webrev demonstrates exactly that: Due to the race, the draining thread can suddenly start to read a huge file which will cause OutOfMemoryException. >> >> Here's the webrev with a simple fix, which synchronizes close() and processExited(): >> http://cr.openjdk.java.net/~igerasim/8024521/0/webrev/ >> >> It's important to note that this simple fix isn't complete. >> It only protects from the race when the file descriptor is closed by a call to Process#getInputStream().close(). >> The file descriptor can still be asynchronously closed in some other way, for example by calling to the native close() function. >> >> Sincerely yours, >> Ivan Gerasimov >> From ivan.gerasimov at oracle.com Mon Oct 14 09:51:29 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Oct 2013 13:51:29 +0400 Subject: RFR [8023431] Test java/util/zip/GZIP/GZIPInZip.java failed Message-ID: <525BBEA1.8010202@oracle.com> Hello all! Would you please help review a fix for the intermittently failing regtest? http://bugs.sun.com/view_bug.do?bug_id=8023431 The reasons of the failures were non closed PipedInput/OutputStreams. Thus Read/write dead end were reported. The fix is to use try-with-resource for appropriate closing the streams. Here is the webrev: http://cr.openjdk.java.net/~igerasim/8023431/0/webrev/ In addition to the fix I added a small enhancement to the test itself. Now it also tests that the ZipStream isn't closed in the case of malformed nested GZiped entries. Sincerely yours, Ivan Gerasimov From aleksej.efimov at oracle.com Mon Oct 14 10:05:59 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 14 Oct 2013 14:05:59 +0400 Subject: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc In-Reply-To: <525B03AB.3020307@oracle.com> References: <525805D2.2040003@oracle.com> <52580B83.9050104@oracle.com> <52585816.2090907@oracle.com> <525863D7.1000908@oracle.com> <525A6F5A.9080506@oracle.com> <525B03AB.3020307@oracle.com> Message-ID: <525BC207.5040809@oracle.com> Thank you, Alan. I have updated the changeset (Aleksey was added as a reviewer): http://cr.openjdk.java.net/~aefimov/8008733/8008733_hg.export Best Regards, Aleksej On 10/14/2013 12:33 AM, Alan Bateman wrote: > On 13/10/2013 11:00, Aleksej Efimov wrote: >> : >> >> Alan, >> No, I don't have sponsor and I'll be very appreciate if you'll >> sponsor this commit. The changeset is located here: h >> ttp://cr.openjdk.java.net/~aefimov/8008733/8008733_hg.export >> . >> But I suppose, we will need another one formal review from a JDK8 >> reviewer. >> > Okay, I will push it for you on Monday. For the change-set then > Aleksey can also be listed on the Reviewed-by line (it's okay to list > non-Reviewers once you have at least one Reviewer). > > -Alan From alan.bateman at oracle.com Mon Oct 14 10:22:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Oct 2013 10:22:51 +0000 Subject: hg: jdk8/tl/jaxp: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Message-ID: <20131014102257.8AE596236F@hg.openjdk.java.net> Changeset: de8c803d4958 Author: aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de8c803d4958 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java From chris.hegarty at oracle.com Mon Oct 14 10:49:03 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Oct 2013 10:49:03 +0000 Subject: hg: jdk8/tl/jdk: 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Message-ID: <20131014104948.C8DD262372@hg.openjdk.java.net> Changeset: 077237e4613f Author: tyan Date: 2013-10-14 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/077237e4613f 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Reviewed-by: chegar, alanb ! test/java/net/Socks/SocksProxyVersion.java From paul.sandoz at oracle.com Mon Oct 14 11:33:05 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 13:33:05 +0200 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: <525BBB35.4030701@oracle.com> References: <52585560.6080904@oracle.com> <525BBB35.4030701@oracle.com> Message-ID: <2C2F4AD7-EC2F-4E01-BD5D-F3627D5207C8@oracle.com> On Oct 14, 2013, at 11:36 AM, Ivan Gerasimov wrote: > Hi Paul, > > Thank you for looking at the webrev! > > On 14.10.2013 12:50, Paul Sandoz wrote: >> Hi Ivan, >> >> Why do you require closeLock? is it not sufficient leave processExited as is and just add: >> >> public synchronized void close() throws IOException { >> super.close(); >> } > > I want to limit the impact on the code, that's why I synchronize close() with only processExited(). > If I made close() synchronized with all the stream's methods, then I think it could introduce some unpredictable drawback. > Yeah, the close will block until the drain is complete, which might also have some unpredictable drawback. A concern is there was already some code in place to check for async close, which if detected throws away all the data and sets the underlying filtered input stream is set to null. So all that effort draining is wasted. Another solution is to keep checking in the loop of drainInputStream for an async close and fail-fast: private InputStream drainInputStream(InputStream in) throws IOException { int n = 0; int j; byte[] a = null; while ((j = in.available()) > 0) { if (buf == null) // asynchronous close()? return null; // stop reading and discard a = (a == null) ? new byte[j] : Arrays.copyOf(a, n + j); n += in.read(a, n, j); } if (buf == null) // asynchronous close()? return null; // discard else if (a == null) return ProcessBuilder.NullInputStream.INSTANCE; else return ByteArrayInputStream(n == a.length ? a : Arrays.copyOf(a, n)); } /** Called by the process reaper thread when the process exits. */ synchronized void processExited() { // Most BufferedInputStream methods are synchronized, but close() // is not, and so we have to handle concurrent racing close(). try { InputStream in = this.in; if (in != null) { InputStream stragglers = drainInputStream(in); in.close(); this.in = stragglers; } } catch (IOException ignored) { // probably an asynchronous close(). } } This still has the potential to look at the availability of the current input before async closing, and read from a different input after async closing, but it will break out on the next loop check if there are more bytes available to read otherwise it will be caught again on the final check, so no munged data will be exposed. >> Plus there was already some logic checking if close was asynchronously called (see BufferedInputStream.close): >> >> 372 if (buf == null) // asynchronous close()? >> 373 this.in = null; >> >> and this would no longer be required > > Yes, you're right and these two lines can be removed. > I wouldn't remove the surrounding try {} catch (IOException) though, as the stream can still be closed asynchronously. > >> I am somewhat struggling to understand the test (not too familiar with this area). Requires a more expert eye in this area than I. >> >> IIUC you are trying to induce the the output process fd of ExecLoop to "flip" to another fd opened by OpenLoop. > > Yes. > I actually adopted a testcase provided by the reporter of the problem. > I only changed the test in such a way that it can be run in an automated mode. > > Below is the exact comment from the original testcase. > It may be a good idea to include it in the regtest. > > /* Following code is a test case that demonstrates a close race in ProcessPipeInputStream. > *. > * A snippet of the offending code within ProcessPipeInputStream:. > * // Called by the process reaper thread when the process exits.. > * synchronized void processExited() { > * // Most BufferedInputStream methods are synchronized, but close() > * // is not, and so we have to handle concurrent racing close(). > * try { > * InputStream in = this.in; > * if (in != null) { > * byte[] stragglers = drainInputStream(in); > * in.close(); > * > * The comment even talks about the race. However, the code is not adequately > * protecting against it. drainInputStream() (available() in particular) is not > * threadsafe when a close happens in parallel. What's worse is that a subsequent > * open() is likely to reassign the closed fd so drainInputStream ends up draining > * the wrong fd! This can cause OOMs, data corruption on other fds, and other very > * bad things. > *. > * Notes:. > * - Test creates a large sparse file in /tmp/bigsparsefile > * - Test uses "/proc/meminfo" for simple input.. > * - Invoke using "-Xmx128m" to insure file size of 1G is greater than heap size > * - Test will run forever, if successful there will not be any OOM exceptions > * (on my test system they occur about 1 per minute) > * - You need multiple cores (I use 2 x Xeon E5620 = 8 cores, 16 threads). > *.. > * The basic premise of the test is to create a 1GB sparse file. Then have lots > * of threads opening and closing this file. In a loop within a separate thread use UNIXprocess > * to run a simple command. We read the output of the command, make sure the process > * has exited and then close the inputstream. When the bug happens, processExited() > * will use FIONREAD to figure out how much data to drain BUT the fd it is checking > * will be closed and reopened (now referring to /tmp/bigsparsefile) so it will > * see the size as 1GB and then attempt to allocate a buffer of that size and. > * then OOM.. > */ > > > >> The test concerns me since it is gonna use up loads of resources and proceed for 10 minutes until deciding beyond reasonable doubt that there is no issue. > When I ran the test across different machines (with the unpatched jdk) it reported from one to five races during 10 minutes. > We can surely decrease the timeout for the price of higher probability of a false positive result. > Unit-like tests should really run in under a minute, plus should ideally be frugal in their resource consumption otherwise it could starve other tests running in parallel. If we cannot create a more deterministic test (not sure it is possible) then perhaps this test belongs to SQE and not in the JDK tests? Paul. From stefan.karlsson at oracle.com Mon Oct 14 12:40:22 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 14 Oct 2013 12:40:22 +0000 Subject: hg: jdk8/tl/jdk: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Message-ID: <20131014124112.178C06237C@hg.openjdk.java.net> Changeset: f15a0087181e Author: stefank Date: 2013-10-14 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15a0087181e 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Reviewed-by: coleenp, sla Contributed-by: stefan.karlsson at oracle.com, coleen.phillimore at oracle.com ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh From roger.riggs at oracle.com Mon Oct 14 14:34:35 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Oct 2013 10:34:35 -0400 Subject: Please Review: refactor of Chronology class Message-ID: <525C00FB.1000908@oracle.com> Hi, The java.time.chrono.Chronology should be split into an interface for Chronology and an AbstractChronology class that is the base for implementing a Chronology. A number of static methods on the java.time.chrono.Chronology class are inherited by subclasses but can be incorrectly understood to be instance methods. The methods 'from(Temporal)', of(String)', 'ofLocale(Locale)', and 'getAvailableChronologies()' all have the same static inheritance problem. They are intended as methods returning a Chronology but in the context of a specific Chronology, for example JapaneseChronology, can be confused with methods that return a JapaneseDate. Please Review: webrev: http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ [1] https://bugs.openjdk.java.net/browse/JDK-8025719 From paul.sandoz at oracle.com Mon Oct 14 15:27:49 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 17:27:49 +0200 Subject: Demo for Parallel Core Collection API In-Reply-To: References: Message-ID: <2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com> Hi, Some high-level points first: - try and use static import where possible. - suggest that all streams are sequential. There is an inconsistency in the use and in some cases it is embedded in other stream usages. - "ParallelCore" is not a very descriptive name. Suggest "streams". - suggest moving the data classes and XML parsing code to a separate package. - Unfortunately Supplier is overloaded with the functional interface in j.u.function. Not sure much could be done about that. More details below. I am not really commenting on the specific use-case, just the usages of the API itself, plus for brevity i have removed comments. Conversion -- A more compact form of mostTProductsByCategory (without comments) is: public static > Product[] mostTProductsByCategory( Function func){ Map> m = products.stream(). collect(groupingBy(Product::getCategory, maxBy(comparing(func)))); return m.values().stream(). map(Optional::get). toArray(Product[]::new); } i.e. show the Map rather than the Collector. A DRYer form: public static Collection countries(boolean ordered) { Stream countries = customers.stream().map(Customer::getCountry); if (ordered) { return countries.distinct().collect(toCollection(LinkedList::new)); } else { return countries.collect(Collectors.toSet()); } } Shame that the type witness is required. For sequential streams is probably no advantage here to providing a link list over a list except for API educational value. Elements -- Simpler form. The function to apply the terminal op obfuscates: public static Optional suppliersInCountry(boolean findAny, String country) { Stream s = suppliers.stream(). //filter supplier who is same sa given country filter(supplier -> country. equals(supplier.getCountry())); return findAny ? s.findAny() : s.findFirst(); } The use of the collector is complicating matters. Off the top of my head what you require is a reducer that reduces to the first product whose stock units is > 0: public static Map inStockProductsByCategory( boolean findAny) { BinaryOperator reduceToFirstMatch = (l, r) -> (l != null) ? l : (r != null && r.getUnitsInStock() > 0) ? r : null; return products.stream().collect( groupingBy(Product::getCategory, reducing(null, reduceToFirstMatch))); } The above relies on the associativity of the binary operator. There is no need to collect into a filtered list then stream with findAny/findFirst since we can reduce to the result as each element is received. That reduceToFirstMatch can easily be abstracted into a higher order function taking a predicate Grouping -- public static Map> groupOrdersByCustomer() { //a collector that generate a order list from a customer Collector, List> collectOrder = Collector. of(ArrayList::new, (orders, customer) -> { orders.addAll(customer.getOrders()); }, (left, right) -> { left.addAll(right); return left; }); return customers.parallelStream(). //convert customers to a Map which key is it name, value is its //orders collect(Collectors. groupingBy(Customer::getCompanyName, collectOrder)); } Not clear to me if there are multiple customers with the same name so the catamorphic collect may not be necessary and toMap can be used instead. Perhaps there is another way to show this collect usage? Can simplify: public static > Map> productMaxByTGroupByS(boolean maxBy, Function groupFunc, Function compFunc){ //Comparator of Product which will compare on T by given function Comparator comp = Comparator.comparing(compFunc); return products.stream(). //collect products into a Map, which key is S by function of //groupFunc, value is max or min by given max and function of //compFunc collect(groupingBy( groupFunc, maxBy ? maxBy(comp) : minBy(comp))); } Simplify: public static Map>> ordersByRThenT( Function func1,Function func2){ return customers.stream(). //map every customer to orders flatMap(customer -> customer.getOrders().stream()). //group products to Map by given two functions collect(groupingBy(func1, groupingBy(func2))); } Selection -- public static Map bigOrderCustomers(double bigValue) { Function orderTotal = c -> c.getOrders().stream(). //map order to order price mapToDouble(Order::getTotal). //calculate total price sum(); //A predicate which filter customer whose total order price is greater //than bigValue Predicate bigOrder = c -> orderTotal.apply(c) >= bigValue; return customers.parallelStream(). //filter customer whose total order price is greater than bigValue filter(bigOrder). //grouping customer to a Map which key is customer, value is //total order price collect( Collectors.toMap(Function.identity(), orderTotal)); } This is essentially performing the sum twice on each element that passes through the filter. Unfortunately we don't have tuples yet and that is what i think you really need to retain the calculation for use later on. It might be simpler just to create a Map then iterate over entries and remove ones that do not match. Subset -- public static List firstNOrdersFromState(int number, String state, Consumer action){ return customers.parallelStream(). //only take customers from a particular state filter(c -> state.equals(c.getRegion())). //get orders of those customers flatMap(c -> c.getOrders().stream()). //get first number of orders substream(0, number). //apply the supplied action peek(action). //collect to a list collect(Collectors.toList()); } Replace substream(0, number) with limit(number). The use of peek here is setting a bad precedent, suggest changing to return void and using forEach or removing it. Same applies for topNCustomer. Tabulate -- This is another example of where tuples or MapStream (a stream for a tuple of 2 elements) could be useful. It would be good to remove the Pair class if at all possible, if not it is best if containing within Tabulate as this is the only place that uses it. For sameCountryCustomerAndSuppliers, off the top of my head, it is possible to reformulate using two Maps and we do not need Pair: Map> countryToSuppliers = suppliers.stream().collect( // group suppliers by their country Collectors.groupingBy(Supplier::getCountry)); Map> s = customers.stream().collect( Collectors.toMap(Function::identity, c -> countryToSuppliers.getOrDefault(c.getCountry(), null))); Simplify: public static Set bothCustomerAndSupplier() { Set suppliersName = suppliers.stream(). map(Supplier::getSupplierName). collect(toSet()); return customers.stream(). map(Customer::getCompanyName). flatMap(c -> suppliersName.contains(c) ? Stream.of(c) : Stream.empty()). collect(toSet()); } Hth, Paul. On Oct 14, 2013, at 5:27 AM, Tristan Yan wrote: > Hi all > > > > Could you please help to review the demo code for parallel core collection API? > > http://cr.openjdk.java.net/~pzhang/Tristan/8023555/webrev/ > > > > Thank you very much > > > > > > Tristan Yan(Haibo Yan) > > Office : 8610-61066212 > > Fax : 8610-61065441 > > Cell : 86-18610696822 > > > > 2F, Building No. 24, Zhongguancun Software Park > > Haidian District HYPERLINK "http://people.us.oracle.com/pls/oracle/f?p=8000:6:396067987304343:::6:P6_CITY:Beijing"Beijing , 100193 > > oracle > > > From scolebourne at joda.org Mon Oct 14 15:37:32 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 14 Oct 2013 16:37:32 +0100 Subject: Please Review: refactor of Chronology class In-Reply-To: <525C00FB.1000908@oracle.com> References: <525C00FB.1000908@oracle.com> Message-ID: Fine by me (not an official reviewer) Stephen On 14 October 2013 15:34, roger riggs wrote: > Hi, > > The java.time.chrono.Chronology should be split into an interface for > Chronology > and an AbstractChronology class that is the base for implementing a > Chronology. > > A number of static methods on the java.time.chrono.Chronology class are > inherited by subclasses but can be incorrectly understood to be instance > methods. > The methods 'from(Temporal)', of(String)', 'ofLocale(Locale)', and > 'getAvailableChronologies()' all have the same static inheritance problem. > They are intended as methods returning a Chronology but in the context > of a specific Chronology, for example JapaneseChronology, can be confused > with methods that return a JapaneseDate. > > Please Review: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ > > javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8025719 From andrey.x.nazarov at oracle.com Mon Oct 14 15:46:46 2013 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 14 Oct 2013 19:46:46 +0400 Subject: Review: demos for jdk8 In-Reply-To: References: <52326F0F.9010707@oracle.com> <52581193.3020606@oracle.com> Message-ID: <525C11E6.9000607@oracle.com> Thank you Paul, I've fixed demo http://cr.openjdk.java.net/~anazarov/try-with-resources/webrev.01 --Thanks, Andrey. On 11.10.2013 19:04, Paul Benedict wrote: > I think there may be a problem with Console::close(). Even though the > Console instance will be disposed in a try-with-resources construct, > that doesn't the reader and writer are guaranteed to close together. > Currently, if the reader fails to close, the writer will be left > dangling. What do you think of putting a try/catch in close() (and > maybe suppressing one of them)? > > > On Fri, Oct 11, 2013 at 9:56 AM, Andrey Nazarov > > wrote: > > Hi guys, > > Did you have a chance to review our jdk8 demos? > > http://cr.openjdk.java.net/~anazarov/try-with-resources/ > > http://cr.openjdk.java.net/~anazarov/repeating-annotations/ > > http://cr.openjdk.java.net/~anazarov/jdk8-demo-bulkoperations/ > > http://cr.openjdk.java.net/~anazarov/extension-methods/ > > > > -- Andrey. > > On 13.09.2013 5:49, Andrey Nazarov wrote: > > I've fixed subject > > --- > > Hi guys, > > > > We want to push our demo code for try-with-resources feature > > Could you please review this code? > > http://cr.openjdk.java.net/~anazarov/try-with-resources/ > > > > > > > --Andrey. > > > > > > > > -- > Cheers, > Paul From chris.hegarty at oracle.com Mon Oct 14 15:52:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Oct 2013 16:52:08 +0100 Subject: RFR: ForkJoinTask leaks exceptions Message-ID: <525C1328.2090707@oracle.com> This is a request to pull a small change to ForkJoinTask into jdk8, from the jsr166 CVS. This was first discussed over on c-i [1] a few weeks back. diff -r 077237e4613f src/share/classes/java/util/concurrent/ForkJoinTask.java --- a/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 11:47:54 2013 +0100 +++ b/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 16:44:01 2013 +0100 @@ -439,11 +439,13 @@ public abstract class ForkJoinTask im final Throwable ex; ExceptionNode next; final long thrower; // use id not ref to avoid weak cycles + final int hashCode; // store task hashCode before weak ref disappears ExceptionNode(ForkJoinTask task, Throwable ex, ExceptionNode next) { super(task, exceptionTableRefQueue); this.ex = ex; this.next = next; this.thrower = Thread.currentThread().getId(); + this.hashCode = System.identityHashCode(task); } } @@ -605,9 +607,9 @@ public abstract class ForkJoinTask im private static void expungeStaleExceptions() { for (Object x; (x = exceptionTableRefQueue.poll()) != null;) { if (x instanceof ExceptionNode) { - ForkJoinTask key = ((ExceptionNode)x).get(); + int hashCode = ((ExceptionNode)x).hashCode; ExceptionNode[] t = exceptionTable; - int i = System.identityHashCode(key) & (t.length - 1); + int i = hashCode & (t.length - 1); ExceptionNode e = t[i]; ExceptionNode pred = null; while (e != null) { -Chris [1] http://jsr166-concurrency.10961.n7.nabble.com/ForkJoinTask-leaks-exceptions-td10134.html From paul.sandoz at oracle.com Mon Oct 14 15:59:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 17:59:14 +0200 Subject: Review request for jdeps option rename to Java-style and enhancements to output dot file format In-Reply-To: <525B030C.6000704@oracle.com> References: <5257A3E2.6050305@oracle.com> <525B030C.6000704@oracle.com> Message-ID: <6AD01F29-344F-4EE3-8BD3-2D1C1FC1934E@oracle.com> On Oct 13, 2013, at 10:31 PM, Alan Bateman wrote: > On 11/10/2013 08:08, Mandy Chung wrote: >> There were some discussion of jdeps CLI to follow GNU style option >> or the traditional Java style. As there will be plans to upgrade >> the JDK tools to GNU style options, it'd be desirable to keep jdeps >> be consistent with other langtools and be upgraded to GNU style in >> a unified manner. >> >> This patch includes the fixes for: >> JDK-8015912: jdeps output in dot graph format and option to find API dependences >> JDK-8026255: Switch jdeps to follow traditional Java option style >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ > Command line options are somewhat subjective, I think what you have is reasonable. I thought the GNU style that were in the original version were okay too (just takes getting used to) but keeping them consistent with similarly named options in the other tools is important tool. One change that I didn't quite understand is dropping -R for recursive, that one seemed intuitive (to me). > > Anyway, on the changes then I went through the webrev and I didn't see anything obviously wrong. A few comments: > > - In PlatformClassPath then alt-rt is special-cased and I think that can be removed now. > > - Also in PlatformClassPath is special handling of jfxrt.jar (if it is present) isn't clear. I recall this came up before and maybe it just needs a more detailed comment to explain why it is needed. > > - In Analyzer then I think I missed why the results are a LinkedHashMap, wouldn't HashMap do? > It preserves order of corresponding to the order of archives passed in, but AFAICT that is only taken into account when iterating on line 85, and such an order does not seem to be relevant. Paul. > - A minor comment in JdepsTask but I assume the OutputWriter interface can be private > > -Alan From paul.sandoz at oracle.com Mon Oct 14 16:04:08 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Oct 2013 18:04:08 +0200 Subject: RFR: ForkJoinTask leaks exceptions In-Reply-To: <525C1328.2090707@oracle.com> References: <525C1328.2090707@oracle.com> Message-ID: <5C6A4588-6A5D-40F8-B19B-A409A108781A@oracle.com> Looks good, Paul. On Oct 14, 2013, at 5:52 PM, Chris Hegarty wrote: > This is a request to pull a small change to ForkJoinTask into jdk8, from the jsr166 CVS. This was first discussed over on c-i [1] a few weeks back. > > diff -r 077237e4613f src/share/classes/java/util/concurrent/ForkJoinTask.java > --- a/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 11:47:54 2013 +0100 > +++ b/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 16:44:01 2013 +0100 > @@ -439,11 +439,13 @@ public abstract class ForkJoinTask im > final Throwable ex; > ExceptionNode next; > final long thrower; // use id not ref to avoid weak cycles > + final int hashCode; // store task hashCode before weak ref disappears > ExceptionNode(ForkJoinTask task, Throwable ex, ExceptionNode next) { > super(task, exceptionTableRefQueue); > this.ex = ex; > this.next = next; > this.thrower = Thread.currentThread().getId(); > + this.hashCode = System.identityHashCode(task); > } > } > > @@ -605,9 +607,9 @@ public abstract class ForkJoinTask im > private static void expungeStaleExceptions() { > for (Object x; (x = exceptionTableRefQueue.poll()) != null;) { > if (x instanceof ExceptionNode) { > - ForkJoinTask key = ((ExceptionNode)x).get(); > + int hashCode = ((ExceptionNode)x).hashCode; > ExceptionNode[] t = exceptionTable; > - int i = System.identityHashCode(key) & (t.length - 1); > + int i = hashCode & (t.length - 1); > ExceptionNode e = t[i]; > ExceptionNode pred = null; > while (e != null) { > > > -Chris > > [1] http://jsr166-concurrency.10961.n7.nabble.com/ForkJoinTask-leaks-exceptions-td10134.html From ivan.gerasimov at oracle.com Mon Oct 14 16:04:18 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Oct 2013 20:04:18 +0400 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: <2C2F4AD7-EC2F-4E01-BD5D-F3627D5207C8@oracle.com> References: <52585560.6080904@oracle.com> <525BBB35.4030701@oracle.com> <2C2F4AD7-EC2F-4E01-BD5D-F3627D5207C8@oracle.com> Message-ID: <525C1602.8090200@oracle.com> Thanks Paul! Yes, I like your solution better. I'll test it and send the updated webrev shortly. Sincerely yours, Ivan On 14.10.2013 15:33, Paul Sandoz wrote: > On Oct 14, 2013, at 11:36 AM, Ivan Gerasimov wrote: > >> Hi Paul, >> >> Thank you for looking at the webrev! >> >> On 14.10.2013 12:50, Paul Sandoz wrote: >>> Hi Ivan, >>> >>> Why do you require closeLock? is it not sufficient leave processExited as is and just add: >>> >>> public synchronized void close() throws IOException { >>> super.close(); >>> } >> I want to limit the impact on the code, that's why I synchronize close() with only processExited(). >> If I made close() synchronized with all the stream's methods, then I think it could introduce some unpredictable drawback. >> > Yeah, the close will block until the drain is complete, which might also have some unpredictable drawback. > > A concern is there was already some code in place to check for async close, which if detected throws away all the data and sets the underlying filtered input stream is set to null. So all that effort draining is wasted. > > Another solution is to keep checking in the loop of drainInputStream for an async close and fail-fast: > > private InputStream drainInputStream(InputStream in) > throws IOException { > int n = 0; > int j; > byte[] a = null; > while ((j = in.available()) > 0) { > if (buf == null) // asynchronous close()? > return null; // stop reading and discard > a = (a == null) ? new byte[j] : Arrays.copyOf(a, n + j); > n += in.read(a, n, j); > } > > if (buf == null) // asynchronous close()? > return null; // discard > else if (a == null) > return ProcessBuilder.NullInputStream.INSTANCE; > else > return ByteArrayInputStream(n == a.length ? a : Arrays.copyOf(a, n)); > } > > /** Called by the process reaper thread when the process exits. */ > synchronized void processExited() { > // Most BufferedInputStream methods are synchronized, but close() > // is not, and so we have to handle concurrent racing close(). > try { > InputStream in = this.in; > if (in != null) { > InputStream stragglers = drainInputStream(in); > in.close(); > this.in = stragglers; > } > } catch (IOException ignored) { > // probably an asynchronous close(). > } > } > > This still has the potential to look at the availability of the current input before async closing, and read from a different input after async closing, but it will break out on the next loop check if there are more bytes available to read otherwise it will be caught again on the final check, so no munged data will be exposed. > > > >>> Plus there was already some logic checking if close was asynchronously called (see BufferedInputStream.close): >>> >>> 372 if (buf == null) // asynchronous close()? >>> 373 this.in = null; >>> >>> and this would no longer be required >> Yes, you're right and these two lines can be removed. >> I wouldn't remove the surrounding try {} catch (IOException) though, as the stream can still be closed asynchronously. >> >>> I am somewhat struggling to understand the test (not too familiar with this area). Requires a more expert eye in this area than I. >>> >>> IIUC you are trying to induce the the output process fd of ExecLoop to "flip" to another fd opened by OpenLoop. >> Yes. >> I actually adopted a testcase provided by the reporter of the problem. >> I only changed the test in such a way that it can be run in an automated mode. >> >> Below is the exact comment from the original testcase. >> It may be a good idea to include it in the regtest. >> >> /* Following code is a test case that demonstrates a close race in ProcessPipeInputStream. >> *. >> * A snippet of the offending code within ProcessPipeInputStream:. >> * // Called by the process reaper thread when the process exits.. >> * synchronized void processExited() { >> * // Most BufferedInputStream methods are synchronized, but close() >> * // is not, and so we have to handle concurrent racing close(). >> * try { >> * InputStream in = this.in; >> * if (in != null) { >> * byte[] stragglers = drainInputStream(in); >> * in.close(); >> * >> * The comment even talks about the race. However, the code is not adequately >> * protecting against it. drainInputStream() (available() in particular) is not >> * threadsafe when a close happens in parallel. What's worse is that a subsequent >> * open() is likely to reassign the closed fd so drainInputStream ends up draining >> * the wrong fd! This can cause OOMs, data corruption on other fds, and other very >> * bad things. >> *. >> * Notes:. >> * - Test creates a large sparse file in /tmp/bigsparsefile >> * - Test uses "/proc/meminfo" for simple input.. >> * - Invoke using "-Xmx128m" to insure file size of 1G is greater than heap size >> * - Test will run forever, if successful there will not be any OOM exceptions >> * (on my test system they occur about 1 per minute) >> * - You need multiple cores (I use 2 x Xeon E5620 = 8 cores, 16 threads). >> *.. >> * The basic premise of the test is to create a 1GB sparse file. Then have lots >> * of threads opening and closing this file. In a loop within a separate thread use UNIXprocess >> * to run a simple command. We read the output of the command, make sure the process >> * has exited and then close the inputstream. When the bug happens, processExited() >> * will use FIONREAD to figure out how much data to drain BUT the fd it is checking >> * will be closed and reopened (now referring to /tmp/bigsparsefile) so it will >> * see the size as 1GB and then attempt to allocate a buffer of that size and. >> * then OOM.. >> */ >> >> >> >>> The test concerns me since it is gonna use up loads of resources and proceed for 10 minutes until deciding beyond reasonable doubt that there is no issue. >> When I ran the test across different machines (with the unpatched jdk) it reported from one to five races during 10 minutes. >> We can surely decrease the timeout for the price of higher probability of a false positive result. >> > Unit-like tests should really run in under a minute, plus should ideally be frugal in their resource consumption otherwise it could starve other tests running in parallel. If we cannot create a more deterministic test (not sure it is possible) then perhaps this test belongs to SQE and not in the JDK tests? > > Paul. From joe.darcy at oracle.com Mon Oct 14 16:20:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Oct 2013 09:20:30 -0700 Subject: RFR [8023431] Test java/util/zip/GZIP/GZIPInZip.java failed In-Reply-To: <525BBEA1.8010202@oracle.com> References: <525BBEA1.8010202@oracle.com> Message-ID: <525C19CE.5050206@oracle.com> Hi Ivan, The try with resource changes look fine. Cheers, -Joe On 10/14/2013 2:51 AM, Ivan Gerasimov wrote: > Hello all! > > Would you please help review a fix for the intermittently failing > regtest? > http://bugs.sun.com/view_bug.do?bug_id=8023431 > > > The reasons of the failures were non closed PipedInput/OutputStreams. > Thus Read/write dead end were reported. > > The fix is to use try-with-resource for appropriate closing the streams. > Here is the webrev: > http://cr.openjdk.java.net/~igerasim/8023431/0/webrev/ > > In addition to the fix I added a small enhancement to the test itself. > Now it also tests that the ZipStream isn't closed in the case of > malformed nested GZiped entries. > > Sincerely yours, > Ivan Gerasimov > From mike.duigou at oracle.com Mon Oct 14 16:25:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 14 Oct 2013 09:25:20 -0700 Subject: RFR: ForkJoinTask leaks exceptions In-Reply-To: <525C1328.2090707@oracle.com> References: <525C1328.2090707@oracle.com> Message-ID: <41B5762A-CA8B-42BF-8FF7-53D9408B674F@oracle.com> Looks fine. Is it practical to create a regression test for this case? Mike On Oct 14 2013, at 08:52 , Chris Hegarty wrote: > This is a request to pull a small change to ForkJoinTask into jdk8, from the jsr166 CVS. This was first discussed over on c-i [1] a few weeks back. > > diff -r 077237e4613f src/share/classes/java/util/concurrent/ForkJoinTask.java > --- a/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 11:47:54 2013 +0100 > +++ b/src/share/classes/java/util/concurrent/ForkJoinTask.java Mon Oct 14 16:44:01 2013 +0100 > @@ -439,11 +439,13 @@ public abstract class ForkJoinTask im > final Throwable ex; > ExceptionNode next; > final long thrower; // use id not ref to avoid weak cycles > + final int hashCode; // store task hashCode before weak ref disappears > ExceptionNode(ForkJoinTask task, Throwable ex, ExceptionNode next) { > super(task, exceptionTableRefQueue); > this.ex = ex; > this.next = next; > this.thrower = Thread.currentThread().getId(); > + this.hashCode = System.identityHashCode(task); > } > } > > @@ -605,9 +607,9 @@ public abstract class ForkJoinTask im > private static void expungeStaleExceptions() { > for (Object x; (x = exceptionTableRefQueue.poll()) != null;) { > if (x instanceof ExceptionNode) { > - ForkJoinTask key = ((ExceptionNode)x).get(); > + int hashCode = ((ExceptionNode)x).hashCode; > ExceptionNode[] t = exceptionTable; > - int i = System.identityHashCode(key) & (t.length - 1); > + int i = hashCode & (t.length - 1); > ExceptionNode e = t[i]; > ExceptionNode pred = null; > while (e != null) { > > > -Chris > > [1] http://jsr166-concurrency.10961.n7.nabble.com/ForkJoinTask-leaks-exceptions-td10134.html From ivan.gerasimov at oracle.com Mon Oct 14 16:25:59 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Oct 2013 20:25:59 +0400 Subject: RFR [8023431] Test java/util/zip/GZIP/GZIPInZip.java failed In-Reply-To: <525C19CE.5050206@oracle.com> References: <525BBEA1.8010202@oracle.com> <525C19CE.5050206@oracle.com> Message-ID: <525C1B17.60403@oracle.com> Thank you Joe! Ivan On 14.10.2013 20:20, Joe Darcy wrote: > Hi Ivan, > > The try with resource changes look fine. > > Cheers, > > -Joe > > On 10/14/2013 2:51 AM, Ivan Gerasimov wrote: >> Hello all! >> >> Would you please help review a fix for the intermittently failing >> regtest? >> http://bugs.sun.com/view_bug.do?bug_id=8023431 >> >> >> The reasons of the failures were non closed PipedInput/OutputStreams. >> Thus Read/write dead end were reported. >> >> The fix is to use try-with-resource for appropriate closing the streams. >> Here is the webrev: >> http://cr.openjdk.java.net/~igerasim/8023431/0/webrev/ >> >> In addition to the fix I added a small enhancement to the test itself. >> Now it also tests that the ZipStream isn't closed in the case of >> malformed nested GZiped entries. >> >> Sincerely yours, >> Ivan Gerasimov >> > > > From xueming.shen at oracle.com Mon Oct 14 16:40:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Oct 2013 09:40:36 -0700 Subject: RFR [8023431] Test java/util/zip/GZIP/GZIPInZip.java failed In-Reply-To: <525BBEA1.8010202@oracle.com> References: <525BBEA1.8010202@oracle.com> Message-ID: <525C1E84.2000301@oracle.com> looks fine. On 10/14/2013 02:51 AM, Ivan Gerasimov wrote: > Hello all! > > Would you please help review a fix for the intermittently failing regtest? > http://bugs.sun.com/view_bug.do?bug_id=8023431 > > > The reasons of the failures were non closed PipedInput/OutputStreams. > Thus Read/write dead end were reported. > > The fix is to use try-with-resource for appropriate closing the streams. > Here is the webrev: > http://cr.openjdk.java.net/~igerasim/8023431/0/webrev/ > > In addition to the fix I added a small enhancement to the test itself. > Now it also tests that the ZipStream isn't closed in the case of malformed nested GZiped entries. > > Sincerely yours, > Ivan Gerasimov > From joe.darcy at oracle.com Mon Oct 14 16:31:54 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Oct 2013 09:31:54 -0700 Subject: Please Review: refactor of Chronology class In-Reply-To: <525C00FB.1000908@oracle.com> References: <525C00FB.1000908@oracle.com> Message-ID: <525C1C7A.9070402@oracle.com> Hi Roger, Looks fine; thanks, -Joe On 10/14/2013 7:34 AM, roger riggs wrote: > Hi, > > The java.time.chrono.Chronology should be split into an interface for > Chronology > and an AbstractChronology class that is the base for implementing a > Chronology. > > A number of static methods on the java.time.chrono.Chronology class are > inherited by subclasses but can be incorrectly understood to be > instance methods. > The methods 'from(Temporal)', of(String)', 'ofLocale(Locale)', and > 'getAvailableChronologies()' all have the same static inheritance > problem. > They are intended as methods returning a Chronology but in the context > of a specific Chronology, for example JapaneseChronology, can be confused > with methods that return a JapaneseDate. > > Please Review: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ > > javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8025719 From ivan.gerasimov at oracle.com Mon Oct 14 16:34:28 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Oct 2013 20:34:28 +0400 Subject: RFR [8023431] Test java/util/zip/GZIP/GZIPInZip.java failed In-Reply-To: <525C1E84.2000301@oracle.com> References: <525BBEA1.8010202@oracle.com> <525C1E84.2000301@oracle.com> Message-ID: <525C1D14.9050106@oracle.com> Thank you Sherman! Ivan On 14.10.2013 20:40, Xueming Shen wrote: > looks fine. > > On 10/14/2013 02:51 AM, Ivan Gerasimov wrote: >> Hello all! >> >> Would you please help review a fix for the intermittently failing >> regtest? >> http://bugs.sun.com/view_bug.do?bug_id=8023431 >> >> >> The reasons of the failures were non closed PipedInput/OutputStreams. >> Thus Read/write dead end were reported. >> >> The fix is to use try-with-resource for appropriate closing the streams. >> Here is the webrev: >> http://cr.openjdk.java.net/~igerasim/8023431/0/webrev/ >> >> In addition to the fix I added a small enhancement to the test itself. >> Now it also tests that the ZipStream isn't closed in the case of >> malformed nested GZiped entries. >> >> Sincerely yours, >> Ivan Gerasimov >> > > > From roger.riggs at oracle.com Mon Oct 14 17:49:56 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 14 Oct 2013 13:49:56 -0400 Subject: Please Review Separate temporal interface layer (8025720) Message-ID: <525C2EC4.3080302@oracle.com> Hi, The concrete argument types of Chronology and ZoneId in the TemporalField.resolve method are too specific and should be generalized to allow greater access to the Temporal being resolved. They should be replaced by a single more general argument of type TemporalAccessor that can be queried as needed. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-temporal-layer-8025720/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8025720 From daniel.fuchs at oracle.com Mon Oct 14 18:05:48 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Oct 2013 20:05:48 +0200 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Message-ID: <525C327C.9010400@oracle.com> Hi, Please find below a fix for: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In some circumstances the call to JavaAWTAccess.getAppletContext() will trigger a call to ecx.threadGroup.getParent() == null The trouble is that this call will require a "modifyThreadGroup" permission if it happens that ecx.threadGroup.getParent() is the root thread group. The fix for that is simple - the call to ecx.threadGroup.getParent() == null needs to be done within a doPrivileged: The reg test fails without the fix and passes with it. best regards, -- daniel From Alan.Bateman at oracle.com Mon Oct 14 18:19:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Oct 2013 19:19:24 +0100 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525C327C.9010400@oracle.com> References: <525C327C.9010400@oracle.com> Message-ID: <525C35AC.1040802@oracle.com> On 14/10/2013 19:05, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8026404: Logging in Applet can trigger ACE: > access denied ("java.lang.RuntimePermission" > "modifyThreadGroup") > > In some circumstances the call to JavaAWTAccess.getAppletContext() > will trigger a call to ecx.threadGroup.getParent() == null > The trouble is that this call will require a "modifyThreadGroup" > permission if it happens that ecx.threadGroup.getParent() is > the root thread group. > > The fix for that is simple - the call to > ecx.threadGroup.getParent() == null > needs to be done within a doPrivileged: > > > > The reg test fails without the fix and passes with it. The change looks okay to me but I would suggest sending to awt-dev so that the folks that maintain this area know about it. On the test then does initializing SunToolkit cause AWT to be initialized? I just wonder if this test will run headless. -Alan. From huizhe.wang at oracle.com Mon Oct 14 18:21:42 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 14 Oct 2013 11:21:42 -0700 Subject: RFR (JAXP) : 8015092 : SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Message-ID: <525C3636.4020106@oracle.com> Hi, This is a quick conformance fix to allow whitespace in xpath expression such as '. //.'. http://cr.openjdk.java.net/~joehw/jdk8/8015092/webrev/ Thanks, Joe From alexander.zuev at oracle.com Mon Oct 14 18:44:11 2013 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 14 Oct 2013 22:44:11 +0400 Subject: RFR 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking Message-ID: <525C3B7B.7010009@oracle.com> Hi, please review my fix for 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking The fix adds new option to the jar command which makes created jars normalized without the need to invoke the external program. Bug description: https://bugs.openjdk.java.net/browse/JDK-8020802 Webrev with proposed fix: http://cr.openjdk.java.net/~kizune/8020802/webrev.01 With best regards, /Alex From lana.steuck at oracle.com Mon Oct 14 18:47:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:32 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20131014184751.C582862391@hg.openjdk.java.net> Changeset: d69f4ac43d64 Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d69f4ac43d64 Merge Changeset: cdc3577cba0b Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cdc3577cba0b Merge Changeset: 4712979714d1 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4712979714d1 Merge Changeset: 91ae0f2045bc Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/91ae0f2045bc Merge From lana.steuck at oracle.com Mon Oct 14 18:47:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:44 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131014184753.2CCFC62393@hg.openjdk.java.net> Changeset: 3551855c4f40 Author: lana Date: 2013-10-08 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3551855c4f40 Merge - make/java.security.override Changeset: b48b719c5efc Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b48b719c5efc Merge - make/java.security.override Changeset: 1b0a71a9920a Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1b0a71a9920a Merge From lana.steuck at oracle.com Mon Oct 14 18:47:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:57 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20131014184806.311CC62394@hg.openjdk.java.net> Changeset: 4dfcf3a6902f Author: lana Date: 2013-10-08 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dfcf3a6902f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: 2f43529df42f Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2f43529df42f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: f329c374da4b Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f329c374da4b Merge From lana.steuck at oracle.com Mon Oct 14 18:47:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:36 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20131014184752.2548F62392@hg.openjdk.java.net> Changeset: 1d6c13d3b8de Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1d6c13d3b8de Merge Changeset: 7c0a7937f6ef Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7c0a7937f6ef Merge Changeset: 328b8b96773b Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/328b8b96773b Merge From Lance.Andersen at oracle.com Mon Oct 14 18:52:22 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 14 Oct 2013 14:52:22 -0400 Subject: RFR (JAXP) : 8015092 : SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression In-Reply-To: <525C3636.4020106@oracle.com> References: <525C3636.4020106@oracle.com> Message-ID: <3B1DB088-ABA4-46B8-997C-26001DC4DEE2@oracle.com> Looks OK On Oct 14, 2013, at 2:21 PM, huizhe wang wrote: > Hi, > > This is a quick conformance fix to allow whitespace in xpath expression such as '. //.'. > > http://cr.openjdk.java.net/~joehw/jdk8/8015092/webrev/ > > Thanks, > Joe 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 daniel.fuchs at oracle.com Mon Oct 14 19:19:14 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Oct 2013 21:19:14 +0200 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Message-ID: <525C43B2.6000007@oracle.com> Adding awt-dev... > The change looks okay to me but I would suggest sending to awt-dev so that the folks that maintain this area know about it. > > On the test then does initializing SunToolkit cause AWT to be initialized? I just wonder if this test will run headless. > > -Alan. Hi, Please find below a fix for: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In some circumstances the call to JavaAWTAccess.getAppletContext() will trigger a call to ecx.threadGroup.getParent() == null The trouble is that this call will require a "modifyThreadGroup" permission if it happens that ecx.threadGroup.getParent() is the root thread group. The fix for that is simple - the call to ecx.threadGroup.getParent() == null needs to be done within a doPrivileged: The reg test fails without the fix and passes with it. best regards, -- daniel From lana.steuck at oracle.com Mon Oct 14 18:47:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:22 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20131014184724.A016E6238F@hg.openjdk.java.net> Changeset: 7c0e2fd8be4d Author: lana Date: 2013-10-08 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7c0e2fd8be4d Merge Changeset: 3ece65f23ed2 Author: lana Date: 2013-10-11 00:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3ece65f23ed2 Merge Changeset: d35943431696 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d35943431696 Merge From jonathan.gibbons at oracle.com Mon Oct 14 19:38:46 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Oct 2013 19:38:46 +0000 Subject: hg: jdk8/tl/langtools: 8026368: doclint does not report empty tags when tag closed implicitly Message-ID: <20131014193849.5D63A6239B@hg.openjdk.java.net> Changeset: b024fe427d24 Author: jjg Date: 2013-10-14 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b024fe427d24 8026368: doclint does not report empty tags when tag closed implicitly Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out From brian.burkhalter at oracle.com Mon Oct 14 19:43:49 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 14 Oct 2013 12:43:49 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <525BB220.1090100@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> <525BB220.1090100@oracle.com> Message-ID: <916787D6-258A-4DA3-A732-C79F8E210C46@oracle.com> On Oct 14, 2013, at 1:58 AM, Alan Bateman wrote: >> 2) In Inet4AddressImpl.c and Inet6AddressImpl.c replace NET_ThrowUnknownHostExceptionWithGaiError with NET_ThrowByNameWithLastError (see net_md_util.c). >> >> [?] >> >> If the "con" of option 2 is acceptable then I think that would be the best way to go, otherwise option 1. >> > Option #2 seems reasonable, the exception messages for similar network conditions are rarely the same on Windows and Unix anyway. Here's the patch updated for this option: http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ > However I think it's important to have verified it with one or two errors to be confident that the errors translate as expected. I can do this if we are actually going with this change for JDK 8. > One other thing to add is that winsock_errors dates from early versions of Windows whether there wasn't a means to translate Windows Sockets errors. We should look at eliminating it (not for JDK 8 of course, it's too late) so that all errors are handle translated consistently. See https://bugs.openjdk.java.net/browse/JDK-4842142. Brian From huizhe.wang at oracle.com Mon Oct 14 19:57:41 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 14 Oct 2013 12:57:41 -0700 Subject: RFR (JAXP) : 8015092 : SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression In-Reply-To: <3B1DB088-ABA4-46B8-997C-26001DC4DEE2@oracle.com> References: <525C3636.4020106@oracle.com> <3B1DB088-ABA4-46B8-997C-26001DC4DEE2@oracle.com> Message-ID: <525C4CB5.1010307@oracle.com> Thanks! On 10/14/2013 11:52 AM, Lance Andersen wrote: > Looks OK > On Oct 14, 2013, at 2:21 PM, huizhe wang > wrote: > >> Hi, >> >> This is a quick conformance fix to allow whitespace in xpath >> expression such as '. //.'. >> >> http://cr.openjdk.java.net/~joehw/jdk8/8015092/webrev/ >> >> >> Thanks, >> Joe > > > > 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 henry.jen at oracle.com Mon Oct 14 20:03:34 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 14 Oct 2013 13:03:34 -0700 Subject: RFR: 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Message-ID: <525C4E16.8000708@oracle.com> Hi, Please review a quick one line fix for the test, we simply "pass"(ignore) the test instead of "skip" the test. Ignore the test is the intention. It would be ideal if we know it's "skipped" intentionally, but currently jtreg consider a skipped test with a throwable failed test for other scenarios, which certainly can be reviewed separately. In the mean time, we should get rid of this noise. Cheers, Henry http://cr.openjdk.java.net/~henryjen/tl/8026362/0/webrev/ From Alan.Bateman at oracle.com Mon Oct 14 20:04:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Oct 2013 21:04:27 +0100 Subject: RFR (JAXP) : 8015092 : SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression In-Reply-To: <525C3636.4020106@oracle.com> References: <525C3636.4020106@oracle.com> Message-ID: <525C4E4B.3020301@oracle.com> On 14/10/2013 19:21, huizhe wang wrote: > Hi, > > This is a quick conformance fix to allow whitespace in xpath > expression such as '. //.'. > > http://cr.openjdk.java.net/~joehw/jdk8/8015092/webrev/ A minor comment on the test but it might be cleaner to set XSDFILE to "idJ029.xsd" and then use new File(System.getProperty("test.src", "."), XSDFILE) rather than concatenating the Strings. -Alan From lana.steuck at oracle.com Mon Oct 14 18:50:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:50:33 +0000 Subject: hg: jdk8/tl/jdk: 63 new changesets Message-ID: <20131014190553.ABDF662395@hg.openjdk.java.net> Changeset: 8a041011b6e6 Author: jgodinez Date: 2013-09-27 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a041011b6e6 6870661: Setting a custom PrintService on a PrinterJob leads to a PrinterException Reviewed-by: prr, jgodinez Contributed-by: patrick at reini.net ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintDialog.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java + test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java Changeset: 31b8d4931a09 Author: prr Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31b8d4931a09 8020190: Fatal: Bug in native code: jfieldID must match object Reviewed-by: jgodinez, vadim ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/native/sun/font/freetypeScaler.c Changeset: 6ef33b4553a4 Author: vadim Date: 2013-09-30 12:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ef33b4553a4 8001119: [fingbugs] Evaluate necessity to make some arrays package protected Reviewed-by: prr, bae + src/share/classes/com/sun/imageio/plugins/bmp/BMPCompressionTypes.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.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/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java Changeset: e2604b873b36 Author: prr Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2604b873b36 8007386: On physical machine (video card is Intel Q45) the text is blank. Reviewed-by: prr, jchen ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 96ff585555f4 Author: vadim Date: 2013-10-02 10:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96ff585555f4 8024343: Change different color with the "The XOR alternation color" combobox, the color of the image can not shown immediately. Reviewed-by: ceisserer, prr, bae ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java + test/sun/java2d/AcceleratedXORModeTest.java Changeset: 5f3d984d8207 Author: prr Date: 2013-10-02 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f3d984d8207 8025837: Extraneous changes in the fix for 8007386 Reviewed-by: jgodinez, jchen ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: f53aeb3c7eed Author: prr Date: 2013-10-02 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f53aeb3c7eed 7179526: xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 Reviewed-by: prr, jchen ! 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/XRDrawLine.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java + test/java/awt/Graphics/LineClipTest.java Changeset: a15cad0e12d3 Author: bae Date: 2013-10-03 11:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a15cad0e12d3 8022632: Reading a PNG file fails because of WBMPImageReaderSpi.canDecodeInput() Reviewed-by: prr, jgodinez ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/StreamResetTest.java Changeset: 2f11a00279ec Author: jchen Date: 2013-10-03 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f11a00279ec 8025280: [parfait] warnings from b107 for jdk.src.share.native.sun.java2d.loops: JNI exception pending, JNI critical region violation Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! 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/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: e88d39b110dd Author: jchen Date: 2013-10-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88d39b110dd 8025480: [parfait] "JNI exception pending" warnings from b107 for jdk.src.share.native.sun.java2d Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c Changeset: 3c1b13ad0677 Author: jchen Date: 2013-10-03 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1b13ad0677 8025309: [parfait] JNI-related warnings from b107 for jdk.src.share.native.sun.java2d.pipe Reviewed-by: prr, jgodinez ! 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 Changeset: d37594b689ce Author: jchen Date: 2013-10-03 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d37594b689ce 8025664: [parfait] warnings from b62 for jdk.src.share.native.sun.font Reviewed-by: prr, jgodinez ! src/share/native/sun/font/freetypeScaler.c Changeset: 0ed939dc4230 Author: jchen Date: 2013-10-03 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ed939dc4230 8025294: [parfait] JNI-related warnings from b107 for jdk.src.solaris.native.sun.java2d.x11 Reviewed-by: prr, jgodinez ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 8fd757f31470 Author: jchen Date: 2013-10-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fd757f31470 8025940: Windows build fails after the fix for 8025280 Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/MaskBlit.c Changeset: 727b60f9c09c Author: lana Date: 2013-10-08 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/727b60f9c09c Merge Changeset: e4e151f6ae50 Author: yan Date: 2013-09-27 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4e151f6ae50 8025249: [javadoc] fix some javadoc errors in javax/swing/ Reviewed-by: alexsch, yan Contributed-by: Taras Ledkov ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.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/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/Document.java ! src/share/classes/javax/swing/text/Element.java ! src/share/classes/javax/swing/text/View.java Changeset: ca45169cb4eb Author: pchelko Date: 2013-09-27 14:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca45169cb4eb 8024122: [TEST] need test to cover JDK-7146572 Reviewed-by: anthony, yan Contributed-by: Alexander Stepanov + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java Changeset: ad7db846c951 Author: pchelko Date: 2013-09-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad7db846c951 8025503: [macosx] FileDialog allows file selection with apple.awt.fileDialogForDirectories = true Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 260bc59ca253 Author: pchelko Date: 2013-09-27 18:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/260bc59ca253 8016563: Test closed/java/awt/dnd/ImageTransferTest/ImageTransferTest.html fails Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: bfff9e9120ec Author: malenkov Date: 2013-09-27 22:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfff9e9120ec 8012716: java.beans.EventHandler.create method should check if the given listenerInterface is a public interface Reviewed-by: art, mchung ! src/share/classes/java/beans/EventHandler.java Changeset: 0042f54f65d0 Author: malenkov Date: 2013-09-27 22:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0042f54f65d0 7117595: ArrayIndexOutOfBoundsException in Win32GraphicsEnvironment if display is removed Reviewed-by: anthony, serb ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 603cd3cefbb0 Author: malenkov Date: 2013-09-30 22:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/603cd3cefbb0 8025652: [macos] build failed Reviewed-by: serb ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: cdfa2301a291 Author: serb Date: 2013-10-01 04:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdfa2301a291 7150100: [macosx] "0123456789" is selected in the TextField Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/SelectionVisible/SelectionVisible.html + test/java/awt/TextArea/SelectionVisible/SelectionVisible.java + test/java/awt/TextField/SelectionVisible/SelectionVisible.html + test/java/awt/TextField/SelectionVisible/SelectionVisible.java Changeset: 2d8418d68a3c Author: kshefov Date: 2013-10-01 13:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d8418d68a3c 7125471: [macosx] NofocusListDblClickTest should wait between doublr clicks Reviewed-by: anthony, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java Changeset: 329011aad090 Author: kshefov Date: 2013-10-01 13:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/329011aad090 8012468: [TEST_BUG] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 0887aad989fb Author: kshefov Date: 2013-10-01 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0887aad989fb 8012466: [TEST_BUG] javax/swing/JInternalFrame/Test6505027.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/JInternalFrame/Test6505027.java Changeset: 1043bd1f7fca Author: kshefov Date: 2013-10-01 13:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1043bd1f7fca 8004294: [TEST_BUG] javax/swing/JSpinner/4973721/bug4973721.java failed on win2003 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSpinner/4973721/bug4973721.java Changeset: 68157255f3eb Author: kshefov Date: 2013-10-01 13:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68157255f3eb 8012461: [TEST_BUG] closed/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.xml Changeset: 172405287fde Author: kshefov Date: 2013-10-01 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/172405287fde 7133545: [macosx] closed/javax/swing/JSplitPane/4514858/bug4514858.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4514858/bug4514858.java Changeset: 291e66f4cb83 Author: kshefov Date: 2013-10-01 13:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/291e66f4cb83 7133532: [macosx] closed/javax/swing/JScrollBar/bug4202954/bug4202954.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JScrollBar/bug4202954/bug4202954.java Changeset: 560ede42bd2e Author: kshefov Date: 2013-10-01 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/560ede42bd2e 8025707: Frogot to add a file to fix for JDK-8012461 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/red.gif Changeset: a0c28e64c049 Author: alitvinov Date: 2013-10-01 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0c28e64c049 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Reviewed-by: anthony, serb Contributed-by: anton.nashatyrev at oracle.com ! src/macosx/lib/flavormap.properties Changeset: 5e205645d990 Author: pchelko Date: 2013-10-02 11:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e205645d990 7124363: [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1189f954d52f Author: pchelko Date: 2013-10-02 11:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1189f954d52f 8024163: [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/native/sun/awt/CDropTarget.m + test/java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java + test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java Changeset: 01198c681710 Author: pchelko Date: 2013-10-02 11:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01198c681710 8024600: [macosx] code prevents use of -Xlint:auxiliaryclass,empty in jdk build Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java + src/macosx/classes/com/apple/eawt/_OpenAppHandler.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java + src/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java Changeset: 287e0a7731ff Author: pchelko Date: 2013-10-02 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/287e0a7731ff 8024158: [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 244f2ee51f31 Author: leonidr Date: 2013-10-02 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/244f2ee51f31 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java Changeset: f40f2421c60f Author: serb Date: 2013-10-02 21:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f40f2421c60f 8013563: Memory leak in JFrame on Linux Reviewed-by: anthony, art ! src/share/classes/java/awt/Window.java + test/java/awt/Window/WindowsLeak/WindowsLeak.java Changeset: 1da5d306e84b Author: cl Date: 2013-10-02 11:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da5d306e84b 8025409: Fix javadoc comments errors and warning reported by doclint report Reviewed-by: anthony, yan ! 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/Color.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.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/List.java ! src/share/classes/java/awt/MenuBar.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/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/attribute/standard/Finishings.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/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 998578a87c0e Author: bagiras Date: 2013-10-03 16:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/998578a87c0e 8013553: [macosx] java.awt.FileDialog removes file extensions Reviewed-by: leonidr, serb ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 1533a379deb0 Author: anthony Date: 2013-10-03 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1533a379deb0 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Summary: Load the lwawt native library on Mac regardless of the headless/headful mode. Also, some minor cleanup. Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 39b674405270 Author: alexsch Date: 2013-10-03 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b674405270 7092283: Property Window.locationByPlatform is not cleared by calling setVisible(false) Reviewed-by: anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/LocationByPlatform/LocationByPlatformTest.java Changeset: 6ffe50fe06bd Author: mcherkas Date: 2013-10-04 20:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ffe50fe06bd 8020688: Broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. Reviewed-by: anthony, alexsch ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentEvent.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/FocusEvent.java ! src/share/classes/java/awt/event/FocusListener.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/WindowAdapter.java ! src/share/classes/java/awt/event/WindowEvent.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/swing/AbstractButton.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/ButtonGroup.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/ImageIcon.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/JComponent.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/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.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/JPopupMenu.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/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/JWindow.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.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/SwingWorker.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/Border.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/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/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.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/sun/swing/PrintingStatus.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java Changeset: 01b40315f872 Author: alexsch Date: 2013-10-07 16:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b40315f872 8025438: [macosx] right JNFCall* method should be used in JDK-8008728 fix Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 72afa269fa3b Author: alexsch Date: 2013-10-07 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72afa269fa3b 8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java Changeset: 546c0ebfbf56 Author: cl Date: 2013-10-07 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/546c0ebfbf56 8025840: Fix all the doclint warnings about trademark Reviewed-by: art ! 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/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.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/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/ImageIcon.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/JComponent.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/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/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/JPopupMenu.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/OverlayLayout.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.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/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.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/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! 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/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameEvent.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/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.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/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.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/BasicEditorPaneUI.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/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.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/ComboPopup.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.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/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.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/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.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/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/TableColumn.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/BadLocationException.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/DefaultStyledDocument.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/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/html/Option.java ! 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/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: bdc8abbce9c1 Author: yan Date: 2013-10-08 13:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdc8abbce9c1 8025236: [javadoc] fix some errors in AWT Reviewed-by: yan, anthony Contributed-by: Dmitry Ginzburg ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/awt/im/InputMethodHighlight.java Changeset: 01022f461570 Author: pchelko Date: 2013-10-08 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01022f461570 7158311: GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux 8001463: Regression : Deadlock between AWT-XAWT thread and AWT-EventQueue-0 Thread when screen resolution changes Reviewed-by: art, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a5d0730342a5 Author: pchelko Date: 2013-10-08 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5d0730342a5 8025585: Win: Popups in JFXPanel do not receive MouseWheel events Reviewed-by: anthony, art ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 85a72bb00d74 Author: bagiras Date: 2013-10-08 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85a72bb00d74 8000425: FileDialog documentation should be enhanced Reviewed-by: serb, anthony ! src/share/classes/java/awt/FileDialog.java Changeset: 01607de6265d Author: bagiras Date: 2013-10-08 16:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01607de6265d 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java Changeset: 184b16f4e61f Author: bagiras Date: 2013-10-08 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184b16f4e61f 7199196: Incremental transfer is broken because of a typo Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 42d3ea1c35b4 Author: malenkov Date: 2013-10-08 18:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42d3ea1c35b4 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 6914b883c3bb Author: malenkov Date: 2013-10-08 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6914b883c3bb 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Reviewed-by: art, anthony ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: a2dd2b411723 Author: alexsch Date: 2013-10-08 18:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2dd2b411723 7081594: Windows owned by an always-on-top window DO NOT automatically become always-on-top Reviewed-by: art, anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java Changeset: 0c06c38dfc3e Author: serb Date: 2013-10-08 21:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c06c38dfc3e 8022119: test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Reviewed-by: art, anthony ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: b218a14bdc8a Author: serb Date: 2013-10-08 23:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b218a14bdc8a 8025603: Unused methods in the awt text peers should be removed Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/windows/classes/sun/awt/windows/WButtonPeer.java ! src/windows/classes/sun/awt/windows/WCheckboxPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLabelPeer.java ! src/windows/classes/sun/awt/windows/WListPeer.java ! src/windows/classes/sun/awt/windows/WScrollbarPeer.java ! src/windows/classes/sun/awt/windows/WTextAreaPeer.java ! src/windows/classes/sun/awt/windows/WTextComponentPeer.java ! src/windows/classes/sun/awt/windows/WTextFieldPeer.java ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: e591ac19174f Author: leonidr Date: 2013-10-09 01:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e591ac19174f 8004050: [macosx] The 'ESC' key does not work with jdk8 Reviewed-by: alexsch, serb ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java Changeset: c1ef9ebac26a Author: lana Date: 2013-10-08 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1ef9ebac26a Merge ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: 748207aa9620 Author: lana Date: 2013-10-08 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/748207aa9620 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 575d4bc3bcae Author: lana Date: 2013-10-11 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/575d4bc3bcae Merge ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 96644227daed Author: lana Date: 2013-10-11 23:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96644227daed Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk Changeset: 3a5c987ff3a0 Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a5c987ff3a0 Merge From jan.lahoda at oracle.com Mon Oct 14 20:14:03 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 14 Oct 2013 20:14:03 +0000 Subject: hg: jdk8/tl/langtools: 8014016: javac is too late detecting invalid annotation usage Message-ID: <20131014201425.D6D7E6239E@hg.openjdk.java.net> Changeset: 87b5bfef7edb Author: jlahoda Date: 2013-10-14 22:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87b5bfef7edb 8014016: javac is too late detecting invalid annotation usage Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter Reviewed-by: jjg, emc, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Processor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Source.java From chris.hegarty at oracle.com Mon Oct 14 20:56:12 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Oct 2013 21:56:12 +0100 Subject: RFR: 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException In-Reply-To: <525C4E16.8000708@oracle.com> References: <525C4E16.8000708@oracle.com> Message-ID: > On 14 Oct 2013, at 21:03, Henry Jen wrote: > > Hi, > > Please review a quick one line fix for the test, we simply > "pass"(ignore) the test instead of "skip" the test. > > Ignore the test is the intention. It would be ideal if we know it's > "skipped" intentionally, but currently jtreg consider a skipped test > with a throwable failed test for other scenarios, which certainly can be > reviewed separately. > This is in line with what we do for other tests, where the platform or system cannot run the test. A, somewhat, limitation of jtreg, but ok. > In the mean time, we should get rid of this noise. > > Cheers, > Henry > > http://cr.openjdk.java.net/~henryjen/tl/8026362/0/webrev/ Thanks Henry, reviewed. -Chris. From michael.x.mcmahon at oracle.com Mon Oct 14 21:10:22 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 14 Oct 2013 21:10:22 +0000 Subject: hg: jdk8/tl/jdk: 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Message-ID: <20131014211103.07C21623A0@hg.openjdk.java.net> Changeset: dd0deeb04933 Author: michaelm Date: 2013-10-14 22:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd0deeb04933 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Reviewed-by: alanb, chegar + src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/HttpURLConnection.java - src/share/classes/java/net/HttpURLPermission.java + src/share/classes/java/net/URLPermission.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 + test/java/net/URLPermission/URLPermissionTest.java + test/java/net/URLPermission/URLTest.java + test/java/net/URLPermission/policy.1 + test/java/net/URLPermission/policy.2 + test/java/net/URLPermission/policy.3 From brian.burkhalter at oracle.com Tue Oct 15 00:27:25 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 14 Oct 2013 17:27:25 -0700 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> Message-ID: <0A722FED-1A87-4E68-B500-1F69034F0767@oracle.com> Ping! This proposal could use more comments, not to mention review(s). http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html Thanks, Brian On Oct 3, 2013, at 5:58 PM, Brian Burkhalter wrote: > I have reviewed this proposed change a couple of times in its current form and it looks good to me. > > It would be good to see some comments about the general concept from BigInt cognoscenti, and from (a) Reviewer(s) as concerns the @implNote addition as well as the new ArithmeticExceptions added at several points in the javadoc. From henry.jen at oracle.com Tue Oct 15 00:28:00 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 15 Oct 2013 00:28:00 +0000 Subject: hg: jdk8/tl/jdk: 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Message-ID: <20131015002828.C515B623B2@hg.openjdk.java.net> Changeset: 94d4aa2fb414 Author: henryjen Date: 2013-10-14 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94d4aa2fb414 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Reviewed-by: chegar ! test/java/lang/invoke/lambda/LogGeneratedClassesTest.java From mandy.chung at oracle.com Tue Oct 15 03:38:11 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Oct 2013 20:38:11 -0700 Subject: Review request for jdeps option rename to Java-style and enhancements to output dot file format In-Reply-To: <525B030C.6000704@oracle.com> References: <5257A3E2.6050305@oracle.com> <525B030C.6000704@oracle.com> Message-ID: <525CB8A3.9070906@oracle.com> Alan, Thanks for the review. Here is the updated webrev per your feedback: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.01/ I have also fixed jdk/test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java due to the change of ClassFileReader.newInstance method. More comments inlined below. On 10/13/2013 1:31 PM, Alan Bateman wrote: > Command line options are somewhat subjective, I think what you have is > reasonable. I thought the GNU style that were in the original version > were okay too (just takes getting used to) but keeping them consistent > with similarly named options in the other tools is important tool. One > change that I didn't quite understand is dropping -R for recursive, > that one seemed intuitive (to me). > Initially I considered that -recursive is a less frequently used option as typically we would be interested in the immediate dependencies. I also think that -R is an intuitive short option to -recursive and there shouldn't be an issue when it's upgraded to gnu-style in the future and so I add it back. > Anyway, on the changes then I went through the webrev and I didn't see > anything obviously wrong. A few comments: > > - In PlatformClassPath then alt-rt is special-cased and I think that > can be removed now. > That's right (thanks for reminding it). I have removed it. > - Also in PlatformClassPath is special handling of jfxrt.jar (if it is > present) isn't clear. I recall this came up before and maybe it just > needs a more detailed comment to explain why it is needed. > PlatformClassPath.contains method seems to be a bit confusing. I added a new JDKArchive class that will be instantiated for JDK jar file > - In Analyzer then I think I missed why the results are a > LinkedHashMap, wouldn't HashMap do? > It doesn't need to be ordered and I have changed it to HashMap. That was a left-over change I made in an earlier version of this fix. JdepsTask already maintains an ordered list of archives (sourceLocations). > - A minor comment in JdepsTask but I assume the OutputWriter interface > can be private > OutputWriter was in an earlier version but was removed. It's not in webrev.00 and perhaps you were looking at an earlier version? Mandy From mandy.chung at oracle.com Tue Oct 15 03:48:01 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Oct 2013 20:48:01 -0700 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525C327C.9010400@oracle.com> References: <525C327C.9010400@oracle.com> Message-ID: <525CBAF1.2010405@oracle.com> On 10/14/2013 11:05 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8026404: Logging in Applet can trigger ACE: > access denied ("java.lang.RuntimePermission" > "modifyThreadGroup") > > In some circumstances the call to JavaAWTAccess.getAppletContext() > will trigger a call to ecx.threadGroup.getParent() == null > The trouble is that this call will require a "modifyThreadGroup" > permission if it happens that ecx.threadGroup.getParent() is > the root thread group. > > The fix for that is simple - the call to > ecx.threadGroup.getParent() == null > needs to be done within a doPrivileged: > > > The change looks okay to me. Mandy From masayoshi.okutsu at oracle.com Tue Oct 15 04:31:54 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 15 Oct 2013 13:31:54 +0900 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <525BBB02.9060805@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> <525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com> Message-ID: <525CC53A.6020809@oracle.com> Hi Aleksej and Michael, TimeZoneNames_de.java: - String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST", + String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST", Is this change correct? BTW, is there any reason to change lower case to upper case for the \uxxxx notation? Thanks, Masayoshi On 10/14/2013 6:36 PM, Aleksej Efimov wrote: > Hi, > The second item is dropped - I was informed in a parallel review > thread, that I can have one approval from a Reviewer and another > approval[s] from members. > The hg patch was updated and located here: > http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch > > > Can I ask for a sponsor help to push this fix? > > Thank you and Best Regards, > Aleksej > > On 10/13/2013 02:23 PM, Aleksej Efimov wrote: >> Michael, Masayoshi, >> >> Looks like, we can commit this changes with following items in mind: >> 1. Generic names in TimeZoneNames_*.java should be added as part of >> JDK-8025051 resolution. >> 2. I need another one approval from a JDK 8 reviewer for this one. >> >> Anyway, the hg changeset patch can be found here: >> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch >> >> Best Regards, >> Aleksej >> >> On 10/12/2013 12:43 AM, Michael Fang wrote: >>> Hi Aleksej, >>> >>> Yes, you are right. They can be handled separately. Thanks! >>> >>> Regards, >>> >>> Michael >>> Sent from my iPhone >>> >>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: >>> >>>> Hi Michael, >>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. >>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? >>>> >>>> Thanks and Best Regards, >>>> Aleksej >>>> >>>> On 11.10.2013 21:41, Michael Fang wrote: >>>>> Hi Aleksej, >>>>> >>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >>>>> >>>>> I think we can file a separate bug to track that issue. >>>>> >>>>> thanks, >>>>> >>>>> -michael >>>>> >>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>>>>> Hi Aleksej, >>>>>> >>>>>> Here are my review comments. >>>>>> >>>>>> - The copyright header of the data files shouldn't be removed. >>>>>> >>>>>> - TimeZoneNames.java: >>>>>> >>>>>> - "Middle Europe Time", "MET"}}, >>>>>> + "MET", "MET"}}, >>>>>> >>>>>> I don't think the long name should be changed. >>>>>> >>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>>>>> >>>>>>> The brief list of changes: >>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>>>>> 2. a) Updates to long time zone names >>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>>>>> c) Removed unused ACT[] array >>>>>>> d) Added "Europe/Busingen" time zone name >>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>>>>> >>>>>>> The following tests were executed on JDK 8 with fix: >>>>>>> test/java/util/TimeZone >>>>>>> test/java/util/Calendar >>>>>>> test/java/util/Formatter >>>>>>> test/sun/util/calendar >>>>>>> test/java/time >>>>>>> >>>>>>> Testing result: All test passed >>>>>>> >>>>>>> Thanks! >>>>>>> Aleksej >>>>>>> >>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ > From jonathan.gibbons at oracle.com Tue Oct 15 04:52:03 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 04:52:03 +0000 Subject: hg: jdk8/tl/langtools: 8026371: "tidy" issues in langtools/src/**/*.html files Message-ID: <20131015045206.996DF623C5@hg.openjdk.java.net> Changeset: b9e3b55a908c Author: jjg Date: 2013-10-14 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b9e3b55a908c 8026371: "tidy" issues in langtools/src/**/*.html files Reviewed-by: darcy + src/share/classes/com/sun/javadoc/package-info.java - src/share/classes/com/sun/javadoc/package.html + src/share/classes/com/sun/tools/classfile/package-info.java - src/share/classes/com/sun/tools/classfile/package.html + src/share/classes/com/sun/tools/doclets/formats/html/markup/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html + src/share/classes/com/sun/tools/doclets/formats/html/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html + src/share/classes/com/sun/tools/doclets/package-info.java - src/share/classes/com/sun/tools/doclets/package.html + src/share/classes/com/sun/tools/javap/package-info.java - src/share/classes/com/sun/tools/javap/package.html ! src/share/classes/javax/lang/model/overview.html ! src/share/classes/javax/tools/overview.html From david.holmes at oracle.com Tue Oct 15 05:02:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 15:02:37 +1000 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups Message-ID: <525CCC6D.3020309@oracle.com> http://cr.openjdk.java.net/~dholmes/8026378/webrev/ Trivial cleanup: Non-existent java/util/SummaryStatistics deleted from group jdk_stream Non-existent com/oracle/security deleted from jdk_security3 java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to needs_jre jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 java/util/Collection/ListDefaults.java renamed to java/util/List/ListDefaults.java Thanks, David From huizhe.wang at oracle.com Tue Oct 15 05:08:13 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 15 Oct 2013 05:08:13 +0000 Subject: hg: jdk8/tl/jaxp: 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Message-ID: <20131015050818.7D767623C8@hg.openjdk.java.net> Changeset: eb169222d3f2 Author: joehw Date: 2013-10-14 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eb169222d3f2 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java From michael.fang at oracle.com Tue Oct 15 05:19:10 2013 From: michael.fang at oracle.com (Michael Fang) Date: Mon, 14 Oct 2013 22:19:10 -0700 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <525CC53A.6020809@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> <525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com> <525CC53A.6020809@oracle.com> Message-ID: <525CD04E.60003@oracle.com> Hi Masayoshi, I am not sure if the changes are correct. I need to check with translation team for confirmation. There are several other similar cases. About the upper casing, it's the way Oracle translation team returns their translation. Nothing we can do about it. I think it's a way for them to know if anyone else has changed the translation without their knowledge. Translation changes has to be done on their translation memory by them instead of manually editing the resource files. Otherwise, the next time they deliver l10n resource files back, the manually changes will not be there. thanks, -michael On 13?10?14? 09:31 ??, Masayoshi Okutsu wrote: > Hi Aleksej and Michael, > > TimeZoneNames_de.java: > - String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST", > + String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST", > Is this change correct? > > BTW, is there any reason to change lower case to upper case for the > \uxxxx notation? > > Thanks, > Masayoshi > > On 10/14/2013 6:36 PM, Aleksej Efimov wrote: >> Hi, >> The second item is dropped - I was informed in a parallel review >> thread, that I can have one approval from a Reviewer and another >> approval[s] from members. >> The hg patch was updated and located here: >> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch >> >> >> Can I ask for a sponsor help to push this fix? >> >> Thank you and Best Regards, >> Aleksej >> >> On 10/13/2013 02:23 PM, Aleksej Efimov wrote: >>> Michael, Masayoshi, >>> >>> Looks like, we can commit this changes with following items in mind: >>> 1. Generic names in TimeZoneNames_*.java should be added as part of >>> JDK-8025051 resolution. >>> 2. I need another one approval from a JDK 8 reviewer for this one. >>> >>> Anyway, the hg changeset patch can be found here: >>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch >>> >>> Best Regards, >>> Aleksej >>> >>> On 10/12/2013 12:43 AM, Michael Fang wrote: >>>> Hi Aleksej, >>>> >>>> Yes, you are right. They can be handled separately. Thanks! >>>> >>>> Regards, >>>> >>>> Michael >>>> Sent from my iPhone >>>> >>>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: >>>> >>>>> Hi Michael, >>>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. >>>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? >>>>> >>>>> Thanks and Best Regards, >>>>> Aleksej >>>>> >>>>> On 11.10.2013 21:41, Michael Fang wrote: >>>>>> Hi Aleksej, >>>>>> >>>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >>>>>> >>>>>> I think we can file a separate bug to track that issue. >>>>>> >>>>>> thanks, >>>>>> >>>>>> -michael >>>>>> >>>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>>>>>> Hi Aleksej, >>>>>>> >>>>>>> Here are my review comments. >>>>>>> >>>>>>> - The copyright header of the data files shouldn't be removed. >>>>>>> >>>>>>> - TimeZoneNames.java: >>>>>>> >>>>>>> - "Middle Europe Time", "MET"}}, >>>>>>> + "MET", "MET"}}, >>>>>>> >>>>>>> I don't think the long name should be changed. >>>>>>> >>>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>>>>>> >>>>>>>> The brief list of changes: >>>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>>>>>> 2. a) Updates to long time zone names >>>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>>>>>> c) Removed unused ACT[] array >>>>>>>> d) Added "Europe/Busingen" time zone name >>>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>>>>>> >>>>>>>> The following tests were executed on JDK 8 with fix: >>>>>>>> test/java/util/TimeZone >>>>>>>> test/java/util/Calendar >>>>>>>> test/java/util/Formatter >>>>>>>> test/sun/util/calendar >>>>>>>> test/java/time >>>>>>>> >>>>>>>> Testing result: All test passed >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Aleksej >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >> > From david.holmes at oracle.com Tue Oct 15 05:28:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 15:28:49 +1000 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CCC6D.3020309@oracle.com> References: <525CCC6D.3020309@oracle.com> Message-ID: <525CD291.3010607@oracle.com> Correction ... On 15/10/2013 3:02 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8026378/webrev/ > > Trivial cleanup: > > Non-existent java/util/SummaryStatistics deleted from group jdk_stream > > Non-existent com/oracle/security deleted from jdk_security3 > > java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to > needs_jre > > jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 This has to stay in needs_jdk as it is testing the compiler output from the JDK under test. Webrev updated in place. David ----- > java/util/Collection/ListDefaults.java renamed to > java/util/List/ListDefaults.java > > Thanks, > David From huizhe.wang at oracle.com Tue Oct 15 05:28:24 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 15 Oct 2013 05:28:24 +0000 Subject: hg: jdk8/tl/jdk: 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Message-ID: <20131015052905.CC8A9623CA@hg.openjdk.java.net> Changeset: 50e88f25255f Author: joehw Date: 2013-10-14 22:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50e88f25255f 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb + test/javax/xml/jaxp/validation/8015092/XPathWhiteSpaceTest.java + test/javax/xml/jaxp/validation/8015092/idIxpns.xsd + test/javax/xml/jaxp/validation/8015092/idIxpns1.xsd + test/javax/xml/jaxp/validation/8015092/idJ029.xsd + test/javax/xml/jaxp/validation/8015092/idJimp.xsd From mandy.chung at oracle.com Tue Oct 15 05:34:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Oct 2013 22:34:24 -0700 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CCC6D.3020309@oracle.com> References: <525CCC6D.3020309@oracle.com> Message-ID: <525CD3E0.8060005@oracle.com> On 10/14/2013 10:02 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8026378/webrev/ > Looks okay with one question: > [..] > java/util/Collection/ListDefaults.java renamed to > java/util/List/ListDefaults.java > I skimmed on this test and it's not obvious to me - what compact2 API does this test use? Mandy From jonathan.gibbons at oracle.com Tue Oct 15 05:36:29 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 05:36:29 +0000 Subject: hg: jdk8/tl/langtools: 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Message-ID: <20131015053632.19853623CB@hg.openjdk.java.net> Changeset: 7d266a2b31b2 Author: jjg Date: 2013-10-14 22:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d266a2b31b2 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javadoc/8025693/Test.java From david.holmes at oracle.com Tue Oct 15 06:03:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 16:03:56 +1000 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CD3E0.8060005@oracle.com> References: <525CCC6D.3020309@oracle.com> <525CD3E0.8060005@oracle.com> Message-ID: <525CDACC.2000709@oracle.com> Hi Mandy, On 15/10/2013 3:34 PM, Mandy Chung wrote: > > On 10/14/2013 10:02 PM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/8026378/webrev/ >> > Looks okay with one question: > >> [..] >> java/util/Collection/ListDefaults.java renamed to >> java/util/List/ListDefaults.java >> > > I skimmed on this test and it's not obvious to me - what compact2 API > does this test use? It uses testng which in turn requires compact2 because its use of sax/xml Thanks for the Review! David ----- > Mandy > From jonathan.gibbons at oracle.com Tue Oct 15 06:09:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 06:09:05 +0000 Subject: hg: jdk8/tl/langtools: 8025998: Missing LV table in lambda bodies Message-ID: <20131015060908.D2808623CC@hg.openjdk.java.net> Changeset: 09a414673570 Author: jjg Date: 2013-10-14 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09a414673570 8025998: Missing LV table in lambda bodies Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java From mandy.chung at oracle.com Tue Oct 15 06:12:42 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Oct 2013 23:12:42 -0700 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CDACC.2000709@oracle.com> References: <525CCC6D.3020309@oracle.com> <525CD3E0.8060005@oracle.com> <525CDACC.2000709@oracle.com> Message-ID: <525CDCDA.5060208@oracle.com> On 10/14/2013 11:03 PM, David Holmes wrote: > It uses testng which in turn requires compact2 because its use of sax/xml > Oh that's right. I missed that is a TestNG test. thanks Mandy From martinrb at google.com Tue Oct 15 06:29:43 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Oct 2013 23:29:43 -0700 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: <525C1602.8090200@oracle.com> References: <52585560.6080904@oracle.com> <525BBB35.4030701@oracle.com> <2C2F4AD7-EC2F-4E01-BD5D-F3627D5207C8@oracle.com> <525C1602.8090200@oracle.com> Message-ID: Hi I'm the author of this code. I'm perfectly willing to believe the close/drain code is buggy. It is difficult to get right. I'm looking forward to the updated webrev. Often the best way to handle a stress test is to make it run quickly by default, but provide a system property to make it run as long as desired, for manual ad-hoc testing. On Mon, Oct 14, 2013 at 9:04 AM, Ivan Gerasimov wrote: > Thanks Paul! > > Yes, I like your solution better. > I'll test it and send the updated webrev shortly. > > Sincerely yours, > Ivan > > > > On 14.10.2013 15:33, Paul Sandoz wrote: > >> On Oct 14, 2013, at 11:36 AM, Ivan Gerasimov >> wrote: >> >> Hi Paul, >>> >>> Thank you for looking at the webrev! >>> >>> On 14.10.2013 12:50, Paul Sandoz wrote: >>> >>>> Hi Ivan, >>>> >>>> Why do you require closeLock? is it not sufficient leave processExited >>>> as is and just add: >>>> >>>> public synchronized void close() throws IOException { >>>> super.close(); >>>> } >>>> >>> I want to limit the impact on the code, that's why I synchronize close() >>> with only processExited(). >>> If I made close() synchronized with all the stream's methods, then I >>> think it could introduce some unpredictable drawback. >>> >>> Yeah, the close will block until the drain is complete, which might >> also have some unpredictable drawback. >> >> A concern is there was already some code in place to check for async >> close, which if detected throws away all the data and sets the underlying >> filtered input stream is set to null. So all that effort draining is wasted. >> >> Another solution is to keep checking in the loop of drainInputStream for >> an async close and fail-fast: >> >> private InputStream drainInputStream(InputStream in) >> throws IOException { >> int n = 0; >> int j; >> byte[] a = null; >> while ((j = in.available()) > 0) { >> if (buf == null) // asynchronous close()? >> return null; // stop reading and discard >> a = (a == null) ? new byte[j] : Arrays.copyOf(a, n + j); >> n += in.read(a, n, j); >> } >> >> if (buf == null) // asynchronous close()? >> return null; // discard >> else if (a == null) >> return ProcessBuilder.**NullInputStream.INSTANCE; >> else >> return ByteArrayInputStream(n == a.length ? a : >> Arrays.copyOf(a, n)); >> } >> >> /** Called by the process reaper thread when the process exits. >> */ >> synchronized void processExited() { >> // Most BufferedInputStream methods are synchronized, but >> close() >> // is not, and so we have to handle concurrent racing >> close(). >> try { >> InputStream in = this.in; >> if (in != null) { >> InputStream stragglers = drainInputStream(in); >> in.close(); >> this.in = stragglers; >> } >> } catch (IOException ignored) { >> // probably an asynchronous close(). >> } >> } >> >> This still has the potential to look at the availability of the current >> input before async closing, and read from a different input after async >> closing, but it will break out on the next loop check if there are more >> bytes available to read otherwise it will be caught again on the final >> check, so no munged data will be exposed. >> >> >> >> Plus there was already some logic checking if close was asynchronously >>>> called (see BufferedInputStream.close): >>>> >>>> 372 if (buf == null) // asynchronous close()? >>>> 373 this.in = null; >>>> >>>> and this would no longer be required >>>> >>> Yes, you're right and these two lines can be removed. >>> I wouldn't remove the surrounding try {} catch (IOException) though, as >>> the stream can still be closed asynchronously. >>> >>> I am somewhat struggling to understand the test (not too familiar with >>>> this area). Requires a more expert eye in this area than I. >>>> >>>> IIUC you are trying to induce the the output process fd of ExecLoop to >>>> "flip" to another fd opened by OpenLoop. >>>> >>> Yes. >>> I actually adopted a testcase provided by the reporter of the problem. >>> I only changed the test in such a way that it can be run in an automated >>> mode. >>> >>> Below is the exact comment from the original testcase. >>> It may be a good idea to include it in the regtest. >>> >>> /* Following code is a test case that demonstrates a close race in >>> ProcessPipeInputStream. >>> *. >>> * A snippet of the offending code within ProcessPipeInputStream:. >>> * // Called by the process reaper thread when the process exits.. >>> * synchronized void processExited() { >>> * // Most BufferedInputStream methods are synchronized, but >>> close() >>> * // is not, and so we have to handle concurrent racing >>> close(). >>> * try { >>> * InputStream in = this.in; >>> * if (in != null) { >>> * byte[] stragglers = drainInputStream(in); >>> * in.close(); >>> * >>> * The comment even talks about the race. However, the code is not >>> adequately >>> * protecting against it. drainInputStream() (available() in particular) >>> is not >>> * threadsafe when a close happens in parallel. What's worse is that a >>> subsequent >>> * open() is likely to reassign the closed fd so drainInputStream ends up >>> draining >>> * the wrong fd! This can cause OOMs, data corruption on other fds, and >>> other very >>> * bad things. >>> *. >>> * Notes:. >>> * - Test creates a large sparse file in /tmp/bigsparsefile >>> * - Test uses "/proc/meminfo" for simple input.. >>> * - Invoke using "-Xmx128m" to insure file size of 1G is greater than >>> heap size >>> * - Test will run forever, if successful there will not be any OOM >>> exceptions >>> * (on my test system they occur about 1 per minute) >>> * - You need multiple cores (I use 2 x Xeon E5620 = 8 cores, 16 >>> threads). >>> *.. >>> * The basic premise of the test is to create a 1GB sparse file. Then >>> have lots >>> * of threads opening and closing this file. In a loop within a separate >>> thread use UNIXprocess >>> * to run a simple command. We read the output of the command, make sure >>> the process >>> * has exited and then close the inputstream. When the bug happens, >>> processExited() >>> * will use FIONREAD to figure out how much data to drain BUT the fd it >>> is checking >>> * will be closed and reopened (now referring to /tmp/bigsparsefile) so >>> it will >>> * see the size as 1GB and then attempt to allocate a buffer of that size >>> and. >>> * then OOM.. >>> */ >>> >>> >>> >>> The test concerns me since it is gonna use up loads of resources and >>>> proceed for 10 minutes until deciding beyond reasonable doubt that there is >>>> no issue. >>>> >>> When I ran the test across different machines (with the unpatched jdk) >>> it reported from one to five races during 10 minutes. >>> We can surely decrease the timeout for the price of higher probability >>> of a false positive result. >>> >>> Unit-like tests should really run in under a minute, plus should >> ideally be frugal in their resource consumption otherwise it could starve >> other tests running in parallel. If we cannot create a more deterministic >> test (not sure it is possible) then perhaps this test belongs to SQE and >> not in the JDK tests? >> >> Paul. >> > > From david.holmes at oracle.com Tue Oct 15 07:38:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 17:38:30 +1000 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525C43B2.6000007@oracle.com> References: <525C43B2.6000007@oracle.com> Message-ID: <525CF0F6.9090904@oracle.com> On 15/10/2013 5:19 AM, Daniel Fuchs wrote: > Adding awt-dev... > >> The change looks okay to me but I would suggest sending to awt-dev so >> that the folks that maintain this area know about it. >> >> On the test then does initializing SunToolkit cause AWT to be >> initialized? I just wonder if this test will run headless. >> >> -Alan. > > > Hi, > > Please find below a fix for: > > 8026404: Logging in Applet can trigger ACE: > access denied ("java.lang.RuntimePermission" > "modifyThreadGroup") > > In some circumstances the call to JavaAWTAccess.getAppletContext() > will trigger a call to ecx.threadGroup.getParent() == null > The trouble is that this call will require a "modifyThreadGroup" > permission if it happens that ecx.threadGroup.getParent() is > the root thread group. > > The fix for that is simple - the call to > ecx.threadGroup.getParent() == null > needs to be done within a doPrivileged: Doesn't the absence of the permission indicate that this can't be the mainAppContext? Just wondering if catching the security exception was an alternative - not that I see any issue with the doPrivileged in this case. > > > The reg test fails without the fix and passes with it. Test nit: while(rootTG <- need a space after while Thanks for keeping TEST.groups up to date! David > best regards, > > -- daniel From Alan.Bateman at oracle.com Tue Oct 15 08:00:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 09:00:40 +0100 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CDACC.2000709@oracle.com> References: <525CCC6D.3020309@oracle.com> <525CD3E0.8060005@oracle.com> <525CDACC.2000709@oracle.com> Message-ID: <525CF628.5010304@oracle.com> On 15/10/2013 07:03, David Holmes wrote: > > It uses testng which in turn requires compact2 because its use of sax/xml Right, we need to figure out a solution for that as more and more TestNG tests are added. Anyway, the changes in the webrev look okay to me too. I suspect that com/oracle/security in jdk_security3 was a mistake in the original group definitions, apologies about that. For the needs_* groups then the changes are just a reminder that this will require regularly gardening to keep down the weeds, we need to continue to look for an alternative solution. -Alan From paul.sandoz at oracle.com Tue Oct 15 08:20:32 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Oct 2013 10:20:32 +0200 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: <0A722FED-1A87-4E68-B500-1F69034F0767@oracle.com> References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> <0A722FED-1A87-4E68-B500-1F69034F0767@oracle.com> Message-ID: Hi, I took a look at the patch, but i am not an expert in this area. On BigInteger: 99 * @implNote 100 * BigInteger constructors and operations throw {@code ArithmeticException} when 101 * the result is out of the supported range. The supported range in JDK 8 is 102 * -2{@code Integer.MAX_VALUE} to 103 * 2{@code Integer.MAX_VALUE}, exclusive. I suggest changing to: @implNote BigInteger constructors and operations throw {@code ArithmeticException} when the result is out of the supported range of -2{@code Integer.MAX_VALUE} (exclusive) to 2{@code Integer.MAX_VALUE} (exclusive). I don't think it is worth declaring @throws ArithmeticException for all relevant constructors and operations. This is likely to be noise for most people and the implNote is sufficient. Paul. On Oct 15, 2013, at 2:27 AM, Brian Burkhalter wrote: > Ping! > > This proposal could use more comments, not to mention review(s). > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html > > Thanks, > > Brian > > On Oct 3, 2013, at 5:58 PM, Brian Burkhalter wrote: > >> I have reviewed this proposed change a couple of times in its current form and it looks good to me. >> >> It would be good to see some comments about the general concept from BigInt cognoscenti, and from (a) Reviewer(s) as concerns the @implNote addition as well as the new ArithmeticExceptions added at several points in the javadoc. > From daniel.fuchs at oracle.com Tue Oct 15 08:55:32 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Oct 2013 10:55:32 +0200 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525CF0F6.9090904@oracle.com> References: <525C43B2.6000007@oracle.com> <525CF0F6.9090904@oracle.com> Message-ID: <525D0304.5060305@oracle.com> Hi David, On 10/15/13 9:38 AM, David Holmes wrote: > On 15/10/2013 5:19 AM, Daniel Fuchs wrote: >> Adding awt-dev... >> >>> The change looks okay to me but I would suggest sending to awt-dev so >>> that the folks that maintain this area know about it. >>> >>> On the test then does initializing SunToolkit cause AWT to be >>> initialized? I just wonder if this test will run headless. >>> >>> -Alan. >> >> >> Hi, >> >> Please find below a fix for: >> >> 8026404: Logging in Applet can trigger ACE: >> access denied ("java.lang.RuntimePermission" >> "modifyThreadGroup") >> >> In some circumstances the call to JavaAWTAccess.getAppletContext() >> will trigger a call to ecx.threadGroup.getParent() == null >> The trouble is that this call will require a "modifyThreadGroup" >> permission if it happens that ecx.threadGroup.getParent() is >> the root thread group. >> >> The fix for that is simple - the call to >> ecx.threadGroup.getParent() == null >> needs to be done within a doPrivileged: > > Doesn't the absence of the permission indicate that this can't be the > mainAppContext? Just wondering if catching the security exception was an > alternative - not that I see any issue with the doPrivileged in this case. Well, yes and no. The exception will not be raised if there is only trusted code in the stack trace - so we can't really take that to ascertain whether this is the main app context. >> >> >> The reg test fails without the fix and passes with it. > > Test nit: while(rootTG <- need a space after while Thanks for spotting that. I will fix it before pushing! > Thanks for keeping TEST.groups up to date! I almost forgot ;-) -- daniel > > David > >> best regards, >> >> -- daniel From jaroslav.bachorik at oracle.com Tue Oct 15 08:37:15 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 15 Oct 2013 08:37:15 +0000 Subject: hg: jdk8/tl/jdk: 6804470: JvmstatCountersTest.java test times out on slower machines Message-ID: <20131015083748.D959C623D0@hg.openjdk.java.net> Changeset: abe8d432f714 Author: jbachorik Date: 2013-10-15 10:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abe8d432f714 6804470: JvmstatCountersTest.java test times out on slower machines Summary: Increasing the default timeout to cater for the slower machines Reviewed-by: alanb ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java From alan.bateman at oracle.com Tue Oct 15 09:57:40 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Oct 2013 09:57:40 +0000 Subject: hg: jdk8/tl/jdk: 8026398: Can't load jdk.Exported, ClassNotFoundException Message-ID: <20131015095854.93053623D7@hg.openjdk.java.net> Changeset: 0b6632e570b0 Author: alanb Date: 2013-10-15 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b6632e570b0 8026398: Can't load jdk.Exported, ClassNotFoundException Reviewed-by: chegar, mchung ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java From daniel.fuchs at oracle.com Tue Oct 15 11:02:03 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 15 Oct 2013 11:02:03 +0000 Subject: hg: jdk8/tl/jdk: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Message-ID: <20131015110224.D7D07623E3@hg.openjdk.java.net> Changeset: 2c16140fb515 Author: dfuchs Date: 2013-10-15 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c16140fb515 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() == null' can sometimes throw ACE and needs to be wrapped in doPrivileged. Reviewed-by: alanb, mchung, dholmes ! src/share/classes/sun/awt/AppContext.java ! test/TEST.groups + test/java/util/logging/TestMainAppContext.java From Alan.Bateman at oracle.com Tue Oct 15 13:14:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 14:14:30 +0100 Subject: Review request for jdeps option rename to Java-style and enhancements to output dot file format In-Reply-To: <525CB8A3.9070906@oracle.com> References: <5257A3E2.6050305@oracle.com> <525B030C.6000704@oracle.com> <525CB8A3.9070906@oracle.com> Message-ID: <525D3FB6.4090504@oracle.com> On 15/10/2013 04:38, Mandy Chung wrote: > Alan, > > Thanks for the review. Here is the updated webrev per your feedback: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.01/ > > I have also fixed > jdk/test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java due to > the change of ClassFileReader.newInstance method. I went through the updated webrev, thanks for the changes, I think it looks good now. -Alan. From Alan.Bateman at oracle.com Tue Oct 15 13:21:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 14:21:19 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <916787D6-258A-4DA3-A732-C79F8E210C46@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> <525BB220.1090100@oracle.com> <916787D6-258A-4DA3-A732-C79F8E210C46@oracle.com> Message-ID: <525D414F.1000904@oracle.com> On 14/10/2013 20:43, Brian Burkhalter wrote: > : > > Here's the patch updated for this option: > > http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ > > I think this is okay, the only concern is that the host name is no longer guaranteed to be in the exception detail (but for WSATRY_AGAIN then it might not matter because the problem is unlikely to be specific to the host name that is being looked up). -Alan. From jan.lahoda at oracle.com Tue Oct 15 14:24:33 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 15 Oct 2013 14:24:33 +0000 Subject: hg: jdk8/tl/langtools: 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Message-ID: <20131015142436.CBB89623EA@hg.openjdk.java.net> Changeset: 79649bf21a92 Author: jlahoda Date: 2013-10-15 16:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79649bf21a92 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java + test/tools/javac/tree/NoPrivateTypesExported.java From erik.joelsson at oracle.com Tue Oct 15 14:30:06 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Oct 2013 16:30:06 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Message-ID: <525D516E.6040703@oracle.com> Currently the RMI stubs in the jdk are built with the newly built rmic binary at the end of the build. This patch changes that and instead builds a bootstrap version of the rmic classes, much like bootstrap javac in langtools, which runs on the bootjdk, but generates classes for the new jdk. The new solution is more friendly to cross compilation. A few notes on the patch: * In src/share/classes/sun/tools/tree/Node.java, I had to change a call to a jdk8 only constructor in java.lang.InternalError. * The packages included when compiling rmic were just picked by extending for each missing class until the compilation succeeded. If someone knows of a crucial package or class that needs to be included, please say so. * I renamed a parameter to SetupJavaCompilation. I do not consider the parameter a hack anymore, but a necessary option for this case. * In RMICompilation, the dependency file is now a real touch file instead of a virtual one. This was needed for proper dependencies in GenerateClasses.gmk. * All of corba is compiled twice since I have no idea which parts would actually be needed. This doesn't add much build time since it can be run effectively in parallel with the rest of the corba build. * I put the compilation of bootstrap rmic in GenerateClasses.gmk directly instead of Tools.gmk. This was to not add much compile time, since Tools.gmk is included and therefore parsed a lot. Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ /Erik From Alan.Bateman at oracle.com Tue Oct 15 14:40:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 15:40:12 +0100 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D516E.6040703@oracle.com> References: <525D516E.6040703@oracle.com> Message-ID: <525D53CC.8030509@oracle.com> On 15/10/2013 15:30, Erik Joelsson wrote: > Currently the RMI stubs in the jdk are built with the newly built rmic > binary at the end of the build. This patch changes that and instead > builds a bootstrap version of the rmic classes, much like bootstrap > javac in langtools, which runs on the bootjdk, but generates classes > for the new jdk. The new solution is more friendly to cross compilation. > > A few notes on the patch: > > * In src/share/classes/sun/tools/tree/Node.java, I had to change a > call to a jdk8 only constructor in java.lang.InternalError. > * The packages included when compiling rmic were just picked by > extending for each missing class until the compilation succeeded. If > someone knows of a crucial package or class that needs to be included, > please say so. > * I renamed a parameter to SetupJavaCompilation. I do not consider the > parameter a hack anymore, but a necessary option for this case. > * In RMICompilation, the dependency file is now a real touch file > instead of a virtual one. This was needed for proper dependencies in > GenerateClasses.gmk. > * All of corba is compiled twice since I have no idea which parts > would actually be needed. This doesn't add much build time since it > can be run effectively in parallel with the rest of the corba build. > * I put the compilation of bootstrap rmic in GenerateClasses.gmk > directly instead of Tools.gmk. This was to not add much compile time, > since Tools.gmk is included and therefore parsed a lot. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 > Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ > > /Erik It's great to see a solution coming for this, it was always been troublesome to run the newly built rmic. So what are the implications of this? I assume it means that we need to be careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and restrict API usage to what is available in the boot JDK - is that right? -Alan. From paul.sandoz at oracle.com Tue Oct 15 14:55:18 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Oct 2013 16:55:18 +0200 Subject: Demo for Parallel Core Collection API In-Reply-To: References: <2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com> Message-ID: <72CCEDAE-77C2-43DB-81DE-D498B7B14C80@oracle.com> On Oct 15, 2013, at 4:20 PM, Tristan Yan wrote: > Thank you Paul > > There is one minor question, I can't compile one of your code, then I realized that's because grouping by signature is public static > Collector> groupingBy(Function classifier, Collector downstream) > > Which makes me wonder why we need type A here, why we don't use variant here. Why the method signature is not > public static Collector> groupingBy(Function classifier, Collector downstream) > > I do remember there was a discussion about this, but I couldn't find the answer for this. > > Code can't be passed compilation > return products.stream(). > //collect products into a Map, which key is S by function of > //groupFunc, value is max or min by given max and function of > //compFunc > collect(groupingBy( > groupFunc, > maxBy ? maxBy(comp) : minBy(comp))); > Drat, i just assumed that since the IDE did not show squiggly red lines that it would compile. Downstream receiving collectors refer to the intermediate accumulation type, so we should abstract what it is, be it a ? or something else of the downstream collector. Unfortunately in this case it looks like the compiler is thrown off the scent by ternary operator. If you remove the operator and just express say "minBy(comp)" it should compile. I don't know whether this is something that can be fixed in the compiler or not. Paul. From erik.joelsson at oracle.com Tue Oct 15 15:09:36 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Oct 2013 17:09:36 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D53CC.8030509@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: <525D5AB0.6060806@oracle.com> On 2013-10-15 16:40, Alan Bateman wrote: > On 15/10/2013 15:30, Erik Joelsson wrote: >> Currently the RMI stubs in the jdk are built with the newly built >> rmic binary at the end of the build. This patch changes that and >> instead builds a bootstrap version of the rmic classes, much like >> bootstrap javac in langtools, which runs on the bootjdk, but >> generates classes for the new jdk. The new solution is more friendly >> to cross compilation. >> >> A few notes on the patch: >> >> * In src/share/classes/sun/tools/tree/Node.java, I had to change a >> call to a jdk8 only constructor in java.lang.InternalError. >> * The packages included when compiling rmic were just picked by >> extending for each missing class until the compilation succeeded. If >> someone knows of a crucial package or class that needs to be >> included, please say so. >> * I renamed a parameter to SetupJavaCompilation. I do not consider >> the parameter a hack anymore, but a necessary option for this case. >> * In RMICompilation, the dependency file is now a real touch file >> instead of a virtual one. This was needed for proper dependencies in >> GenerateClasses.gmk. >> * All of corba is compiled twice since I have no idea which parts >> would actually be needed. This doesn't add much build time since it >> can be run effectively in parallel with the rest of the corba build. >> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >> directly instead of Tools.gmk. This was to not add much compile time, >> since Tools.gmk is included and therefore parsed a lot. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >> >> /Erik > It's great to see a solution coming for this, it was always been > troublesome to run the newly built rmic. > > So what are the implications of this? I assume it means that we need > to be careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} > and restrict API usage to what is available in the boot JDK - is that > right? > That would be my conclusion at least. /Erik From martinrb at google.com Tue Oct 15 15:17:35 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Oct 2013 08:17:35 -0700 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D5AB0.6060806@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> <525D5AB0.6060806@oracle.com> Message-ID: Add this doc somewhere: Any java code executed during a JDK build to build other parts of the JDK must be executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) and for this purpose must be built with -target PREVIOUS for bootstrapping purposes, which requires restricting to language level and api of previous JDK. On Tue, Oct 15, 2013 at 8:09 AM, Erik Joelsson wrote: > > On 2013-10-15 16:40, Alan Bateman wrote: > >> On 15/10/2013 15:30, Erik Joelsson wrote: >> >>> Currently the RMI stubs in the jdk are built with the newly built rmic >>> binary at the end of the build. This patch changes that and instead builds >>> a bootstrap version of the rmic classes, much like bootstrap javac in >>> langtools, which runs on the bootjdk, but generates classes for the new >>> jdk. The new solution is more friendly to cross compilation. >>> >>> A few notes on the patch: >>> >>> * In src/share/classes/sun/tools/**tree/Node.java, I had to change a >>> call to a jdk8 only constructor in java.lang.InternalError. >>> * The packages included when compiling rmic were just picked by >>> extending for each missing class until the compilation succeeded. If >>> someone knows of a crucial package or class that needs to be included, >>> please say so. >>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>> parameter a hack anymore, but a necessary option for this case. >>> * In RMICompilation, the dependency file is now a real touch file >>> instead of a virtual one. This was needed for proper dependencies in >>> GenerateClasses.gmk. >>> * All of corba is compiled twice since I have no idea which parts would >>> actually be needed. This doesn't add much build time since it can be run >>> effectively in parallel with the rest of the corba build. >>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >>> directly instead of Tools.gmk. This was to not add much compile time, since >>> Tools.gmk is included and therefore parsed a lot. >>> >>> Bug: https://bugs.openjdk.java.net/**browse/JDK-6604021 >>> Webrev: http://cr.openjdk.java.net/~**erikj/6604021/webrev.01/ >>> >>> /Erik >>> >> It's great to see a solution coming for this, it was always been >> troublesome to run the newly built rmic. >> >> So what are the implications of this? I assume it means that we need to >> be careful in sun.rmi.rmic, sun.tools.{asm,java,javac,**tree,util} and >> restrict API usage to what is available in the boot JDK - is that right? >> >> That would be my conclusion at least. > > /Erik > > > From paul.sandoz at oracle.com Tue Oct 15 15:20:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Oct 2013 17:20:40 +0200 Subject: Demo for Parallel Core Collection API In-Reply-To: References: <2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com> Message-ID: <36B4EDF7-15DE-482C-AFB7-511A03BCDC92@oracle.com> 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 brian.burkhalter at oracle.com Tue Oct 15 15:28:57 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Oct 2013 08:28:57 -0700 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <525D414F.1000904@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> <525BB220.1090100@oracle.com> <916787D6-258A-4DA3-A732-C79F8E210C46@oracle.com> <525D414F.1000904@oracle.com> Message-ID: <840DC91D-3F60-4391-B235-DF635AD65696@oracle.com> On Oct 15, 2013, at 6:21 AM, Alan Bateman wrote: >> Here's the patch updated for this option: >> >> http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ >> > I think this is okay, the only concern is that the host name is no longer guaranteed to be in the exception detail (but for WSATRY_AGAIN then it might not matter because the problem is unlikely to be specific to the host name that is being looked up). The hostname is guaranteed to be in the exception detail: void NET_ThrowByNameWithLastError(JNIEnv *env, const char *name, const char *defaultDetail) { char errmsg[255]; sprintf(errmsg, "errno: %d, error: %s\n", WSAGetLastError(), defaultDetail); JNU_ThrowByNameWithLastError(env, name, errmsg); } The "hostname" string is passed to the third parameter in the above method. Brian From volker.simonis at gmail.com Tue Oct 15 15:29:47 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Oct 2013 17:29:47 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D53CC.8030509@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: Hi Erik, Alan, first of all I think this is a good change because it helps porters to build a complete JDK even if the newly build rmic wouldn't run. On the other hand I'm a little bit concerned if this change still allows it to bootstrap with a non-Oracle based bootstrap JDK. I remember that we had some problems with IBM J9 as bootstrap JDK because they have different default implementations of idlj and rmic (see http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_) Fortunately, the IBM J9 also contains the original Oracle idlj and rmic versions and with the old build it was possible to use them by specifying the two variables: IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar com.sun.tools.corba.se.idl.toJavaPortable.Compile' RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar sun.rmi.rmic.Main' I'm not sure if this is still possible with the new build system. By the way, the main problem why the IBM J9 idlj and rmic didn't work out of the box were some command line options which were only supported by the Oracle implementation. It would therefore be very nice if you could completely remove such options from the build. And you can easily check this by trying the IBM J9 as bootstrap JDK on Linux/x86_64. Thank you and best regards, Volker On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman wrote: > On 15/10/2013 15:30, Erik Joelsson wrote: >> >> Currently the RMI stubs in the jdk are built with the newly built rmic >> binary at the end of the build. This patch changes that and instead builds a >> bootstrap version of the rmic classes, much like bootstrap javac in >> langtools, which runs on the bootjdk, but generates classes for the new jdk. >> The new solution is more friendly to cross compilation. >> >> A few notes on the patch: >> >> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call to >> a jdk8 only constructor in java.lang.InternalError. >> * The packages included when compiling rmic were just picked by extending >> for each missing class until the compilation succeeded. If someone knows of >> a crucial package or class that needs to be included, please say so. >> * I renamed a parameter to SetupJavaCompilation. I do not consider the >> parameter a hack anymore, but a necessary option for this case. >> * In RMICompilation, the dependency file is now a real touch file instead >> of a virtual one. This was needed for proper dependencies in >> GenerateClasses.gmk. >> * All of corba is compiled twice since I have no idea which parts would >> actually be needed. This doesn't add much build time since it can be run >> effectively in parallel with the rest of the corba build. >> * I put the compilation of bootstrap rmic in GenerateClasses.gmk directly >> instead of Tools.gmk. This was to not add much compile time, since Tools.gmk >> is included and therefore parsed a lot. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >> >> /Erik > > It's great to see a solution coming for this, it was always been troublesome > to run the newly built rmic. > > So what are the implications of this? I assume it means that we need to be > careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and restrict > API usage to what is available in the boot JDK - is that right? > > -Alan. From ivan.gerasimov at oracle.com Tue Oct 15 15:31:18 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Oct 2013 19:31:18 +0400 Subject: RFR [8024521] (process) Async close issues with Process InputStream In-Reply-To: References: <52585560.6080904@oracle.com> <525BBB35.4030701@oracle.com> <2C2F4AD7-EC2F-4E01-BD5D-F3627D5207C8@oracle.com> <525C1602.8090200@oracle.com> Message-ID: <525D5FC6.2080003@oracle.com> Here's the updated webrev with the solution by Paul: http://cr.openjdk.java.net/~igerasim/8024521/1/webrev/ I've also excluded the test from it. Instead, I'm going to write a manual testing instruction for SQE. I've tested the fix and it works as expected. Sincerely yours, Ivan On 15.10.2013 10:29, Martin Buchholz wrote: > Hi > > I'm the author of this code. > I'm perfectly willing to believe the close/drain code is buggy. > It is difficult to get right. > I'm looking forward to the updated webrev. > > Often the best way to handle a stress test is to make it run quickly > by default, but provide a system property to make it run as long as > desired, for manual ad-hoc testing. > > > On Mon, Oct 14, 2013 at 9:04 AM, Ivan Gerasimov > > wrote: > > Thanks Paul! > > Yes, I like your solution better. > I'll test it and send the updated webrev shortly. > > Sincerely yours, > Ivan > > > > On 14.10.2013 15:33, Paul Sandoz wrote: > > On Oct 14, 2013, at 11:36 AM, Ivan Gerasimov > > > wrote: > > Hi Paul, > > Thank you for looking at the webrev! > > On 14.10.2013 12:50, Paul Sandoz wrote: > > Hi Ivan, > > Why do you require closeLock? is it not sufficient > leave processExited as is and just add: > > public synchronized void close() throws IOException { > super.close(); > } > > I want to limit the impact on the code, that's why I > synchronize close() with only processExited(). > If I made close() synchronized with all the stream's > methods, then I think it could introduce some > unpredictable drawback. > > Yeah, the close will block until the drain is complete, which > might also have some unpredictable drawback. > > A concern is there was already some code in place to check for > async close, which if detected throws away all the data and > sets the underlying filtered input stream is set to null. So > all that effort draining is wasted. > > Another solution is to keep checking in the loop of > drainInputStream for an async close and fail-fast: > > private InputStream drainInputStream(InputStream in) > throws IOException { > int n = 0; > int j; > byte[] a = null; > while ((j = in.available()) > 0) { > if (buf == null) // asynchronous close()? > return null; // stop reading and discard > a = (a == null) ? new byte[j] : > Arrays.copyOf(a, n + j); > n += in.read(a, n, j); > } > > if (buf == null) // asynchronous close()? > return null; // discard > else if (a == null) > return ProcessBuilder.NullInputStream.INSTANCE; > else > return ByteArrayInputStream(n == a.length ? a > : Arrays.copyOf(a, n)); > } > > /** Called by the process reaper thread when the > process exits. */ > synchronized void processExited() { > // Most BufferedInputStream methods are > synchronized, but close() > // is not, and so we have to handle concurrent > racing close(). > try { > InputStream in = this.in ; > if (in != null) { > InputStream stragglers = > drainInputStream(in); > in.close(); > this.in = stragglers; > } > } catch (IOException ignored) { > // probably an asynchronous close(). > } > } > > This still has the potential to look at the availability of > the current input before async closing, and read from a > different input after async closing, but it will break out on > the next loop check if there are more bytes available to read > otherwise it will be caught again on the final check, so no > munged data will be exposed. > > > > Plus there was already some logic checking if close > was asynchronously called (see BufferedInputStream.close): > > 372 if (buf == null) // > asynchronous close()? > 373 this.in = null; > > and this would no longer be required > > Yes, you're right and these two lines can be removed. > I wouldn't remove the surrounding try {} catch > (IOException) though, as the stream can still be closed > asynchronously. > > I am somewhat struggling to understand the test (not > too familiar with this area). Requires a more expert > eye in this area than I. > > IIUC you are trying to induce the the output process > fd of ExecLoop to "flip" to another fd opened by OpenLoop. > > Yes. > I actually adopted a testcase provided by the reporter of > the problem. > I only changed the test in such a way that it can be run > in an automated mode. > > Below is the exact comment from the original testcase. > It may be a good idea to include it in the regtest. > > /* Following code is a test case that demonstrates a close > race in ProcessPipeInputStream. > *. > * A snippet of the offending code within > ProcessPipeInputStream:. > * // Called by the process reaper thread when the > process exits.. > * synchronized void processExited() { > * // Most BufferedInputStream methods are > synchronized, but close() > * // is not, and so we have to handle concurrent > racing close(). > * try { > * InputStream in = this.in ; > * if (in != null) { > * byte[] stragglers = drainInputStream(in); > * in.close(); > * > * The comment even talks about the race. However, the code > is not adequately > * protecting against it. drainInputStream() (available() > in particular) is not > * threadsafe when a close happens in parallel. What's > worse is that a subsequent > * open() is likely to reassign the closed fd so > drainInputStream ends up draining > * the wrong fd! This can cause OOMs, data corruption on > other fds, and other very > * bad things. > *. > * Notes:. > * - Test creates a large sparse file in /tmp/bigsparsefile > * - Test uses "/proc/meminfo" for simple input.. > * - Invoke using "-Xmx128m" to insure file size of 1G is > greater than heap size > * - Test will run forever, if successful there will not > be any OOM exceptions > * (on my test system they occur about 1 per minute) > * - You need multiple cores (I use 2 x Xeon E5620 = 8 > cores, 16 threads). > *.. > * The basic premise of the test is to create a 1GB sparse > file. Then have lots > * of threads opening and closing this file. In a loop > within a separate thread use UNIXprocess > * to run a simple command. We read the output of the > command, make sure the process > * has exited and then close the inputstream. When the bug > happens, processExited() > * will use FIONREAD to figure out how much data to drain > BUT the fd it is checking > * will be closed and reopened (now referring to > /tmp/bigsparsefile) so it will > * see the size as 1GB and then attempt to allocate a > buffer of that size and. > * then OOM.. > */ > > > > The test concerns me since it is gonna use up loads > of resources and proceed for 10 minutes until deciding > beyond reasonable doubt that there is no issue. > > When I ran the test across different machines (with the > unpatched jdk) it reported from one to five races during > 10 minutes. > We can surely decrease the timeout for the price of higher > probability of a false positive result. > > Unit-like tests should really run in under a minute, plus > should ideally be frugal in their resource consumption > otherwise it could starve other tests running in parallel. If > we cannot create a more deterministic test (not sure it is > possible) then perhaps this test belongs to SQE and not in the > JDK tests? > > Paul. > > > From Alan.Bateman at oracle.com Tue Oct 15 15:34:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 16:34:03 +0100 Subject: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown In-Reply-To: <840DC91D-3F60-4391-B235-DF635AD65696@oracle.com> References: <8124519C-43B7-4279-8B72-D9304B6EC652@oracle.com> <524B1979.3020106@oracle.com> <684C11F8-9E0B-4117-884A-3306C8A010BF@oracle.com> <133CD1C9-70B8-45E1-92BB-EF158983AC14@oracle.com> <524B96BB.4020301@oracle.com> <5253D3C2.3080509@oracle.com> <5256B135.2020507@oracle.com> <0D7757CB-E3A4-431D-A82F-EBDEA8A2D063@oracle.com> <198EB0A9-E1C0-443F-A081-DC85F9205DC9@oracle.com> <525BB220.1090100@oracle.com> <916787D6-258A-4DA3-A732-C79F8E210C46@oracle.com> <525D414F.1000904@oracle.com> <840DC91D-3F60-4391-B235-DF635AD65696@oracle.com> Message-ID: <525D606B.3040405@oracle.com> On 15/10/2013 16:28, Brian Burkhalter wrote: > > The hostname is guaranteed to be in the exception detail: > > void > NET_ThrowByNameWithLastError(JNIEnv *env, const char *name, > const char *defaultDetail) { > char errmsg[255]; > sprintf(errmsg, "errno: %d, error: %s\n", WSAGetLastError(), > defaultDetail); > JNU_ThrowByNameWithLastError(env, name, errmsg); > } > > The "hostname" string is passed to the third parameter in the above > method. > For JNU_ThrowByNameWithLastError then the third parameter is the default/fallback, only used when the error cannot be translated. As I said, it's not a big deal as you are only using it for the WSATRY_AGAIN case. -Alan. From pavel.punegov at oracle.com Tue Oct 15 15:46:35 2013 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 15 Oct 2013 19:46:35 +0400 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <2558863.oXUMbxbUgH@trisuli> References: <1888522.a2LG2QfRuS@trisuli> <5252B618.7030606@oracle.com> <2558863.oXUMbxbUgH@trisuli> Message-ID: <5717680.T8GSN6ymjz@work-dell> Anyone to review this? Alan, do you have any updates on this? On Mon, 07 of Oct 2013 20:47:22 Pavel Punegov wrote: > Hi Alan, > > On Monday 07 October 2013 14:24:40 you wrote: >> On 04/10/2013 16:10, Rob McKenna wrote: >>> Hi Pavel, >>> >>> Thanks for sorting this out. I'm not a reviewer but hopefully Alan >>> will have a look when he gets a chance. Based on the bug description >>> this looks good to me though. >>> >>> -Rob >> >> I looked over the weekend and it's mostly okay (thanks Pavel for taking >> one, we don't do enough execution of these tests with fastdebug builds >> so I'm sure this isn't the only issue that we have). > > Thanks for looking on this > >> A minor comment is that it might be a bit cleaner to throw >> RuntimeException rather than Error but it's not a big deal in this test. > > Error throwing on InterruptedException was added to not break code style in > the code that throws only Errors all over the test. If you want to I can > change this Error (and other throws too) to RuntimeException. > >> The only real comment/question is whether performB should fail if >> process.waitFor is interrupted, this shouldn't happen. > > Printing "B was interrupted while waiting for C" on InterruptedException > could help if we had a regression and performC were looped. When this > happens Jtreg hits timeout and kills/ends all processes. Messages of each > processes that waited for another one will be printed to stderr. I think it > will ease failure analysis in some situations like hanging, host or VM > slowness. > > Thanks, > Pavel -- Thanks, Pavel Punegov From roger.riggs at oracle.com Tue Oct 15 16:03:43 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 15 Oct 2013 12:03:43 -0400 Subject: Please Review Late binding of Chronology with appendValueReduced Message-ID: <525D675F.9070501@oracle.com> Hi, Spot fix for a date time parsing case witha reduced value field when the chronology is parsed after the reduced value field. The fix is to add a callback when the chronology is set to recompute the value of the field with the new chronology. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reduced-latechrono-8025828/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8025828 From scolebourne at joda.org Tue Oct 15 16:12:45 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 15 Oct 2013 17:12:45 +0100 Subject: Please Review Late binding of Chronology with appendValueReduced In-Reply-To: <525D675F.9070501@oracle.com> References: <525D675F.9070501@oracle.com> Message-ID: Fine by me (not a formal reviewer) Stephen On 15 October 2013 17:03, roger riggs wrote: > Hi, > > Spot fix for a date time parsing case witha reduced value field when the > chronology > is parsed after the reduced value field. The fix is to add a callback when > the > chronology is set to recompute the value of the field with the new > chronology. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-reduced-latechrono-8025828/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8025828 From mike.duigou at oracle.com Tue Oct 15 16:19:42 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 09:19:42 -0700 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525CCC6D.3020309@oracle.com> References: <525CCC6D.3020309@oracle.com> Message-ID: Thanks for this cleanup. Looks fine to me. It is disappointing to see some of the tests disabled for compact1 or compact2 because they use unrelated functionality. Is any effort planned to eliminate unnecessary dependencies? Mike On Oct 14 2013, at 22:02 , David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8026378/webrev/ > > Trivial cleanup: > > Non-existent java/util/SummaryStatistics deleted from group jdk_stream > > Non-existent com/oracle/security deleted from jdk_security3 > > java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to needs_jre > > jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 > > java/util/Collection/ListDefaults.java renamed to java/util/List/ListDefaults.java > > Thanks, > David From mike.duigou at oracle.com Tue Oct 15 16:25:09 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 09:25:09 -0700 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> Message-ID: On Oct 14 2013, at 02:32 , Paul Sandoz wrote: >> Virtually all the cases where CME is thrown in the "new" Map defaults are the points where previously the implementation would have looped/retried. >> > >>> For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. >> >> Understood. The alternative would be to GIGO these situations, return and ignore them. >> > > Yeah, unnecessarily complicates the code. It does detect legitimate errors and it makes me uncomfortable to just ignore them. >>> For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". >> >> Modification of any other entry may have the same result. > > Yes, although IIUC modification, by the function value, of other entries will not interfere with that of operating on the entry under computation. A more general recommendation is the function values should be stateless. > > >> I suspect that modification by some other thread is as likely to be a problem as modification by the function. >> > > And under concurrent modification we cannot deterministically detect. CME in the non-concurrent collections is only useful for detecting serial modification due to inversion of control, and in these particular cases it is really very limited as to what it detects. True, but it generally doesn't impose any extra cost. The error detection happens as a side effect of necessary operations. I'd like to bring this set of changes to conclusion as soon as possible. Mike From paul.sandoz at oracle.com Tue Oct 15 16:38:17 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Oct 2013 18:38:17 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> Message-ID: <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> On Oct 15, 2013, at 6:25 PM, Mike Duigou wrote: > > On Oct 14 2013, at 02:32 , Paul Sandoz wrote: > >>> Virtually all the cases where CME is thrown in the "new" Map defaults are the points where previously the implementation would have looped/retried. >>> >> >>>> For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. >>> >>> Understood. The alternative would be to GIGO these situations, return and ignore them. >>> >> >> Yeah, unnecessarily complicates the code. > > It does detect legitimate errors and it makes me uncomfortable to just ignore them. > It is not deterministic. Does HashMap's implementation of putIfAbsent throw a CME? >>>> For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". >>> >>> Modification of any other entry may have the same result. >> >> Yes, although IIUC modification, by the function value, of other entries will not interfere with that of operating on the entry under computation. A more general recommendation is the function values should be stateless. >> >> >>> I suspect that modification by some other thread is as likely to be a problem as modification by the function. >>> >> >> And under concurrent modification we cannot deterministically detect. CME in the non-concurrent collections is only useful for detecting serial modification due to inversion of control, and in these particular cases it is really very limited as to what it detects. > > True, but it generally doesn't impose any extra cost. The error detection happens as a side effect of necessary operations. > There cost to code complexity. I would argue that additional complexity is not worth it given the limits of what can be detected. I guess you know my opinion: remove 'em. So i will be silent for a bit and see if anyone else speaks up :-) Paul. > I'd like to bring this set of changes to conclusion as soon as possible. > > Mike > From xueming.shen at oracle.com Tue Oct 15 16:42:12 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Oct 2013 09:42:12 -0700 Subject: Please Review Separate temporal interface layer (8025720) In-Reply-To: <525C2EC4.3080302@oracle.com> References: <525C2EC4.3080302@oracle.com> Message-ID: <525D7064.9020602@oracle.com> looks good. On 10/14/2013 10:49 AM, roger riggs wrote: > Hi, > > The concrete argument types of Chronology and ZoneId in the TemporalField.resolve method are too specific and should be generalized to allow greater access to the Temporal being resolved. They should be replaced by a single more general argument of type TemporalAccessor that can be queried as needed. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-temporal-layer-8025720/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8025720 From daniel.fuchs at oracle.com Tue Oct 15 16:48:34 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Oct 2013 18:48:34 +0200 Subject: RFR 8026499: Root Logger level can be reset unexpectedly Message-ID: <525D71E2.4020501@oracle.com> Hi, Please find below a fix for: 8026499: Root Logger level can be reset unexpectedly https://bugs.openjdk.java.net/browse/JDK-8026499 The issue here is that calling a method like e.g. URL.openConnection() will trigger the initialization of some platform logger, which could in turn cause the root logger to be lazilly added to the system context, which in turn causes the root logger's level to be reset with the value found in the configuration file (INFO). The fix is to not reinitialize the value of the logger's level if it already has been initialized. As usual, the test fails without the fix and passes with it. best regards, -- daniel From roger.riggs at oracle.com Tue Oct 15 17:41:17 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 15 Oct 2013 17:41:17 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131015174243.6B6E7623FB@hg.openjdk.java.net> Changeset: ea422834f880 Author: rriggs Date: 2013-09-26 23:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea422834f880 8025720: Separate temporal interface layer Summary: Remove ZoneId and Chronology from TemporalField interface Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 110107410393 Author: scolebourne Date: 2013-07-09 21:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/110107410393 8025719: Change Chronology to an interface Summary: Split Chronology and add AbstractChronology Reviewed-by: darcy Contributed-by: scolebourne at joda.org + src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! test/java/time/tck/java/time/chrono/CopticChronology.java Changeset: 087c8c1d2631 Author: rriggs Date: 2013-10-15 13:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/087c8c1d2631 8025722: TemporalAdjusters and TemporalQueries Summary: Move static from interfaces methods to supporting classes Reviewed-by: sherman ! src/share/classes/java/time/DayOfWeek.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/Month.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/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAdjusters.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalQueries.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/util/Formatter.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/TestIsoChronology.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java ! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java From bhavesh.x.patel at oracle.com Tue Oct 15 18:21:01 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Tue, 15 Oct 2013 18:21:01 +0000 Subject: hg: jdk8/tl/langtools: 8026370: javadoc creates empty Message-ID: <20131015182106.98FF0623FE@hg.openjdk.java.net> Changeset: bf6b11347b1a Author: bpatel Date: 2013-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf6b11347b1a 8026370: javadoc creates empty Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testTagOutput/TestTagOutput.java + test/com/sun/javadoc/testTagOutput/pkg1/DeprecatedTag.java From vicente.romero at oracle.com Tue Oct 15 18:38:09 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 15 Oct 2013 18:38:09 +0000 Subject: hg: jdk8/tl/langtools: 8025816: javac crash with method reference with a type variable as the site Message-ID: <20131015183812.DACE9623FF@hg.openjdk.java.net> Changeset: 70a301b35e71 Author: vromero Date: 2013-10-15 19:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70a301b35e71 8025816: javac crash with method reference with a type variable as the site Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/T8025816/CrashMethodReferenceWithSiteTypeVarTest.java From xueming.shen at oracle.com Tue Oct 15 19:35:07 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Oct 2013 12:35:07 -0700 Subject: RFR 8025971 and 8026197 Message-ID: <525D98EB.1010105@oracle.com> Hi, Please help codereview the changes for 8025971: Remove Time-Zone IDs HST/EST/MST 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote file system http://cr.openjdk.java.net/~sherman/8025971_8026197/webrev Note: for 8026197, the only real native resource here needed to be taken care is the FIS. The only thing can go wrong during the creation chain appears to be the use scenario that the jvm runs out of memory, which means we are in bigger trouble (given this is being run at the beginning of vm start in most use scenario) than the release of the native resource. And the FIS resource will actually be released via finalizer, even it fails to get released proactively here. So I still go with the "embedded" style here. I did not use the explicit "32000" buffer size as well. Using the default 8k buffer size can save us a memory allocation at the FIS's native code and remove the dependency on a specific size of the tzdb file (for this particular release). Thanks, -Sherman From Alan.Bateman at oracle.com Tue Oct 15 19:44:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Oct 2013 20:44:42 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <5717680.T8GSN6ymjz@work-dell> References: <1888522.a2LG2QfRuS@trisuli> <5252B618.7030606@oracle.com> <2558863.oXUMbxbUgH@trisuli> <5717680.T8GSN6ymjz@work-dell> Message-ID: <525D9B2A.2020109@oracle.com> On 15/10/2013 16:46, Pavel Punegov wrote: > > Anyone to review this? > > Alan, do you have any updates on this? > > The only thing is the catching of InterruptedException where it should be a test failure if that happens. However I'm okay with what you have (and Rob has agreed to sponsor this one). -Alan. From chris.hegarty at oracle.com Tue Oct 15 20:00:51 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:00:51 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20131015200051.825F66240B@hg.openjdk.java.net> Changeset: af87dabb4263 Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af87dabb4263 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! common/makefiles/RMICompilation.gmk Changeset: ce8c63017f11 Author: chegar Date: 2013-10-13 21:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ce8c63017f11 Merge Changeset: 28be3d174c92 Author: chegar Date: 2013-10-15 13:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28be3d174c92 Merge From roger.riggs at oracle.com Tue Oct 15 20:03:13 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 15 Oct 2013 16:03:13 -0400 Subject: RFR 8025971 and 8026197 In-Reply-To: <525D98EB.1010105@oracle.com> References: <525D98EB.1010105@oracle.com> Message-ID: <525D9F81.6010306@oracle.com> Hi Sherman, I can't help but notice that the tzdb.dat file is read using a doPrivilege block in ZoneInfoFile.java but not in TzdbZoneRulesProvider.java. It is not new but is that correct? Was there an opportunity to check the performance before and after both in the local a remote cases? tzdb.dat frequently needs to be read and contributes to startup latency. (Not a Reviewer), Roger On 10/15/2013 3:35 PM, Xueming Shen wrote: > Hi, > > Please help codereview the changes for > > 8025971: Remove Time-Zone IDs HST/EST/MST > 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote > file system > > http://cr.openjdk.java.net/~sherman/8025971_8026197/webrev > > Note: for 8026197, the only real native resource here needed to be > taken care is > the FIS. The only thing can go wrong during the creation chain appears > to be the > use scenario that the jvm runs out of memory, which means we are in > bigger trouble > (given this is being run at the beginning of vm start in most use > scenario) than the > release of the native resource. And the FIS resource will actually be > released via > finalizer, even it fails to get released proactively here. So I still > go with the "embedded" > style here. I did not use the explicit "32000" buffer size as well. > Using the default 8k > buffer size can save us a memory allocation at the FIS's native code > and remove the > dependency on a specific size of the tzdb file (for this particular > release). > > Thanks, > -Sherman From vicente.romero at oracle.com Tue Oct 15 20:04:14 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 15 Oct 2013 20:04:14 +0000 Subject: hg: jdk8/tl/langtools: 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Message-ID: <20131015200431.BC4DF6240C@hg.openjdk.java.net> Changeset: d8d6b58f1ebf Author: vromero Date: 2013-10-15 21:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d8d6b58f1ebf 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.out From chris.hegarty at oracle.com Tue Oct 15 20:04:38 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:04:38 +0000 Subject: hg: jdk8/tl/jaxp: 14 new changesets Message-ID: <20131015200522.8F7FD6240D@hg.openjdk.java.net> Changeset: ecb66dc473c1 Author: joehw Date: 2013-07-16 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ecb66dc473c1 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 7a2014318343 Author: joehw Date: 2013-07-17 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7a2014318343 8017298: Better XML support Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: a59549c3ad60 Author: dfuchs Date: 2013-07-17 18:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a59549c3ad60 8013502: Improve stream factories Reviewed-by: joehw, mullan, lancea ! src/javax/xml/stream/FactoryFinder.java Changeset: 4b0b2b5c4cc8 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4b0b2b5c4cc8 Merge Changeset: 40b8abe19642 Author: chegar Date: 2013-07-29 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/40b8abe19642 Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 720db2e27962 Author: joehw Date: 2013-07-31 00:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/720db2e27962 8014530: Better digital signature processing Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.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/XML11NSDocumentScannerImpl.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/XMLEntityManager.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/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: cd9347628c7c Author: joehw Date: 2013-07-31 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cd9347628c7c 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: ecbddaa85462 Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ecbddaa85462 Merge Changeset: c5e80c1fa32f Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c5e80c1fa32f Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: f952c33ebfdb Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f952c33ebfdb Merge Changeset: ce16a5aa1507 Author: joehw Date: 2013-08-20 09:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ce16a5aa1507 8022682: Supporting XOM Reviewed-by: alanb, chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java Changeset: cc3b64366048 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cc3b64366048 Merge Changeset: 2b77e12ff69d Author: chegar Date: 2013-10-11 19:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2b77e12ff69d Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 6f220761f643 Author: chegar Date: 2013-10-15 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6f220761f643 Merge From chris.hegarty at oracle.com Tue Oct 15 20:06:26 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:06:26 +0000 Subject: hg: jdk8/tl/jaxws: 11 new changesets Message-ID: <20131015200656.D6AA46240E@hg.openjdk.java.net> Changeset: 43240b8b995b Author: mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/43240b8b995b 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java + src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java + src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java Changeset: 358f32260d1f Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/358f32260d1f Merge Changeset: 5212665bea32 Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5212665bea32 Merge Changeset: d9704ab517d5 Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9704ab517d5 Merge Changeset: fca8869ccfd0 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fca8869ccfd0 Merge Changeset: a6e2adde013e Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a6e2adde013e Merge Changeset: f6376ba97cea Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f6376ba97cea Merge Changeset: d3a65e8912c9 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d3a65e8912c9 Merge Changeset: da8141b6e344 Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/da8141b6e344 Merge Changeset: 2dc8ae7eb53b Author: chegar Date: 2013-10-11 19:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2dc8ae7eb53b Merge Changeset: 01facfebe17b Author: chegar Date: 2013-10-15 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/01facfebe17b Merge From mike.duigou at oracle.com Tue Oct 15 20:18:17 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 13:18:17 -0700 Subject: RFR : 8025910 : (s) Rename Stream.substream(long) -> skip(long) and remove substream(long, long) Message-ID: Hello all; As promised on the lambda-libs-spec-experts mailing list I have prepared a changeset which renames the single arg substream() to skip() and remove the two arg substream() method (aka "slice"). The rationale behind these changes is: - skip() is easier for new users to locate than substream(). - substream(long,long) has ambiguous semantics and duplicates skip().limit() http://cr.openjdk.java.net/~mduigou/JDK-8025910/1/webrev/ http://cr.openjdk.java.net/~mduigou/JDK-8025910/1/specidff/overview-summary.html Cheers, Mike From xueming.shen at oracle.com Tue Oct 15 20:23:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Oct 2013 13:23:57 -0700 Subject: RFR 8025971 and 8026197 In-Reply-To: <525D9F81.6010306@oracle.com> References: <525D98EB.1010105@oracle.com> <525D9F81.6010306@oracle.com> Message-ID: <525DA45D.60708@oracle.com> On 10/15/2013 01:03 PM, roger riggs wrote: > Hi Sherman, > > I can't help but notice that the tzdb.dat file is read using a doPrivilege block in > ZoneInfoFile.java but not in TzdbZoneRulesProvider.java. > TzdbZoneRulesProvider is package private. It is initialized inside the doPrivilege block in the init code in ZoneRulesProvider. > It is not new but is that correct? > > Was there an opportunity to check the performance before and after both > in the local a remote cases? tzdb.dat frequently needs to be read and > contributes to startup latency. The tzdb.dat should only be read in once in normal use scenario. The buffered stream has limited help in local case, I had measured it lots of time during last round. It definitely should help the "high-latency" remove scenario though. I can measure the local case again before push, if desirable. -Sherman > > (Not a Reviewer), > > Roger > > > On 10/15/2013 3:35 PM, Xueming Shen wrote: >> Hi, >> >> Please help codereview the changes for >> >> 8025971: Remove Time-Zone IDs HST/EST/MST >> 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote file system >> >> http://cr.openjdk.java.net/~sherman/8025971_8026197/webrev >> >> Note: for 8026197, the only real native resource here needed to be taken care is >> the FIS. The only thing can go wrong during the creation chain appears to be the >> use scenario that the jvm runs out of memory, which means we are in bigger trouble >> (given this is being run at the beginning of vm start in most use scenario) than the >> release of the native resource. And the FIS resource will actually be released via >> finalizer, even it fails to get released proactively here. So I still go with the "embedded" >> style here. I did not use the explicit "32000" buffer size as well. Using the default 8k >> buffer size can save us a memory allocation at the FIS's native code and remove the >> dependency on a specific size of the tzdb file (for this particular release). >> >> Thanks, >> -Sherman > From chris.hegarty at oracle.com Tue Oct 15 20:21:42 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:21:42 +0000 Subject: hg: jdk8/tl/corba: 15 new changesets Message-ID: <20131015202154.91C4562411@hg.openjdk.java.net> Changeset: 81d694b1ab2f Author: msheppar Date: 2013-06-14 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/81d694b1ab2f 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: ab6eae733bce Author: chegar Date: 2013-07-15 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ab6eae733bce Merge Changeset: e5ea72df9806 Author: chegar Date: 2013-07-22 13:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e5ea72df9806 Merge Changeset: be4fdc568d73 Author: mchung Date: 2013-07-22 19:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/be4fdc568d73 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: b0aeb77f0292 Author: chegar Date: 2013-07-25 17:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b0aeb77f0292 Merge Changeset: a72f506e3058 Author: chegar Date: 2013-08-02 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a72f506e3058 Merge Changeset: 0717fc6f2960 Author: chegar Date: 2013-08-09 14:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0717fc6f2960 Merge Changeset: 6b5db99e194c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b5db99e194c Merge - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava Changeset: 9c75c61d97f8 Author: msheppar Date: 2013-08-19 15:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9c75c61d97f8 8022940: Enhance CORBA translations Reviewed-by: coffeys, alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java Changeset: 2caa37dfd7cd Author: chegar Date: 2013-08-23 22:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2caa37dfd7cd Merge Changeset: a5788ab042dc Author: chegar Date: 2013-08-30 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a5788ab042dc Merge Changeset: 118a211bb3ba Author: chegar Date: 2013-09-06 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/118a211bb3ba Merge Changeset: cc52d582df09 Author: chegar Date: 2013-09-14 19:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc52d582df09 Merge Changeset: 396854c032bb Author: chegar Date: 2013-10-03 19:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/396854c032bb Merge Changeset: 47513cdce4ed Author: chegar Date: 2013-10-13 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/47513cdce4ed Merge From jan.lahoda at oracle.com Tue Oct 15 20:22:53 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 15 Oct 2013 20:22:53 +0000 Subject: hg: jdk8/tl/langtools: 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Message-ID: <20131015202256.D890D62412@hg.openjdk.java.net> Changeset: 19e8eebfbe52 Author: jlahoda Date: 2013-10-15 22:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/19e8eebfbe52 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Summary: A mostly automated rename Annotate.Annotator->Annotate.Worker and enterAnnotation->run. Reviewed-by: emc, jjg ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java From chris.hegarty at oracle.com Tue Oct 15 20:23:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:23:36 +0000 Subject: hg: jdk8/tl/hotspot: 13 new changesets Message-ID: <20131015202413.3BED862413@hg.openjdk.java.net> Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp From chris.hegarty at oracle.com Tue Oct 15 20:08:27 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:08:27 +0000 Subject: hg: jdk8/tl/jdk: 61 new changesets Message-ID: <20131015202435.B8C2D62414@hg.openjdk.java.net> Changeset: b3baca585b7f Author: jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3baca585b7f 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! 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 Changeset: 37f6f4dbfc6d Author: ksrini Date: 2013-05-07 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37f6f4dbfc6d 8013506: Better Pack200 data handling Reviewed-by: jrose, kizune, mschoene ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 139a01719eec Author: jchen Date: 2013-05-09 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/139a01719eec 8013510: Augment image writing code Reviewed-by: bae, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: f2068f4244a5 Author: bae Date: 2013-05-14 12:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2068f4244a5 8014093: Improve parsing of images Reviewed-by: prr, jgodinez ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 65d5a6e53d12 Author: alexsch Date: 2013-05-20 14:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65d5a6e53d12 8013744: Better tabling for AWT Reviewed-by: art, malenkov, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 52be85d5149b Author: bae Date: 2013-05-20 15:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52be85d5149b 8014102: Improve image conversion Reviewed-by: mschoene, prr, jgodinez ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 08b88f831dd1 Author: malenkov Date: 2013-05-20 19:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08b88f831dd1 8012071: Better Building of Beans Reviewed-by: art, skoivu ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java Changeset: 140c474ab8b9 Author: malenkov Date: 2013-05-31 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/140c474ab8b9 8012277: Improve AWT DataFlavor Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 23fe888b698d Author: weijun Date: 2013-05-08 09:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23fe888b698d 8014341: Better service from Kerberos servers Summary: read incoming data safely and take care of null return value Reviewed-by: valeriep, ahgross ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java Changeset: 532343ec60b7 Author: weijun Date: 2013-06-13 10:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/532343ec60b7 8013739: Better LDAP resource management Reviewed-by: ahgross, mchung, xuelei ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 6d9ec6877a7f Author: weijun Date: 2013-06-13 10:31 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d9ec6877a7f 8015731: Subject java.security.auth.subject to improvements Reviewed-by: skoivu, mullan ! src/share/classes/javax/security/auth/Subject.java Changeset: ccca37ca416a Author: jchen Date: 2013-06-13 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccca37ca416a 8014098: Better profile validation Reviewed-by: bae, mschoene, prr ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: 5a14ecd30b4e Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a14ecd30b4e 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! make/com/sun/jmx/Makefile ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: 7addece3f21e Author: jbachorik Date: 2013-06-20 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7addece3f21e 8014085: Better serialization support in JMX classes Reviewed-by: alanb, dfuchs, skoivu ! src/share/classes/javax/management/MBeanNotificationInfo.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 Changeset: eb29deb3c1db Author: chegar Date: 2013-06-27 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb29deb3c1db Merge Changeset: 0a06ec55aacd Author: bae Date: 2013-07-01 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a06ec55aacd 8017287: Better resource disposal Reviewed-by: prr, vadim, skoivu ! src/share/classes/sun/java2d/Disposer.java Changeset: 51204df822d3 Author: erikj Date: 2013-07-03 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51204df822d3 8012146: Improve tool support Reviewed-by: ksrini, dholmes, alanb, anthony ! makefiles/CompileLaunchers.gmk ! makefiles/Images.gmk ! test/Makefile Changeset: 888fd0ad7e1e Author: ascarpino Date: 2013-07-03 15:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/888fd0ad7e1e 8011071: Better crypto provider handling Reviewed-by: hawtin, valeriep ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/DSAPrivateKey.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java Changeset: a06b764cc2d0 Author: dsamersoff Date: 2013-07-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a06b764cc2d0 8008589: Better MBean permission validation Summary: Better MBean permission validation Reviewed-by: skoivu, dfuchs, mchung, sjiang ! src/share/classes/javax/management/MBeanTrustPermission.java Changeset: 9c6de162771c Author: smarks Date: 2013-07-11 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6de162771c 8014987: Augment serialization handling Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java Changeset: c40752886882 Author: jfranck Date: 2013-07-15 14:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c40752886882 8014349: (cl) Class.getDeclaredClass problematic in some class loader configurations Reviewed-by: mchung, ahgross, darcy ! src/share/classes/java/lang/Class.java ! src/share/native/java/lang/Class.c Changeset: 48548e40187a Author: mchung Date: 2013-07-15 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48548e40187a 8017291: Cast Proxies Aside Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ClassLoader.java Changeset: 047c99b53994 Author: chegar Date: 2013-07-15 18:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/047c99b53994 Merge ! src/share/classes/java/lang/Thread.java - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/swing/SwingUtilities2.java - test/java/util/Comparators/BasicTest.java Changeset: 3062c96e79e0 Author: chegar Date: 2013-07-16 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062c96e79e0 Merge Changeset: e1497f102a8a Author: malenkov Date: 2013-07-16 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1497f102a8a 8019617: Better view of objects Reviewed-by: art, skoivu ! src/share/classes/javax/swing/text/html/ObjectView.java Changeset: 69a2dc92fefe Author: michaelm Date: 2013-07-18 18:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69a2dc92fefe 8015743: Address internet addresses Reviewed-by: alanb, khazra, skoivu ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Inet6Address/serialize/Serialize.java Changeset: 5d8f1e697cd8 Author: okutsu Date: 2013-07-19 12:14 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d8f1e697cd8 8001029: Add new date/time capability Reviewed-by: mchung, hawtin ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/SetDefaultSecurityTest.java Changeset: fe90bd20865b Author: sjiang Date: 2013-07-19 13:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe90bd20865b 8014534: Better profiling support Summary: Validation of parameters Reviewed-by: sspitsyn, skoivu, mchung ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c Changeset: 0a51ccf778b3 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a51ccf778b3 Merge Changeset: 3725e8a70ae9 Author: mchung Date: 2013-07-22 19:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3725e8a70ae9 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 5bde952bf23c Author: sgabdura Date: 2013-07-23 09:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bde952bf23c 8016357: Update hotspot diagnostic class Summary: Add security check to HotSpotDiagnostic.dumpHeap Reviewed-by: fparain, sla, ahgross ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c Changeset: 5bdc55e87cae Author: weijun Date: 2013-07-17 18:46 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bdc55e87cae 8020696: Merge problem for KdcComm.java Reviewed-by: chegar ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: 490c67c5d9a2 Author: jchen Date: 2013-07-24 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/490c67c5d9a2 8020293: JVM crash Reviewed-by: prr, jgodinez ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: bcce47d9d8da Author: jbachorik Date: 2013-07-19 16:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcce47d9d8da 8019584: javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Reviewed-by: mchung, sjiang, dfuchs, ahgross ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java Changeset: d7a0bbf526f8 Author: jbachorik Date: 2013-07-29 04:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7a0bbf526f8 8021577: JCK test api/javax_management/jmx_serial/modelmbean/ModelMBeanNotificationInfo/serial/index.html#Input has failed since jdk 7u45 b01 Reviewed-by: alanb, dfuchs, ahgross ! src/share/classes/javax/management/MBeanNotificationInfo.java Changeset: 1a1e42c8e988 Author: chegar Date: 2013-07-25 19:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a1e42c8e988 Merge ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/javax/security/auth/Subject.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/security/pkcs11/P11Key.java - test/java/util/Collections/EmptySortedSet.java Changeset: 446bc20447a1 Author: chegar Date: 2013-07-29 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/446bc20447a1 Merge Changeset: e537b7f5f39b Author: naoto Date: 2013-08-01 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e537b7f5f39b 8021286: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: 44a063555ccd Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a063555ccd Merge Changeset: 17e1675e3d1e Author: serb Date: 2013-08-04 02:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17e1675e3d1e 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: ba7566de89c6 Author: sjiang Date: 2013-08-06 10:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba7566de89c6 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: 23476862c55b Author: malenkov Date: 2013-08-07 14:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23476862c55b 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: db9539b0061d Author: jbachorik Date: 2013-08-08 19:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db9539b0061d 8021360: object not exported" on start of JMXConnectorServer for RMI-IIOP protocol with security manager Reviewed-by: alanb, ahgross, smarks, coffeys ! src/share/classes/com/sun/jmx/remote/protocol/iiop/IIOPProxyImpl.java Changeset: 077d8c2cc5f6 Author: chegar Date: 2013-08-09 14:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/077d8c2cc5f6 Merge ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/net/package.html ! src/share/classes/java/util/TimeZone.java ! src/share/native/java/net/net_util.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/Makefile Changeset: e82ddcc1b2fb Author: serb Date: 2013-08-12 19:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e82ddcc1b2fb 8021275: Better screening for ScreenMenu Reviewed-by: art ! src/macosx/classes/com/apple/laf/ScreenMenu.java Changeset: 3e3cbd93f4f1 Author: twisti Date: 2013-08-12 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e3cbd93f4f1 8022066: Evaluation of method reference to signature polymorphic method crashes VM Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/MethodHandleConstants.java Changeset: e173b8786362 Author: ksrini Date: 2013-08-14 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e173b8786362 8021355: REGRESSION: Five closed/java/awt/SplashScreen tests fail since 7u45 b01 on Linux, Solaris Reviewed-by: dholmes, anthony, ahgross, erikj ! src/solaris/bin/java_md_solinux.c Changeset: 31010ca3da3e Author: chegar Date: 2013-08-15 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31010ca3da3e Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: 3f85c96eafcc Author: weijun Date: 2013-08-14 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f85c96eafcc 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: 50bdb9577b27 Author: erikj Date: 2013-08-19 12:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50bdb9577b27 8022719: tools/launcher/RunpathTest.java fails after 8012146 Reviewed-by: chegar ! test/tools/launcher/RunpathTest.java Changeset: 0f279113c95a Author: erikj Date: 2013-08-19 14:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f279113c95a 8023231: Remove comma from jtreg bug line Reviewed-by: alanb, chegar ! test/tools/launcher/RunpathTest.java Changeset: ad35b4b6ce8e Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad35b4b6ce8e Merge Changeset: 29f73bc50bd4 Author: chegar Date: 2013-08-30 09:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f73bc50bd4 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/solaris/native/java/net/NetworkInterface.c - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: a8593bc7c29d Author: chegar Date: 2013-09-06 09:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8593bc7c29d Merge ! src/share/classes/java/lang/Class.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 22ea25e71b4c Author: chegar Date: 2013-09-14 19:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22ea25e71b4c Merge Changeset: 240072825ada Author: chegar Date: 2013-10-03 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/240072825ada Merge ! make/sun/awt/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp ! src/solaris/bin/java_md_solinux.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/java/util/regex/PatternTest.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/tools/launcher/RunpathTest.java Changeset: adbf6d61c820 Author: chegar Date: 2013-10-07 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adbf6d61c820 8025991: tools/launcher/RunpathTest.java fails Reviewed-by: erikj ! test/tools/launcher/RunpathTest.java Changeset: 99832c718cb8 Author: chegar Date: 2013-10-15 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99832c718cb8 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3dbfab65c17e Author: chegar Date: 2013-10-15 13:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3dbfab65c17e Merge ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/lang/ClassLoader.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 27ac58b9a62a Author: chegar Date: 2013-10-15 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27ac58b9a62a 8026513: ProblemList.txt Updates (10/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: 78ffa90c77b2 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78ffa90c77b2 Merge From roger.riggs at oracle.com Tue Oct 15 20:50:16 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 15 Oct 2013 16:50:16 -0400 Subject: RFR 8025971 and 8026197 In-Reply-To: <525DA45D.60708@oracle.com> References: <525D98EB.1010105@oracle.com> <525D9F81.6010306@oracle.com> <525DA45D.60708@oracle.com> Message-ID: <525DAA88.60603@oracle.com> Hi Sherman, On 10/15/2013 4:23 PM, Xueming Shen wrote: > On 10/15/2013 01:03 PM, roger riggs wrote: >> Hi Sherman, >> >> I can't help but notice that the tzdb.dat file is read using a >> doPrivilege block in >> ZoneInfoFile.java but not in TzdbZoneRulesProvider.java. >> > > TzdbZoneRulesProvider is package private. It is initialized inside the > doPrivilege > block in the init code in ZoneRulesProvider. Ok, it is fine as is. In retrospect, I would probably have tried to keep the doPriveleged block as close to and as narrow as possible around the privileged operations; in this case the property check and the file open. > > >> It is not new but is that correct? >> >> Was there an opportunity to check the performance before and after both >> in the local a remote cases? tzdb.dat frequently needs to be read and >> contributes to startup latency. > > The tzdb.dat should only be read in once in normal use scenario. The > buffered > stream has limited help in local case, I had measured it lots of time > during > last round. It definitely should help the "high-latency" remove > scenario though. > I can measure the local case again before push, if desirable. While tracking down JDK-8023639 , it was noticed that some of the latency was do to initializating both TimeZone.getDefault and ZoneRulesProvider.getRules. No need for more work if the buffered version does not improve startup. Thanks, Roger > > -Sherman > >> >> (Not a Reviewer), >> >> Roger >> >> >> On 10/15/2013 3:35 PM, Xueming Shen wrote: >>> Hi, >>> >>> Please help codereview the changes for >>> >>> 8025971: Remove Time-Zone IDs HST/EST/MST >>> 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, >>> remote file system >>> >>> http://cr.openjdk.java.net/~sherman/8025971_8026197/webrev >>> >>> Note: for 8026197, the only real native resource here needed to be >>> taken care is >>> the FIS. The only thing can go wrong during the creation chain >>> appears to be the >>> use scenario that the jvm runs out of memory, which means we are in >>> bigger trouble >>> (given this is being run at the beginning of vm start in most use >>> scenario) than the >>> release of the native resource. And the FIS resource will actually >>> be released via >>> finalizer, even it fails to get released proactively here. So I >>> still go with the "embedded" >>> style here. I did not use the explicit "32000" buffer size as well. >>> Using the default 8k >>> buffer size can save us a memory allocation at the FIS's native code >>> and remove the >>> dependency on a specific size of the tzdb file (for this particular >>> release). >>> >>> Thanks, >>> -Sherman >> > From brian.burkhalter at oracle.com Tue Oct 15 20:58:02 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Oct 2013 13:58:02 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <525819D0.4060302@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <525819D0.4060302@oracle.com> Message-ID: Pursuant to comments on the submitted CCC request, the patch previously approved for this issue has been revised: http://cr.openjdk.java.net/~bpb/7179567/webrev.6/ The difference is that the URLClassLoader constructors and newInstance() methods no longer throw a NPE if the URL array parameter is non-null but contains at least one null element. The javadoc and test have been adjusted accordingly. A new issue https://bugs.openjdk.java.net/browse/JDK-8026517 has been filed to track adding a test for a null element in the URL array parameter. This latter issue is not presently scheduled to be addressed in JDK 8. Thanks, Brian From kumar.x.srinivasan at oracle.com Tue Oct 15 21:10:06 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 15 Oct 2013 14:10:06 -0700 Subject: RFR: 8026504: [asm] update internal ASM to the Beta version Message-ID: <525DAF2E.8070209@oracle.com> Hello, Please review refreshing the internal ASM sources to ASM_5_0_BETA, I have run all the lambda test-ng tests using the lambda repo as well as the nashorn regression tests and test262parallel. Bug: https://bugs.openjdk.java.net/browse/JDK-8026504 Webrev: http://cr.openjdk.java.net/~ksrini/8026504/webrev/ Thanks Kumar From chris.hegarty at oracle.com Tue Oct 15 20:15:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:15:40 +0000 Subject: hg: jdk8/tl/langtools: 14 new changesets Message-ID: <20131015201701.A023D6240F@hg.openjdk.java.net> Changeset: 84df20dc604a Author: bpatel Date: 2013-07-24 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84df20dc604a 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + test/com/sun/javadoc/testWindowTitle/TestWindowTitle.java + test/com/sun/javadoc/testWindowTitle/p1/C1.java + test/com/sun/javadoc/testWindowTitle/p2/C2.java Changeset: 8b3e2cc5f1de Author: chegar Date: 2013-07-25 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b3e2cc5f1de Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0d75d3b96477 Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d75d3b96477 Merge Changeset: 2d1a54d213c2 Author: chegar Date: 2013-08-09 14:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d1a54d213c2 Merge Changeset: 84b6d75ff2c9 Author: chegar Date: 2013-08-15 21:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84b6d75ff2c9 Merge Changeset: a540e2a926cf Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a540e2a926cf Merge Changeset: a8f0c3583a86 Author: chegar Date: 2013-08-30 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a8f0c3583a86 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 6250a7f0aba6 Author: chegar Date: 2013-09-06 10:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6250a7f0aba6 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: a6901af8a2e4 Author: chegar Date: 2013-09-14 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6901af8a2e4 Merge Changeset: 2c13a5da6854 Author: chegar Date: 2013-10-03 19:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2c13a5da6854 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java - src/share/classes/com/sun/tools/javac/code/Annotations.java - test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej - test/tools/javac/lambda/TargetType10.out - test/tools/javac/lambda/typeInference/InferenceTest5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out Changeset: 86e57f576e65 Author: chegar Date: 2013-10-11 19:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/86e57f576e65 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java Changeset: 46feacb99698 Author: chegar Date: 2013-10-15 14:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46feacb99698 Merge - src/share/classes/com/sun/javadoc/package.html - src/share/classes/com/sun/tools/classfile/package.html - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html - src/share/classes/com/sun/tools/doclets/formats/html/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html - src/share/classes/com/sun/tools/doclets/package.html - src/share/classes/com/sun/tools/javap/package.html Changeset: 90c9ae4bc756 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/90c9ae4bc756 Merge Changeset: dd073728085d Author: chegar Date: 2013-10-15 21:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd073728085d Merge From mike.duigou at oracle.com Tue Oct 15 21:23:42 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 14:23:42 -0700 Subject: RFR : 8025910 : (s) Rename Stream.substream(long) -> skip(long) and remove substream(long, long) In-Reply-To: <525DAFE3.8040603@oracle.com> References: <525DAFE3.8040603@oracle.com> Message-ID: <4DB84707-F3E5-4100-BAE2-91187849EB69@oracle.com> Thanks, I will make that correction to all of the primitive streams. (cut and paste error) Mike On Oct 15 2013, at 14:13 , Henry Jen wrote: > On 10/15/2013 01:18 PM, Mike Duigou wrote: >> Hello all; >> >> As promised on the lambda-libs-spec-experts mailing list I have prepared a changeset which renames the single arg substream() to skip() and remove the two arg substream() method (aka "slice"). >> >> The rationale behind these changes is: >> >> - skip() is easier for new users to locate than substream(). >> - substream(long,long) has ambiguous semantics and duplicates skip().limit() >> >> http://cr.openjdk.java.net/~mduigou/JDK-8025910/1/webrev/ > > The javadoc for skip() has reference to generate(Supplier), the link is > not correct for Primitive versions, they should be corresponding version > like IntSupplier. > > Cheers, > Henry > From henry.jen at oracle.com Tue Oct 15 22:34:48 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 15 Oct 2013 15:34:48 -0700 Subject: RFR: 8025909: Lambda Library Spec Updates Message-ID: <525DC308.9010803@oracle.com> Hi, Please kindly review the latest update on lambda library spec, and a few minor code clean up. Webrev and specdiff can be found at, http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/webrev http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/specdiff This webrev also covers update that address JDK-8024179 as the spec update explains why reported scenario is expected. Cheers, Henry From philip.race at oracle.com Tue Oct 15 22:48:46 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2013 15:48:46 -0700 Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: <523A27A8.404@oracle.com> <523B01DF.1030902@oracle.com> Message-ID: <525DC64E.3060404@oracle.com> Hello Volker, I just remembered & got back to these changes - my email inbox isn't a very good reminder system. I am OK with everything I see in the client areas except as below :- /* Very basic start for AIX - feel free to complete .. 169 */ We should remove this comment. If that means first getting any necessary completion from IBM folks, please ask them. Given the lack of fontconfig on AIX as standard its probably more important for AIX than any other OS so I suggest the latter. > * insted it has to be installed from the "AIX Toolbox for Linux Applications" insted -> instead X11SurfaceData.c: #ifndef MAX and #ifndef MIN I found that re-definition warnings are seen at least on 64 bit linux. Maybe you should rename these too generically named macros to XSD_MAX and XSD_MIN. > extern int dladdr(void *addr, Dl_info *info); // use the HotSpot implementation from libjvm.so Did you ever get an opinion on this from the libraries or hotspot teams ? -phil. On 9/19/2013 7:28 AM, Volker Simonis wrote: > Hi Phil, > > I'm open to any good ideas. > > The current solution is pragmatic, simple and it has no impact on > existing platforms. > > The other possibility I see is to put the 'dladdr' implantation into > its own library (something equivalent to "libjli") and link that > library to "libawt". But I currently don't see any existing library I > could put the implementation into. > > Notice that the change I propose already contains an extra > implementation of 'dladdr' for AIX in > "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not > linked against libjvm and we therefore can not use the 'extern'-trick > there. > > Of course it would be nice if there would be a small library which > contains 'dladdr' and which could be linked against both, "libawt" and > "libhprof". But I think that would require bigger shared changes (with > possible empty implementations on the current platforms). > > What do other think? > > Regards, > Volker > > > On Thu, Sep 19, 2013 at 3:53 PM, Phil Race wrote: >> Hi, >> >> w.r.t the one issue below : is the awt load library code the only place you >> need/are doing this ? If someone else (hotspot, core-libs) already assented >> to this >> then I guess I could too but I'd like to hear for sure that hotspot and >> core-libs >> teams both agree to this approach and whether there is an alternative. >> >> -phil. >> >> >> On 9/19/13 4:29 AM, Volker Simonis wrote: >> >> Hi Phil, >> >> thank you for looking at the changes. Please find my answers inline: >> >> >>> /* AIX does not provide the 'dladdr' function. But fortunately, we've >>> >>> 42 * already implemented it in the HotSpot, because we need it there as >>> 43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}). >>> >>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot >>> function sounds hacky. What actual requirement is there that the >>> AIX class libraries be so tightly-coupled with that VM? >>> There is no contract there. >>> >> You're right, there is no contract. It's just pragmatic solution and I think >> it should always work because the libjvm will always be loaded at the point >> in AWT where it is used. Another solution would be to re-implement the >> functionality in the class library and I don't like code duplication either. >> >>> -phil. >>> >>> From mandy.chung at oracle.com Tue Oct 15 22:58:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Oct 2013 15:58:26 -0700 Subject: RFR 8026499: Root Logger level can be reset unexpectedly In-Reply-To: <525D71E2.4020501@oracle.com> References: <525D71E2.4020501@oracle.com> Message-ID: <525DC892.3020008@oracle.com> On 10/15/2013 9:48 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8026499: Root Logger level can be reset unexpectedly > https://bugs.openjdk.java.net/browse/JDK-8026499 > > > > The issue here is that calling a method like e.g. URL.openConnection() > will trigger the initialization of some platform logger, which could > in turn cause the root logger to be lazilly added to the system context, > which in turn causes the root logger's level to be reset with the > value found in the configuration file (INFO). > > The fix is to not reinitialize the value of the logger's level if > it already has been initialized. The change looks okay. When the root logger is added to the system context, it considers it as a newly created logger and thus resetting its level. The global logger should have the same issue as there is only a single instance. I believe the logger's handler doesn't get reset and level is the only issue. Logger.hasLocalLevel() doesn't seem to be necessary and it seems to be more explicit to replace !logger.hasLocalLevel() with logger.getLevel() == null It would also help to add a comment to explain the check. TestRootLoggerLevel.java - it may be good to also test the global logger. line 70: I believe this line is not necessary (do you mean to do any other checking and that's why you call LoggingSupport.getLogger?) I think the comment on the behavior before the fix (line 77-78) can be removed and this may become not as relevant after this bug fix. Line 104 - this permission may be needed in your early version of this test? can be removed now? btw - should this test also run with no security manager? Mandy From mike.duigou at oracle.com Tue Oct 15 23:05:04 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 16:05:04 -0700 Subject: RFR: 8025909: Lambda Library Spec Updates In-Reply-To: <525DC308.9010803@oracle.com> References: <525DC308.9010803@oracle.com> Message-ID: <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> Where is the null handling for methods like DoubleStream.allMatch() described? I don't see an @throws NullPointerException if predicate is null. The class level "functional interface parameters to methods, unless otherwise specified, may not be null" instruction is removed with reference to Stream docs. I hope this is sufficient notice. For allMatch/noneMatch I think the case where predicate is null and the stream is empty is covered by "and the predicate is not evaluated". Mike On Oct 15 2013, at 15:34 , Henry Jen wrote: > Hi, > > Please kindly review the latest update on lambda library spec, and a few > minor code clean up. > > Webrev and specdiff can be found at, > > http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/webrev > http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/specdiff > > This webrev also covers update that address JDK-8024179 as the spec > update explains why reported scenario is expected. > > Cheers, > Henry From david.holmes at oracle.com Tue Oct 15 23:14:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 09:14:41 +1000 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: References: <525CCC6D.3020309@oracle.com> Message-ID: <525DCC61.3080705@oracle.com> An additional fix is needed due to a very recent rename :( java/net/HttpURLPermission/URLTest.java renamed to java/net/URLPermission/URLTest.java Updated webrev: http://cr.openjdk.java.net/~dholmes/8026378/webrev.v2/ On 16/10/2013 2:19 AM, Mike Duigou wrote: > Thanks for this cleanup. > > Looks fine to me. Thanks for the review. > It is disappointing to see some of the tests disabled for compact1 or compact2 because they use unrelated functionality. Is any effort planned to eliminate unnecessary dependencies? This is up to the test owners. I have heard that the TestNG issue is being looked at. David ----- > Mike > > On Oct 14 2013, at 22:02 , David Holmes wrote: > >> http://cr.openjdk.java.net/~dholmes/8026378/webrev/ >> >> Trivial cleanup: >> >> Non-existent java/util/SummaryStatistics deleted from group jdk_stream >> >> Non-existent com/oracle/security deleted from jdk_security3 >> >> java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to needs_jre >> >> jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 >> >> java/util/Collection/ListDefaults.java renamed to java/util/List/ListDefaults.java >> >> Thanks, >> David > From mike.duigou at oracle.com Tue Oct 15 23:19:32 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 15 Oct 2013 16:19:32 -0700 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525DCC61.3080705@oracle.com> References: <525CCC6D.3020309@oracle.com> <525DCC61.3080705@oracle.com> Message-ID: The additional change looks fine. On Oct 15 2013, at 16:14 , David Holmes wrote: > An additional fix is needed due to a very recent rename :( > > java/net/HttpURLPermission/URLTest.java renamed to java/net/URLPermission/URLTest.java > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8026378/webrev.v2/ > > On 16/10/2013 2:19 AM, Mike Duigou wrote: >> Thanks for this cleanup. >> >> Looks fine to me. > > Thanks for the review. > >> It is disappointing to see some of the tests disabled for compact1 or compact2 because they use unrelated functionality. Is any effort planned to eliminate unnecessary dependencies? > > This is up to the test owners. I have heard that the TestNG issue is being looked at. So the root problem is that TestNG requires XML as it is currently being used? Mike > > David > ----- > >> Mike >> >> On Oct 14 2013, at 22:02 , David Holmes wrote: >> >>> http://cr.openjdk.java.net/~dholmes/8026378/webrev/ >>> >>> Trivial cleanup: >>> >>> Non-existent java/util/SummaryStatistics deleted from group jdk_stream >>> >>> Non-existent com/oracle/security deleted from jdk_security3 >>> >>> java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to needs_jre >>> >>> jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 >>> >>> java/util/Collection/ListDefaults.java renamed to java/util/List/ListDefaults.java >>> >>> Thanks, >>> David >> From jonathan.gibbons at oracle.com Tue Oct 15 22:58:43 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 22:58:43 +0000 Subject: hg: jdk8/tl/langtools: 8026564: import changes from type-annotations forest Message-ID: <20131015225846.A7F786242A@hg.openjdk.java.net> Changeset: b0c086cd4520 Author: jjg Date: 2013-10-15 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0c086cd4520 8026564: import changes from type-annotations forest Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/T7042623.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.java ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java - test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/OldArray.out ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out - test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateScoping.java + test/tools/javac/diags/examples/CantAnnotateScoping1.java - test/tools/javac/diags/examples/CantAnnotateStaticClass.java ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java From david.holmes at oracle.com Tue Oct 15 23:39:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 09:39:54 +1000 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: References: <525CCC6D.3020309@oracle.com> <525DCC61.3080705@oracle.com> Message-ID: <525DD24A.7080000@oracle.com> On 16/10/2013 9:19 AM, Mike Duigou wrote: > The additional change looks fine. Thanks. > > On Oct 15 2013, at 16:14 , David Holmes wrote: > >> An additional fix is needed due to a very recent rename :( >> >> java/net/HttpURLPermission/URLTest.java renamed to java/net/URLPermission/URLTest.java >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8026378/webrev.v2/ >> >> On 16/10/2013 2:19 AM, Mike Duigou wrote: >>> Thanks for this cleanup. >>> >>> Looks fine to me. >> >> Thanks for the review. >> >>> It is disappointing to see some of the tests disabled for compact1 or compact2 because they use unrelated functionality. Is any effort planned to eliminate unnecessary dependencies? >> >> This is up to the test owners. I have heard that the TestNG issue is being looked at. > > So the root problem is that TestNG requires XML as it is currently being used? Yes sax/xml. David > Mike > >> >> David >> ----- >> >>> Mike >>> >>> On Oct 14 2013, at 22:02 , David Holmes wrote: >>> >>>> http://cr.openjdk.java.net/~dholmes/8026378/webrev/ >>>> >>>> Trivial cleanup: >>>> >>>> Non-existent java/util/SummaryStatistics deleted from group jdk_stream >>>> >>>> Non-existent com/oracle/security deleted from jdk_security3 >>>> >>>> java/util/jar/Manifest/CreateManifest.java - moved from needs_jdk to needs_jre >>>> >>>> jdk/lambda/separate/Compiler.java - moved from needs_jdk to needs_compact3 >>>> >>>> java/util/Collection/ListDefaults.java renamed to java/util/List/ListDefaults.java >>>> >>>> Thanks, >>>> David >>> > From brian.burkhalter at oracle.com Tue Oct 15 23:47:39 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Tue, 15 Oct 2013 23:47:39 +0000 Subject: hg: jdk8/tl/jdk: 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Message-ID: <20131015234802.A3DAB6242E@hg.openjdk.java.net> Changeset: 3676f04e6553 Author: bpb Date: 2013-10-15 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3676f04e6553 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Summary: Modify UHE exception message for EAI_AGAIN failures. Reviewed-by: alanb, chegar, michaelm, dsamersoff Contributed-by: Brian Burkhalter ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c From david.holmes at oracle.com Wed Oct 16 00:02:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 10:02:55 +1000 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D516E.6040703@oracle.com> References: <525D516E.6040703@oracle.com> Message-ID: <525DD7AF.9040504@oracle.com> Hi Erik, Many thanks for jumping on this! On 16/10/2013 12:30 AM, Erik Joelsson wrote: > Currently the RMI stubs in the jdk are built with the newly built rmic > binary at the end of the build. This patch changes that and instead > builds a bootstrap version of the rmic classes, much like bootstrap > javac in langtools, which runs on the bootjdk, but generates classes for > the new jdk. The new solution is more friendly to cross compilation. > > A few notes on the patch: > > * In src/share/classes/sun/tools/tree/Node.java, I had to change a call > to a jdk8 only constructor in java.lang.InternalError. A better fix to preserve the cause is: throw new InternalError().initCause(e); > * The packages included when compiling rmic were just picked by > extending for each missing class until the compilation succeeded. If > someone knows of a crucial package or class that needs to be included, > please say so. > * I renamed a parameter to SetupJavaCompilation. I do not consider the > parameter a hack anymore, but a necessary option for this case. So should "Don't use this. " say "Use with care." or something like that? :) > * In RMICompilation, the dependency file is now a real touch file > instead of a virtual one. This was needed for proper dependencies in > GenerateClasses.gmk. > * All of corba is compiled twice since I have no idea which parts would > actually be needed. This doesn't add much build time since it can be run > effectively in parallel with the rest of the corba build. I don't understand the need for changes here given that this is Java compilation and it is already using GENERATE_OLDBYTECODE ?? > * I put the compilation of bootstrap rmic in GenerateClasses.gmk > directly instead of Tools.gmk. This was to not add much compile time, > since Tools.gmk is included and therefore parsed a lot. Seems okay - the proof of course is in the building. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 > Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ > > /Erik From david.holmes at oracle.com Wed Oct 16 00:04:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 10:04:46 +1000 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525D53CC.8030509@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: <525DD81E.70107@oracle.com> On 16/10/2013 12:40 AM, Alan Bateman wrote: > On 15/10/2013 15:30, Erik Joelsson wrote: >> Currently the RMI stubs in the jdk are built with the newly built rmic >> binary at the end of the build. This patch changes that and instead >> builds a bootstrap version of the rmic classes, much like bootstrap >> javac in langtools, which runs on the bootjdk, but generates classes >> for the new jdk. The new solution is more friendly to cross compilation. >> >> A few notes on the patch: >> >> * In src/share/classes/sun/tools/tree/Node.java, I had to change a >> call to a jdk8 only constructor in java.lang.InternalError. >> * The packages included when compiling rmic were just picked by >> extending for each missing class until the compilation succeeded. If >> someone knows of a crucial package or class that needs to be included, >> please say so. >> * I renamed a parameter to SetupJavaCompilation. I do not consider the >> parameter a hack anymore, but a necessary option for this case. >> * In RMICompilation, the dependency file is now a real touch file >> instead of a virtual one. This was needed for proper dependencies in >> GenerateClasses.gmk. >> * All of corba is compiled twice since I have no idea which parts >> would actually be needed. This doesn't add much build time since it >> can be run effectively in parallel with the rest of the corba build. >> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >> directly instead of Tools.gmk. This was to not add much compile time, >> since Tools.gmk is included and therefore parsed a lot. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >> >> /Erik > It's great to see a solution coming for this, it was always been > troublesome to run the newly built rmic. > > So what are the implications of this? I assume it means that we need to > be careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and > restrict API usage to what is available in the boot JDK - is that right? I think API restrictions already apply to the sun.tools packages - and both language and API restrictions apply to other build tools that are compiled using the boot JDK. David > -Alan. From david.holmes at oracle.com Wed Oct 16 00:06:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 10:06:55 +1000 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: <525DD89F.2020905@oracle.com> Hi Volker, On 16/10/2013 1:29 AM, Volker Simonis wrote: > Hi Erik, Alan, > > first of all I think this is a good change because it helps porters to > build a complete JDK even if the newly build rmic wouldn't run. > > On the other hand I'm a little bit concerned if this change still > allows it to bootstrap with a non-Oracle based bootstrap JDK. I > remember that we had some problems with IBM J9 as bootstrap JDK > because they have different default implementations of idlj and rmic > (see http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_) > > Fortunately, the IBM J9 also contains the original Oracle idlj and > rmic versions and with the old build it was possible to use them by > specifying the two variables: > > IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > com.sun.tools.corba.se.idl.toJavaPortable.Compile' > RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > sun.rmi.rmic.Main' > > I'm not sure if this is still possible with the new build system. > > By the way, the main problem why the IBM J9 idlj and rmic didn't work > out of the box were some command line options which were only > supported by the Oracle implementation. It would therefore be very > nice if you could completely remove such options from the build. As I understand it the rmic command (neither boot nor built) is never executed now, so as long as the boot JDK can compile and run the OpenJDK's rmic classes there should not be any problems. David ----- > And you can easily check this by trying the IBM J9 as bootstrap JDK on > Linux/x86_64. > > Thank you and best regards, > Volker > > > On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman wrote: >> On 15/10/2013 15:30, Erik Joelsson wrote: >>> >>> Currently the RMI stubs in the jdk are built with the newly built rmic >>> binary at the end of the build. This patch changes that and instead builds a >>> bootstrap version of the rmic classes, much like bootstrap javac in >>> langtools, which runs on the bootjdk, but generates classes for the new jdk. >>> The new solution is more friendly to cross compilation. >>> >>> A few notes on the patch: >>> >>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call to >>> a jdk8 only constructor in java.lang.InternalError. >>> * The packages included when compiling rmic were just picked by extending >>> for each missing class until the compilation succeeded. If someone knows of >>> a crucial package or class that needs to be included, please say so. >>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>> parameter a hack anymore, but a necessary option for this case. >>> * In RMICompilation, the dependency file is now a real touch file instead >>> of a virtual one. This was needed for proper dependencies in >>> GenerateClasses.gmk. >>> * All of corba is compiled twice since I have no idea which parts would >>> actually be needed. This doesn't add much build time since it can be run >>> effectively in parallel with the rest of the corba build. >>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk directly >>> instead of Tools.gmk. This was to not add much compile time, since Tools.gmk >>> is included and therefore parsed a lot. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>> >>> /Erik >> >> It's great to see a solution coming for this, it was always been troublesome >> to run the newly built rmic. >> >> So what are the implications of this? I assume it means that we need to be >> careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and restrict >> API usage to what is available in the boot JDK - is that right? >> >> -Alan. From david.holmes at oracle.com Wed Oct 16 00:12:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 10:12:00 +1000 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525DD7AF.9040504@oracle.com> References: <525D516E.6040703@oracle.com> <525DD7AF.9040504@oracle.com> Message-ID: <525DD9D0.7030803@oracle.com> On 16/10/2013 10:02 AM, David Holmes wrote: > Hi Erik, > > Many thanks for jumping on this! > > On 16/10/2013 12:30 AM, Erik Joelsson wrote: >> Currently the RMI stubs in the jdk are built with the newly built rmic >> binary at the end of the build. This patch changes that and instead >> builds a bootstrap version of the rmic classes, much like bootstrap >> javac in langtools, which runs on the bootjdk, but generates classes for >> the new jdk. The new solution is more friendly to cross compilation. >> >> A few notes on the patch: >> >> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call >> to a jdk8 only constructor in java.lang.InternalError. > > A better fix to preserve the cause is: > > throw new InternalError().initCause(e); That should be throw (InternalError) new InternalError().initCause(e); David ----- >> * The packages included when compiling rmic were just picked by >> extending for each missing class until the compilation succeeded. If >> someone knows of a crucial package or class that needs to be included, >> please say so. >> * I renamed a parameter to SetupJavaCompilation. I do not consider the >> parameter a hack anymore, but a necessary option for this case. > > So should "Don't use this. " say "Use with care." or something like > that? :) > >> * In RMICompilation, the dependency file is now a real touch file >> instead of a virtual one. This was needed for proper dependencies in >> GenerateClasses.gmk. >> * All of corba is compiled twice since I have no idea which parts would >> actually be needed. This doesn't add much build time since it can be run >> effectively in parallel with the rest of the corba build. > > I don't understand the need for changes here given that this is Java > compilation and it is already using GENERATE_OLDBYTECODE ?? > >> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >> directly instead of Tools.gmk. This was to not add much compile time, >> since Tools.gmk is included and therefore parsed a lot. > > Seems okay - the proof of course is in the building. > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >> >> /Erik From mandy.chung at oracle.com Wed Oct 16 00:42:29 2013 From: mandy.chung at oracle.com (Oracle) Date: Wed, 16 Oct 2013 08:42:29 +0800 Subject: Trivial RFR: 8026378: TEST_BUG: Clean up TEST.groups In-Reply-To: <525DCC61.3080705@oracle.com> References: <525CCC6D.3020309@oracle.com> <525DCC61.3080705@oracle.com> Message-ID: > On Oct 16, 2013, at 7:14 AM, David Holmes wrote: > > An additional fix is needed due to a very recent rename :( > > java/net/HttpURLPermission/URLTest.java renamed to java/net/URLPermission/URLTest.java > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8026378/webrev.v2/ The additional change looks fine with me. Mandy From david.holmes at oracle.com Wed Oct 16 00:54:53 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 16 Oct 2013 00:54:53 +0000 Subject: hg: jdk8/tl/jdk: 8026378: TEST_BUG: Clean up TEST.groups Message-ID: <20131016005509.13F4162431@hg.openjdk.java.net> Changeset: e33aea66caa3 Author: dholmes Date: 2013-10-15 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e33aea66caa3 8026378: TEST_BUG: Clean up TEST.groups Reviewed-by: mduigou, mchung, alanb ! test/TEST.groups From david.holmes at oracle.com Wed Oct 16 04:41:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 14:41:01 +1000 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> Message-ID: <525E18DD.2080604@oracle.com> Okay you have incited me to throw in my 2c :) I think the CME issue has been raised a number of times in the past (and if the below doesn't agree with what I've said in the past Hey! It's a brand new day! ;-) ) But first, Mike the missing spaces are creeping back in "if(xxx)" :) For Map I don't think looking for external concurrent modification and throwing CME is necessary or worthwhile. These are not thread-safe methods. That covers: - remove, replace and it implies that putIfAbsent should not check for or throw CME. For compute* and merge it is possible that the computation function modifies the Map - unlikely perhaps but possible - so CME here seems more reasonable. (As for forEach, replaceAll etc.) I fully agree with removing the retry loops in these non-concurrent implementations. That said it makes ConcurrentMap somewhat different to Map as it never throws CME even if it was an internal mutation. Aside: do you still need to re-list every unchecked exception when overriding (i.e. @throws foo {@inheritDoc}) to get them to show up in the subtype docs? I can't tell if this has been forgotten or whether the ConcurrentMap methods truly will never throw such exceptions. Cheers, David ----- On 16/10/2013 2:38 AM, Paul Sandoz wrote: > > On Oct 15, 2013, at 6:25 PM, Mike Duigou wrote: > >> >> On Oct 14 2013, at 02:32 , Paul Sandoz wrote: >> >>>> Virtually all the cases where CME is thrown in the "new" Map defaults are the points where previously the implementation would have looped/retried. >>>> >>> >>>>> For the cases where no function values are passed it has very limited value, we know it is effectively useless for non-current collections being modified concurrently. >>>> >>>> Understood. The alternative would be to GIGO these situations, return and ignore them. >>>> >>> >>> Yeah, unnecessarily complicates the code. >> >> It does detect legitimate errors and it makes me uncomfortable to just ignore them. >> > > It is not deterministic. > > Does HashMap's implementation of putIfAbsent throw a CME? > > >>>>> For the cases where a function value is passed and it modifies the map then it could have some value. But i wonder, for any non-looping function value accepting method on Map (anything other than forEach/replaceAll), whether it is just simpler to state: "if a function value modifies the entry under computation then this method may return incorrect results`". >>>> >>>> Modification of any other entry may have the same result. >>> >>> Yes, although IIUC modification, by the function value, of other entries will not interfere with that of operating on the entry under computation. A more general recommendation is the function values should be stateless. >>> >>> >>>> I suspect that modification by some other thread is as likely to be a problem as modification by the function. >>>> >>> >>> And under concurrent modification we cannot deterministically detect. CME in the non-concurrent collections is only useful for detecting serial modification due to inversion of control, and in these particular cases it is really very limited as to what it detects. >> >> True, but it generally doesn't impose any extra cost. The error detection happens as a side effect of necessary operations. >> > > There cost to code complexity. I would argue that additional complexity is not worth it given the limits of what can be detected. > > I guess you know my opinion: remove 'em. So i will be silent for a bit and see if anyone else speaks up :-) > > Paul. > >> I'd like to bring this set of changes to conclusion as soon as possible. >> >> Mike >> > From henry.jen at oracle.com Wed Oct 16 05:53:41 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 15 Oct 2013 22:53:41 -0700 Subject: RFR: 8025909: Lambda Library Spec Updates In-Reply-To: <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> References: <525DC308.9010803@oracle.com> <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> Message-ID: <525E29E5.8080406@oracle.com> On 10/15/2013 04:05 PM, Mike Duigou wrote: > Where is the null handling for methods like DoubleStream.allMatch() > described? I don't see an @throws NullPointerException if predicate > is null. The class level "functional interface parameters to methods, > unless otherwise specified, may not be null" instruction is removed > with reference to Stream docs. I hope this is sufficient notice. > The idea is to avoid duplicate documentation(clutering) by consolidate into reference of Stream and package documentation. It may not be obvious, but should be enough? Note that we state "must be non-null unless otherwise specified" but don't specify what would happen if null is passed. I think that's is intentionally ambiguous and allows some wiggle room here. Should we be more explicit on NPE? I prefer to leave it as is, so it's unspecified behavior if null is passed. > For allMatch/noneMatch I think the case where predicate is null and > the stream is empty is covered by "and the predicate is not > evaluated". > Right. That covers the empty case "does not evaluate the predicate", and we didn't "otherwise specified" about null, so in theory it still "must be non-null". Cheers, Henry > Mike > > On Oct 15 2013, at 15:34 , Henry Jen wrote: > >> Hi, >> >> Please kindly review the latest update on lambda library spec, and >> a few minor code clean up. >> >> Webrev and specdiff can be found at, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/webrev >> http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/specdiff >> >> This webrev also covers update that address JDK-8024179 as the >> spec update explains why reported scenario is expected. >> >> Cheers, Henry > From henry.jen at oracle.com Wed Oct 16 05:54:50 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 15 Oct 2013 22:54:50 -0700 Subject: RFR: 8025909: Lambda Library Spec Updates In-Reply-To: <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> References: <525DC308.9010803@oracle.com> <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> Message-ID: <525E2A2A.8010802@oracle.com> On 10/15/2013 04:05 PM, Mike Duigou wrote: > Where is the null handling for methods like DoubleStream.allMatch() > described? I don't see an @throws NullPointerException if predicate > is null. The class level "functional interface parameters to methods, > unless otherwise specified, may not be null" instruction is removed > with reference to Stream docs. I hope this is sufficient notice. > The idea is to avoid duplicate documentation(clutering) by consolidate into reference of Stream and package documentation. It may not as obvious, but should be enough? Note that we state "must be non-null unless otherwise specified" but don't specify what would happen if null is passed. I think that's is intentionally ambiguous and allows some wiggle room here. Should we be more explicit on NPE? I prefer to leave it as is, so it's unspecified behavior if null is passed. > For allMatch/noneMatch I think the case where predicate is null and > the stream is empty is covered by "and the predicate is not > evaluated". > Right. That covers the empty case "does not evaluate the predicate", and we didn't "otherwise specified" about null, so in theory it still "must be non-null". As we Cheers, Henry > Mike > > On Oct 15 2013, at 15:34 , Henry Jen wrote: > >> Hi, >> >> Please kindly review the latest update on lambda library spec, and >> a few minor code clean up. >> >> Webrev and specdiff can be found at, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/webrev >> http://cr.openjdk.java.net/~henryjen/ccc/8025909/0/specdiff >> >> This webrev also covers update that address JDK-8024179 as the >> spec update explains why reported scenario is expected. >> >> Cheers, Henry > From henry.jen at oracle.com Wed Oct 16 06:20:40 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 15 Oct 2013 23:20:40 -0700 Subject: RFR: 8025909: Lambda Library Spec Updates In-Reply-To: <525E29E5.8080406@oracle.com> References: <525DC308.9010803@oracle.com> <4CB5E03B-7509-4D6F-B127-4AFDC46C574D@oracle.com> <525E29E5.8080406@oracle.com> Message-ID: <525E3038.4010307@oracle.com> Apologize for the multiple copies, Thunderbird had issue with network, and resulting several copies sent. Sorry for the incident. Cheers, Henry On 10/15/2013 10:53 PM, Henry Jen wrote: > On 10/15/2013 04:05 PM, Mike Duigou wrote: >> Where is the null handling for methods like DoubleStream.allMatch() >> described? I don't see an @throws NullPointerException if predicate >> is null. The class level "functional interface parameters to methods, >> unless otherwise specified, may not be null" instruction is removed >> with reference to Stream docs. I hope this is sufficient notice. >> > > The idea is to avoid duplicate documentation(clutering) by consolidate > into reference of Stream and package documentation. It may not be > obvious, but should be enough? > From weijun.wang at oracle.com Wed Oct 16 06:40:36 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 16 Oct 2013 06:40:36 +0000 Subject: hg: jdk8/tl/jdk: 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Message-ID: <20131016064144.9D15162446@hg.openjdk.java.net> Changeset: a70aab9b373e Author: weijun Date: 2013-10-16 14:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a70aab9b373e 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/krb5/KrbCred.java From sundararajan.athijegannathan at oracle.com Wed Oct 16 06:54:54 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 16 Oct 2013 06:54:54 +0000 Subject: hg: jdk8/tl/nashorn: 7 new changesets Message-ID: <20131016065502.808F862447@hg.openjdk.java.net> Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6cb4f20d971f 8026309: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 8c617a092d68 Author: hannesw Date: 2013-10-14 11:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c617a092d68 8026016: too many relinks dominate avatar.js http benchmark Reviewed-by: sundar, jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026016.js + test/script/basic/JDK-8026016.js.EXPECTED Changeset: d155c4a7703c Author: attila Date: 2013-10-14 12:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d155c4a7703c 8026113: Nashorn arrays should automatically convert to Java arrays Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: 64e841576c68 Author: attila Date: 2013-10-15 15:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/64e841576c68 8026397: Fix ambiguity with array conversion, including passing JS NativeArrays in Java variable arity methods' vararg array position Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/messages.properties ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: aa452eb4a5d0 Author: hannesw Date: 2013-10-15 17:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa452eb4a5d0 8026367: Add a sync keyword to mozilla_compat Reviewed-by: sundar, attila, lagergren ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026367.js ! test/script/sandbox/loadcompat.js Changeset: b3ee112a328e Author: jlaskey Date: 2013-10-15 13:14 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b3ee112a328e 8026498: Revert: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 9a13e95cc40f Author: sundar Date: 2013-10-15 22:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9a13e95cc40f Merge From scolebourne at joda.org Wed Oct 16 08:09:38 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 16 Oct 2013 09:09:38 +0100 Subject: RFR 8025971 and 8026197 In-Reply-To: <525D98EB.1010105@oracle.com> References: <525D98EB.1010105@oracle.com> Message-ID: On 15 October 2013 20:35, Xueming Shen wrote: > Please help codereview the changes for > > 8025971: Remove Time-Zone IDs HST/EST/MST The method ZoneId.systemDefault() now does not match its specification: /** * Gets the system default time-zone. *

* This queries {@link TimeZone#getDefault()} to find the default time-zone * and converts it to a {@code ZoneId}. If the system default time-zone is changed, * then the result of this method will also change. * * @return the zone ID, not null * @throws DateTimeException if the converted zone ID has an invalid format * @throws ZoneRulesException if the converted zone region ID cannot be found */ public static ZoneId systemDefault() { return ZoneId.of(TimeZone.getDefault().getID(), SHORT_IDS); } This needs to be changed to: public static ZoneId systemDefault() { return TimeZone.getDefault().toZoneId(); } This fix is for a different issue - not the one described in the 8025971 bug report. I recommend opening a new issue. If you're not going to fix 8025971 (which I think you should) then that needs to be documented. Stephen From paul.sandoz at oracle.com Wed Oct 16 09:36:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Oct 2013 11:36:40 +0200 Subject: RFR : 8025910 : (s) Rename Stream.substream(long) -> skip(long) and remove substream(long, long) In-Reply-To: References: Message-ID: <2BB63994-736D-4F87-97FF-2AD6A73F3B79@oracle.com> Looks good with Henry's correction (that i missed the first time around!). Paul. On Oct 15, 2013, at 10:18 PM, Mike Duigou wrote: > Hello all; > > As promised on the lambda-libs-spec-experts mailing list I have prepared a changeset which renames the single arg substream() to skip() and remove the two arg substream() method (aka "slice"). > > The rationale behind these changes is: > > - skip() is easier for new users to locate than substream(). > - substream(long,long) has ambiguous semantics and duplicates skip().limit() > > http://cr.openjdk.java.net/~mduigou/JDK-8025910/1/webrev/ > http://cr.openjdk.java.net/~mduigou/JDK-8025910/1/specidff/overview-summary.html > > Cheers, > > Mike From daniel.fuchs at oracle.com Wed Oct 16 09:47:46 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Oct 2013 11:47:46 +0200 Subject: RFR 8026499: Root Logger level can be reset unexpectedly In-Reply-To: <525DC892.3020008@oracle.com> References: <525D71E2.4020501@oracle.com> <525DC892.3020008@oracle.com> Message-ID: <525E60C2.4030700@oracle.com> Hi Mandy, On 10/16/13 12:58 AM, Mandy Chung wrote: > > On 10/15/2013 9:48 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8026499: Root Logger level can be reset unexpectedly >> https://bugs.openjdk.java.net/browse/JDK-8026499 >> >> >> >> The issue here is that calling a method like e.g. URL.openConnection() >> will trigger the initialization of some platform logger, which could >> in turn cause the root logger to be lazilly added to the system context, >> which in turn causes the root logger's level to be reset with the >> value found in the configuration file (INFO). >> >> The fix is to not reinitialize the value of the logger's level if >> it already has been initialized. > > The change looks okay. When the root logger is added to the system > context, it considers it as a newly created logger and thus resetting > its level. The global logger should have the same issue as there is > only a single instance. I believe the logger's handler doesn't get > reset and level is the only issue. That was my analysis too :-) > > Logger.hasLocalLevel() doesn't seem to be necessary and it seems to be > more explicit to replace !logger.hasLocalLevel() with > logger.getLevel() == null I considered that but rejected it because getLevel() can be overridden, and what I really want to know is whether setLevel() has been called. The alternative would have been to declare a package 'setLevelIfAbsent()' method (but it would need to be invoked in doPrivileged) or to add a package getLevelObject() method, (which looked weird) or to expose levelObject - which I didn't want to do. Hence the hasLocalLevel() which I don't like very much but like better than the alternatives ;-) > It would also help to add a comment to explain the check. Right. // Do not reset the logger level if it has already been initialized > TestRootLoggerLevel.java - it may be good to also test the global logger. Good point. > line 70: I believe this line is not necessary (do you mean to do any > other checking and that's why you call LoggingSupport.getLogger?) In fact either line 70-71 or line 73-74 are enough to trigger the issue. What really triggers the issue however is the underlying call to LogManager.demandSystemLogger(). I just put both for good measure ;-) > I think the comment on the behavior before the fix (line 77-78) can be > removed and this may become not as relevant after this bug fix. Line 104 > - this permission may be needed in your early version of this test? can > be removed now? btw - should this test also run with no security manager? Yes and yes. Thanks for the review! > > Mandy > > From paul.sandoz at oracle.com Wed Oct 16 10:03:28 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Oct 2013 12:03:28 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <525E18DD.2080604@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> Message-ID: On Oct 16, 2013, at 6:41 AM, David Holmes wrote: > Okay you have incited me to throw in my 2c :) I think the CME issue has been raised a number of times in the past (and if the below doesn't agree with what I've said in the past Hey! It's a brand new day! ;-) ) > > But first, Mike the missing spaces are creeping back in "if(xxx)" :) > > For Map I don't think looking for external concurrent modification and throwing CME is necessary or worthwhile. These are not thread-safe methods. That covers: > - remove, replace > > and it implies that putIfAbsent should not check for or throw CME. > > For compute* and merge it is possible that the computation function modifies the Map - unlikely perhaps but possible - so CME here seems more reasonable. (As for forEach, replaceAll etc.) > > I fully agree with removing the retry loops in these non-concurrent implementations. > > That said it makes ConcurrentMap somewhat different to Map as it never throws CME even if it was an internal mutation. > HashMap.compute*/merge methods do not throw CME either. I suppose those methods could and do so beyond that of only the entry under computation. I think this really points to the fact that, for non-traversal, only concrete implementations are capable of reliably detecting a CME and therefore it's best to leave it up to those implementations should they choose to do so. Paul. > Aside: do you still need to re-list every unchecked exception when overriding (i.e. @throws foo {@inheritDoc}) to get them to show up in the subtype docs? I can't tell if this has been forgotten or whether the ConcurrentMap methods truly will never throw such exceptions. > > Cheers, > David > ----- From erik.joelsson at oracle.com Wed Oct 16 10:19:37 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Oct 2013 12:19:37 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525DD9D0.7030803@oracle.com> References: <525D516E.6040703@oracle.com> <525DD7AF.9040504@oracle.com> <525DD9D0.7030803@oracle.com> Message-ID: <525E6839.8020801@oracle.com> New webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.02/ * Changed Node.java as David suggested. * Added comment suggested by Martin to Setup.gmk, where the compiler setup is done. Couldn't think of a better place. * Changed comment in JavaCompilation. A note on Corba. While the corba classes are linked against the bootjdk APIs, the current compilation of those classes produce jdk8 version classfiles, which cannot be run on the bootjdk. That's why we have to compile two times, to produce jdk7 classfiles. /Erik On 2013-10-16 02:12, David Holmes wrote: > On 16/10/2013 10:02 AM, David Holmes wrote: >> Hi Erik, >> >> Many thanks for jumping on this! >> >> On 16/10/2013 12:30 AM, Erik Joelsson wrote: >>> Currently the RMI stubs in the jdk are built with the newly built rmic >>> binary at the end of the build. This patch changes that and instead >>> builds a bootstrap version of the rmic classes, much like bootstrap >>> javac in langtools, which runs on the bootjdk, but generates classes >>> for >>> the new jdk. The new solution is more friendly to cross compilation. >>> >>> A few notes on the patch: >>> >>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call >>> to a jdk8 only constructor in java.lang.InternalError. >> >> A better fix to preserve the cause is: >> >> throw new InternalError().initCause(e); > > That should be > > throw (InternalError) new InternalError().initCause(e); > > David > ----- > >>> * The packages included when compiling rmic were just picked by >>> extending for each missing class until the compilation succeeded. If >>> someone knows of a crucial package or class that needs to be included, >>> please say so. >>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>> parameter a hack anymore, but a necessary option for this case. >> >> So should "Don't use this. " say "Use with care." or something like >> that? :) >> >>> * In RMICompilation, the dependency file is now a real touch file >>> instead of a virtual one. This was needed for proper dependencies in >>> GenerateClasses.gmk. >>> * All of corba is compiled twice since I have no idea which parts would >>> actually be needed. This doesn't add much build time since it can be >>> run >>> effectively in parallel with the rest of the corba build. >> >> I don't understand the need for changes here given that this is Java >> compilation and it is already using GENERATE_OLDBYTECODE ?? >> >>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >>> directly instead of Tools.gmk. This was to not add much compile time, >>> since Tools.gmk is included and therefore parsed a lot. >> >> Seems okay - the proof of course is in the building. >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>> >>> /Erik From erik.joelsson at oracle.com Wed Oct 16 10:22:03 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Oct 2013 12:22:03 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: <525E68CB.4000602@oracle.com> On 2013-10-15 17:29, Volker Simonis wrote: > Hi Erik, Alan, > > first of all I think this is a good change because it helps porters to > build a complete JDK even if the newly build rmic wouldn't run. > > On the other hand I'm a little bit concerned if this change still > allows it to bootstrap with a non-Oracle based bootstrap JDK. I > remember that we had some problems with IBM J9 as bootstrap JDK > because they have different default implementations of idlj and rmic > (see http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_) > > Fortunately, the IBM J9 also contains the original Oracle idlj and > rmic versions and with the old build it was possible to use them by > specifying the two variables: > > IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > com.sun.tools.corba.se.idl.toJavaPortable.Compile' > RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar > sun.rmi.rmic.Main' > > I'm not sure if this is still possible with the new build system. > > By the way, the main problem why the IBM J9 idlj and rmic didn't work > out of the box were some command line options which were only > supported by the Oracle implementation. It would therefore be very > nice if you could completely remove such options from the build. > > And you can easily check this by trying the IBM J9 as bootstrap JDK on > Linux/x86_64. I tried building with J9, but it broke in Hotspot already so couldn't get to the relevant parts of the build. But as David pointed out, this should work as we aren't running the rmic or idlj in the bootjdk at all now. /Erik > Thank you and best regards, > Volker > > > On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman wrote: >> On 15/10/2013 15:30, Erik Joelsson wrote: >>> Currently the RMI stubs in the jdk are built with the newly built rmic >>> binary at the end of the build. This patch changes that and instead builds a >>> bootstrap version of the rmic classes, much like bootstrap javac in >>> langtools, which runs on the bootjdk, but generates classes for the new jdk. >>> The new solution is more friendly to cross compilation. >>> >>> A few notes on the patch: >>> >>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call to >>> a jdk8 only constructor in java.lang.InternalError. >>> * The packages included when compiling rmic were just picked by extending >>> for each missing class until the compilation succeeded. If someone knows of >>> a crucial package or class that needs to be included, please say so. >>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>> parameter a hack anymore, but a necessary option for this case. >>> * In RMICompilation, the dependency file is now a real touch file instead >>> of a virtual one. This was needed for proper dependencies in >>> GenerateClasses.gmk. >>> * All of corba is compiled twice since I have no idea which parts would >>> actually be needed. This doesn't add much build time since it can be run >>> effectively in parallel with the rest of the corba build. >>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk directly >>> instead of Tools.gmk. This was to not add much compile time, since Tools.gmk >>> is included and therefore parsed a lot. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>> >>> /Erik >> It's great to see a solution coming for this, it was always been troublesome >> to run the newly built rmic. >> >> So what are the implications of this? I assume it means that we need to be >> careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and restrict >> API usage to what is available in the boot JDK - is that right? >> >> -Alan. From david.holmes at oracle.com Wed Oct 16 10:28:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 20:28:42 +1000 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> Message-ID: <525E6A5A.6080301@oracle.com> On 16/10/2013 8:03 PM, Paul Sandoz wrote: > > On Oct 16, 2013, at 6:41 AM, David Holmes wrote: > >> Okay you have incited me to throw in my 2c :) I think the CME issue has been raised a number of times in the past (and if the below doesn't agree with what I've said in the past Hey! It's a brand new day! ;-) ) >> >> But first, Mike the missing spaces are creeping back in "if(xxx)" :) >> >> For Map I don't think looking for external concurrent modification and throwing CME is necessary or worthwhile. These are not thread-safe methods. That covers: >> - remove, replace >> >> and it implies that putIfAbsent should not check for or throw CME. >> >> For compute* and merge it is possible that the computation function modifies the Map - unlikely perhaps but possible - so CME here seems more reasonable. (As for forEach, replaceAll etc.) >> >> I fully agree with removing the retry loops in these non-concurrent implementations. >> >> That said it makes ConcurrentMap somewhat different to Map as it never throws CME even if it was an internal mutation. >> > > HashMap.compute*/merge methods do not throw CME either. I suppose those methods could and do so beyond that of only the entry under computation. I think this really points to the fact that, for non-traversal, only concrete implementations are capable of reliably detecting a CME and therefore it's best to leave it up to those implementations should they choose to do so. Perhaps HashMap's implementations should throw CME? But the possibility of CME has to be allowed for in the spec of the interfaced methods regardless. David > Paul. > > >> Aside: do you still need to re-list every unchecked exception when overriding (i.e. @throws foo {@inheritDoc}) to get them to show up in the subtype docs? I can't tell if this has been forgotten or whether the ConcurrentMap methods truly will never throw such exceptions. >> >> Cheers, >> David >> ----- > From david.holmes at oracle.com Wed Oct 16 10:35:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 20:35:23 +1000 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525E6839.8020801@oracle.com> References: <525D516E.6040703@oracle.com> <525DD7AF.9040504@oracle.com> <525DD9D0.7030803@oracle.com> <525E6839.8020801@oracle.com> Message-ID: <525E6BEB.8020801@oracle.com> Ship it! Quickly! :) Thanks, David On 16/10/2013 8:19 PM, Erik Joelsson wrote: > New webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.02/ > > * Changed Node.java as David suggested. > * Added comment suggested by Martin to Setup.gmk, where the compiler > setup is done. Couldn't think of a better place. > * Changed comment in JavaCompilation. > > A note on Corba. While the corba classes are linked against the bootjdk > APIs, the current compilation of those classes produce jdk8 version > classfiles, which cannot be run on the bootjdk. That's why we have to > compile two times, to produce jdk7 classfiles. > > /Erik > > On 2013-10-16 02:12, David Holmes wrote: >> On 16/10/2013 10:02 AM, David Holmes wrote: >>> Hi Erik, >>> >>> Many thanks for jumping on this! >>> >>> On 16/10/2013 12:30 AM, Erik Joelsson wrote: >>>> Currently the RMI stubs in the jdk are built with the newly built rmic >>>> binary at the end of the build. This patch changes that and instead >>>> builds a bootstrap version of the rmic classes, much like bootstrap >>>> javac in langtools, which runs on the bootjdk, but generates classes >>>> for >>>> the new jdk. The new solution is more friendly to cross compilation. >>>> >>>> A few notes on the patch: >>>> >>>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call >>>> to a jdk8 only constructor in java.lang.InternalError. >>> >>> A better fix to preserve the cause is: >>> >>> throw new InternalError().initCause(e); >> >> That should be >> >> throw (InternalError) new InternalError().initCause(e); >> >> David >> ----- >> >>>> * The packages included when compiling rmic were just picked by >>>> extending for each missing class until the compilation succeeded. If >>>> someone knows of a crucial package or class that needs to be included, >>>> please say so. >>>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>>> parameter a hack anymore, but a necessary option for this case. >>> >>> So should "Don't use this. " say "Use with care." or something like >>> that? :) >>> >>>> * In RMICompilation, the dependency file is now a real touch file >>>> instead of a virtual one. This was needed for proper dependencies in >>>> GenerateClasses.gmk. >>>> * All of corba is compiled twice since I have no idea which parts would >>>> actually be needed. This doesn't add much build time since it can be >>>> run >>>> effectively in parallel with the rest of the corba build. >>> >>> I don't understand the need for changes here given that this is Java >>> compilation and it is already using GENERATE_OLDBYTECODE ?? >>> >>>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >>>> directly instead of Tools.gmk. This was to not add much compile time, >>>> since Tools.gmk is included and therefore parsed a lot. >>> >>> Seems okay - the proof of course is in the building. >>> >>> Thanks, >>> David >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>>> >>>> /Erik > From chris.hegarty at oracle.com Wed Oct 16 11:07:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Oct 2013 12:07:56 +0100 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525E6BEB.8020801@oracle.com> References: <525D516E.6040703@oracle.com> <525DD7AF.9040504@oracle.com> <525DD9D0.7030803@oracle.com> <525E6839.8020801@oracle.com> <525E6BEB.8020801@oracle.com> Message-ID: <525E738C.70702@oracle.com> On 16/10/2013 11:35, David Holmes wrote: > Ship it! Quickly! :) +1 looks good to me. Thanks Erik, -Chris. > > Thanks, > David > > On 16/10/2013 8:19 PM, Erik Joelsson wrote: >> New webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.02/ >> >> * Changed Node.java as David suggested. >> * Added comment suggested by Martin to Setup.gmk, where the compiler >> setup is done. Couldn't think of a better place. >> * Changed comment in JavaCompilation. >> >> A note on Corba. While the corba classes are linked against the bootjdk >> APIs, the current compilation of those classes produce jdk8 version >> classfiles, which cannot be run on the bootjdk. That's why we have to >> compile two times, to produce jdk7 classfiles. >> >> /Erik >> >> On 2013-10-16 02:12, David Holmes wrote: >>> On 16/10/2013 10:02 AM, David Holmes wrote: >>>> Hi Erik, >>>> >>>> Many thanks for jumping on this! >>>> >>>> On 16/10/2013 12:30 AM, Erik Joelsson wrote: >>>>> Currently the RMI stubs in the jdk are built with the newly built rmic >>>>> binary at the end of the build. This patch changes that and instead >>>>> builds a bootstrap version of the rmic classes, much like bootstrap >>>>> javac in langtools, which runs on the bootjdk, but generates classes >>>>> for >>>>> the new jdk. The new solution is more friendly to cross compilation. >>>>> >>>>> A few notes on the patch: >>>>> >>>>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a >>>>> call >>>>> to a jdk8 only constructor in java.lang.InternalError. >>>> >>>> A better fix to preserve the cause is: >>>> >>>> throw new InternalError().initCause(e); >>> >>> That should be >>> >>> throw (InternalError) new InternalError().initCause(e); >>> >>> David >>> ----- >>> >>>>> * The packages included when compiling rmic were just picked by >>>>> extending for each missing class until the compilation succeeded. If >>>>> someone knows of a crucial package or class that needs to be included, >>>>> please say so. >>>>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>>>> parameter a hack anymore, but a necessary option for this case. >>>> >>>> So should "Don't use this. " say "Use with care." or something like >>>> that? :) >>>> >>>>> * In RMICompilation, the dependency file is now a real touch file >>>>> instead of a virtual one. This was needed for proper dependencies in >>>>> GenerateClasses.gmk. >>>>> * All of corba is compiled twice since I have no idea which parts >>>>> would >>>>> actually be needed. This doesn't add much build time since it can be >>>>> run >>>>> effectively in parallel with the rest of the corba build. >>>> >>>> I don't understand the need for changes here given that this is Java >>>> compilation and it is already using GENERATE_OLDBYTECODE ?? >>>> >>>>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >>>>> directly instead of Tools.gmk. This was to not add much compile time, >>>>> since Tools.gmk is included and therefore parsed a lot. >>>> >>>> Seems okay - the proof of course is in the building. >>>> >>>> Thanks, >>>> David >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>>>> >>>>> /Erik >> From dmitry.degrave at oracle.com Wed Oct 16 11:17:36 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Wed, 16 Oct 2013 11:17:36 +0000 Subject: hg: jdk8/tl/jdk: 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Message-ID: <20131016111755.CC42F62456@hg.openjdk.java.net> Changeset: 9ea6a464c147 Author: igerasim Date: 2013-10-15 21:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ea6a464c147 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Summary: Properly close PipedStreams. Additional testing for malformed input Reviewed-by: darcy, sherman ! test/java/util/zip/GZIP/GZIPInZip.java From paul.sandoz at oracle.com Wed Oct 16 11:26:11 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Oct 2013 13:26:11 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <525E6A5A.6080301@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> <525E6A5A.6080301@oracle.com> Message-ID: <19D18902-695B-4039-94C0-C9375118975B@oracle.com> On Oct 16, 2013, at 12:28 PM, David Holmes wrote: > On 16/10/2013 8:03 PM, Paul Sandoz wrote: >> >> On Oct 16, 2013, at 6:41 AM, David Holmes wrote: >> >>> Okay you have incited me to throw in my 2c :) I think the CME issue has been raised a number of times in the past (and if the below doesn't agree with what I've said in the past Hey! It's a brand new day! ;-) ) >>> >>> But first, Mike the missing spaces are creeping back in "if(xxx)" :) >>> >>> For Map I don't think looking for external concurrent modification and throwing CME is necessary or worthwhile. These are not thread-safe methods. That covers: >>> - remove, replace >>> >>> and it implies that putIfAbsent should not check for or throw CME. >>> >>> For compute* and merge it is possible that the computation function modifies the Map - unlikely perhaps but possible - so CME here seems more reasonable. (As for forEach, replaceAll etc.) >>> >>> I fully agree with removing the retry loops in these non-concurrent implementations. >>> >>> That said it makes ConcurrentMap somewhat different to Map as it never throws CME even if it was an internal mutation. >>> >> >> HashMap.compute*/merge methods do not throw CME either. I suppose those methods could and do so beyond that of only the entry under computation. I think this really points to the fact that, for non-traversal, only concrete implementations are capable of reliably detecting a CME and therefore it's best to leave it up to those implementations should they choose to do so. > > Perhaps HashMap's implementations should throw CME? > Perhaps, seems to be going beyond the call of duty. My inclination is not to bother. It becomes most relevant with forEach since the consumer will have side-effects that might make it easier to unintentionally slip in a modification to the map itself. > But the possibility of CME has to be allowed for in the spec of the interfaced methods regardless. > Ideally by not say anything :-) otherwise perhaps a variant of the following: "If a function value passed to an operation of a non-concurrent map modifies the contents of that map then the result of that operation is undefined. An implementation may throw {@link ConcurrentModificationException} in such cases and if so that behaviour should be documented." Paul. From Alan.Bateman at oracle.com Wed Oct 16 11:37:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Oct 2013 12:37:26 +0100 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525DD81E.70107@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> <525DD81E.70107@oracle.com> Message-ID: <525E7A76.4010503@oracle.com> On 16/10/2013 01:04, David Holmes wrote: > > I think API restrictions already apply to the sun.tools packages - and > both language and API restrictions apply to other build tools that are > compiled using the boot JDK. Yes for build tools but not sun.tools.** in general (the change to sun.tools.tree.Node wouldn't have been required otherwise). In any case, the main point is that any usages of new APIs need to be caught when compiling them as they would otherwise be more difficult to diagnose if rmic were to fail in the build. From what I can see then it looks right. -Alan. From Alan.Bateman at oracle.com Wed Oct 16 11:40:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Oct 2013 12:40:24 +0100 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> Message-ID: <525E7B28.70401@oracle.com> On 15/10/2013 16:29, Volker Simonis wrote: > : > > By the way, the main problem why the IBM J9 idlj and rmic didn't work > out of the box were some command line options which were only > supported by the Oracle implementation. It would therefore be very > nice if you could completely remove such options from the build. > > And you can easily check this by trying the IBM J9 as bootstrap JDK on > Linux/x86_64. > If I understand correctly then this shouldn't be an issue with Erik's changes, right? That is, the changes mean the newly built rmic is executed (on the boot JDK). Or maybe you mean there are other calls to rmic that use rmic in the boot JDK? -Alan From Alan.Bateman at oracle.com Wed Oct 16 11:46:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Oct 2013 12:46:16 +0100 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <525819D0.4060302@oracle.com> Message-ID: <525E7C88.9040405@oracle.com> On 15/10/2013 21:58, Brian Burkhalter wrote: > Pursuant to comments on the submitted CCC request, the patch previously approved for this issue has been revised: > > http://cr.openjdk.java.net/~bpb/7179567/webrev.6/ > > The difference is that the URLClassLoader constructors and newInstance() methods no longer throw a NPE if the URL array parameter is non-null but contains at least one null element. The javadoc and test have been adjusted accordingly. > > A new issue https://bugs.openjdk.java.net/browse/JDK-8026517 has been filed to track adding a test for a null element in the URL array parameter. This latter issue is not presently scheduled to be addressed in JDK 8. > > Thanks, > > Brian This version looks okay too. For JDK-8026517 then you could add a note to say that the tests for it are in the NullURLTest.java test case, alternatively remove the commented-out tests and leave it to when JDK-8026517 is re-examined. -Alan. From david.holmes at oracle.com Wed Oct 16 11:52:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 21:52:25 +1000 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <19D18902-695B-4039-94C0-C9375118975B@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> <525E6A5A.6080301@oracle.com> <19D18902-695B-4039-94C0-C9375118975B@oracle.com> Message-ID: <525E7DF9.9020901@oracle.com> On 16/10/2013 9:26 PM, Paul Sandoz wrote: > > On Oct 16, 2013, at 12:28 PM, David Holmes wrote: > >> On 16/10/2013 8:03 PM, Paul Sandoz wrote: >>> >>> On Oct 16, 2013, at 6:41 AM, David Holmes wrote: >>> >>>> Okay you have incited me to throw in my 2c :) I think the CME issue has been raised a number of times in the past (and if the below doesn't agree with what I've said in the past Hey! It's a brand new day! ;-) ) >>>> >>>> But first, Mike the missing spaces are creeping back in "if(xxx)" :) >>>> >>>> For Map I don't think looking for external concurrent modification and throwing CME is necessary or worthwhile. These are not thread-safe methods. That covers: >>>> - remove, replace >>>> >>>> and it implies that putIfAbsent should not check for or throw CME. >>>> >>>> For compute* and merge it is possible that the computation function modifies the Map - unlikely perhaps but possible - so CME here seems more reasonable. (As for forEach, replaceAll etc.) >>>> >>>> I fully agree with removing the retry loops in these non-concurrent implementations. >>>> >>>> That said it makes ConcurrentMap somewhat different to Map as it never throws CME even if it was an internal mutation. >>>> >>> >>> HashMap.compute*/merge methods do not throw CME either. I suppose those methods could and do so beyond that of only the entry under computation. I think this really points to the fact that, for non-traversal, only concrete implementations are capable of reliably detecting a CME and therefore it's best to leave it up to those implementations should they choose to do so. >> >> Perhaps HashMap's implementations should throw CME? >> > > Perhaps, seems to be going beyond the call of duty. My inclination is not to bother. It becomes most relevant with forEach since the consumer will have side-effects that might make it easier to unintentionally slip in a modification to the map itself. I think there is a lot to be said for consistency. At present it seems we don't have a clear idea on how these methods should be spec'd or how the implementations should behave. >> But the possibility of CME has to be allowed for in the spec of the interfaced methods regardless. >> > > Ideally by not say anything :-) otherwise perhaps a variant of the following: Not saying anything doesn't permit CME to be thrown. > "If a function value passed to an operation of a non-concurrent map modifies the contents of that map then the result of that operation is undefined. An implementation may throw {@link ConcurrentModificationException} in such cases and if so that behaviour should be documented." I don't think it is the Java spirit to allow for undefined behaviour. Wouldn't: @throws CME if the modifies the map and this is detected by the implementation give the same flexibility while not being so obviously flimsy? I prefer to see exception info on methods as much as practical - with NPE being the obvious exception (no pun intended). David ----- > Paul. > From dl at cs.oswego.edu Wed Oct 16 11:58:47 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 16 Oct 2013 07:58:47 -0400 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <19D18902-695B-4039-94C0-C9375118975B@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> <525E6A5A.6080301@oracle.com> <19D18902-695B-4039-94C0-C9375118975B@oracle.com> Message-ID: <525E7F77.3050702@cs.oswego.edu> On 10/16/2013 07:26 AM, Paul Sandoz wrote: > > On Oct 16, 2013, at 12:28 PM, David Holmes wrote: > >> On 16/10/2013 8:03 PM, Paul Sandoz wrote: >>> >>> HashMap.compute*/merge methods do not throw CME either. I suppose those >>> methods could and do so beyond that of only the entry under computation. >>> I think this really points to the fact that, for non-traversal, only >>> concrete implementations are capable of reliably detecting a CME and >>> therefore it's best to leave it up to those implementations should they >>> choose to do so. >> >> Perhaps HashMap's implementations should throw CME? >> > > Perhaps, seems to be going beyond the call of duty. My inclination is not to > bother. It becomes most relevant with forEach since the consumer will have > side-effects that might make it easier to unintentionally slip in a > modification to the map itself. > > >> But the possibility of CME has to be allowed for in the spec of the >> interfaced methods regardless. >> > A variant of this issue came up a year or so ago for JDK8 ConcurrentHashMap.compute*/merge: What happens if the lambda side-effects by modifying some other map element? Because CHM (sometimes) uses fine-grained locks, it is possible for two such operations from different threads could cause a deadlock. We put in wording saying that the methods are allowed to throw exceptions in this case (rather than deadlock) but they currently don't catch all such errors. Which seems analogous to the non-concurrent case, so maybe similar wording could be used at Map level. CHM: * @throws IllegalStateException if the computation detectably * attempts a recursive update to this map that would * otherwise never complete Map? * @throws IllegalStateException if the computation detectably * attempts a secondary update to this map that would * otherwise never complete or perform an inconsistent update -Doug From mikael.auno at oracle.com Wed Oct 16 12:04:21 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 16 Oct 2013 14:04:21 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> References: <516E9DB9.8020009@oracle.com> <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> Message-ID: <525E80C5.6040802@oracle.com> This bug got a bit lost from my radar after vacation, but I've picked it again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering. Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java. The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/. Thanks, Mikael On 2013-05-28 08:46, Staffan Larsen wrote: > Looks good. > > You could optimize it a bit by not doing the Arrays.asList() on every > methodExit event. > > /Staffan > > On 17 apr 2013, at 15:03, Mikael Auno > wrote: > >> Hi, I'd like some reviews on >> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for >> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). >> >> The issue here is that when MethodExitReturnValuesTest hooks into >> MethodExit events through JDI it uses an exclude list to filter out >> classes from which it is not interested in these events. This is >> bound to break over and over again as new features are added to the >> JDK. I've changed the test to use an include list instead, >> containing only the handful of classes the test is actually >> interested in. >> >> Thanks, >> Mikael > From erik.joelsson at oracle.com Wed Oct 16 12:25:42 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 12:25:42 +0000 Subject: hg: jdk8/tl: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Message-ID: <20131016122542.E4D5B62459@hg.openjdk.java.net> Changeset: af81988013b5 Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk From paul.sandoz at oracle.com Wed Oct 16 12:34:00 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Oct 2013 14:34:00 +0200 Subject: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair In-Reply-To: <525E7DF9.9020901@oracle.com> References: <679CE08E-E954-414F-8717-255CBCCF64D5@oracle.com> <15BB8B5C-40C2-434C-927B-ABA6163740C9@oracle.com> <70D2641C-CBC2-4FC7-AB08-F3982C13BDE3@oracle.com> <4240E03C-C0A8-468F-8A11-300D51C72FFA@oracle.com> <274E77B8-E27A-4DF0-81E3-3E9A23CA44F2@oracle.com> <525E18DD.2080604@oracle.com> <525E6A5A.6080301@oracle.com> <19D18902-695B-4039-94C0-C9375118975B@oracle.com> <525E7DF9.9020901@oracle.com> Message-ID: <433CAECD-9BC6-4CD8-BD61-B140FDE01097@oracle.com> On Oct 16, 2013, at 1:52 PM, David Holmes wrote: >>> Perhaps HashMap's implementations should throw CME? >>> >> >> Perhaps, seems to be going beyond the call of duty. My inclination is not to bother. It becomes most relevant with forEach since the consumer will have side-effects that might make it easier to unintentionally slip in a modification to the map itself. > > I think there is a lot to be said for consistency. Yes, i was proposing to consistently not support it for non-traversal methods :-) > At present it seems we don't have a clear idea on how these methods should be spec'd or how the implementations should behave. > >>> But the possibility of CME has to be allowed for in the spec of the interfaced methods regardless. >>> >> >> Ideally by not say anything :-) otherwise perhaps a variant of the following: > > Not saying anything doesn't permit CME to be thrown. > Yeah, it was my poor attempt at a joke wishing CME would go away :-) >> "If a function value passed to an operation of a non-concurrent map modifies the contents of that map then the result of that operation is undefined. An implementation may throw {@link ConcurrentModificationException} in such cases and if so that behaviour should be documented." > > I don't think it is the Java spirit to allow for undefined behaviour. OK. > Wouldn't: > > @throws CME if the modifies the map and this is detected by the implementation > > give the same flexibility while not being so obviously flimsy? Reluctantly yes; i know it's more of a style thing but it is somewhat tiresome for each and every method receiving a function value to repeat the same thing. Paul. > I prefer to see exception info on methods as much as practical - with NPE being the obvious exception (no pun intended). > From daniel.fuchs at oracle.com Wed Oct 16 12:35:41 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Oct 2013 14:35:41 +0200 Subject: RFR 8026499: Root Logger level can be reset unexpectedly In-Reply-To: <525E60C2.4030700@oracle.com> References: <525D71E2.4020501@oracle.com> <525DC892.3020008@oracle.com> <525E60C2.4030700@oracle.com> Message-ID: <525E881D.2030308@oracle.com> Hi, Please find below the new revision: - added comment in LogManager - renamed hasLocalLevel() into isLevelInitialized() - fixed the test, including Logger.global, with and without SecurityManager -- daniel On 10/16/13 11:47 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 10/16/13 12:58 AM, Mandy Chung wrote: >> >> On 10/15/2013 9:48 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a fix for: >>> >>> 8026499: Root Logger level can be reset unexpectedly >>> https://bugs.openjdk.java.net/browse/JDK-8026499 >>> >>> >>> >>> The issue here is that calling a method like e.g. URL.openConnection() >>> will trigger the initialization of some platform logger, which could >>> in turn cause the root logger to be lazilly added to the system context, >>> which in turn causes the root logger's level to be reset with the >>> value found in the configuration file (INFO). >>> >>> The fix is to not reinitialize the value of the logger's level if >>> it already has been initialized. >> >> The change looks okay. When the root logger is added to the system >> context, it considers it as a newly created logger and thus resetting >> its level. The global logger should have the same issue as there is >> only a single instance. I believe the logger's handler doesn't get >> reset and level is the only issue. > > That was my analysis too :-) > >> >> Logger.hasLocalLevel() doesn't seem to be necessary and it seems to be >> more explicit to replace !logger.hasLocalLevel() with >> logger.getLevel() == null > > I considered that but rejected it because getLevel() can be overridden, > and what I really want to know is whether setLevel() has been called. > > The alternative would have been to declare a package > 'setLevelIfAbsent()' method (but it would need to be invoked > in doPrivileged) or to add a package getLevelObject() method, > (which looked weird) or to expose levelObject - which I didn't want > to do. > > Hence the hasLocalLevel() which I don't like very much but like better > than the alternatives ;-) > > >> It would also help to add a comment to explain the check. > > Right. > > // Do not reset the logger level if it has already been initialized > > >> TestRootLoggerLevel.java - it may be good to also test the global logger. > > Good point. > >> line 70: I believe this line is not necessary (do you mean to do any >> other checking and that's why you call LoggingSupport.getLogger?) > > In fact either line 70-71 or line 73-74 are enough to trigger the issue. > What really triggers the issue however is the underlying call to > LogManager.demandSystemLogger(). I just put both for good measure ;-) > > >> I think the comment on the behavior before the fix (line 77-78) can be >> removed and this may become not as relevant after this bug fix. Line 104 >> - this permission may be needed in your early version of this test? can >> be removed now? btw - should this test also run with no security >> manager? > > Yes and yes. > > Thanks for the review! > >> >> Mandy >> >> > From erik.joelsson at oracle.com Wed Oct 16 12:26:00 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 12:26:00 +0000 Subject: hg: jdk8/tl/corba: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Message-ID: <20131016122602.1BA126245A@hg.openjdk.java.net> Changeset: 438c54c148a6 Author: erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/438c54c148a6 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/BuildCorba.gmk From volker.simonis at gmail.com Wed Oct 16 12:51:23 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Oct 2013 14:51:23 +0200 Subject: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar In-Reply-To: <525E68CB.4000602@oracle.com> References: <525D516E.6040703@oracle.com> <525D53CC.8030509@oracle.com> <525E68CB.4000602@oracle.com> Message-ID: On Wed, Oct 16, 2013 at 12:22 PM, Erik Joelsson wrote: > > On 2013-10-15 17:29, Volker Simonis wrote: >> >> Hi Erik, Alan, >> >> first of all I think this is a good change because it helps porters to >> build a complete JDK even if the newly build rmic wouldn't run. >> >> On the other hand I'm a little bit concerned if this change still >> allows it to bootstrap with a non-Oracle based bootstrap JDK. I >> remember that we had some problems with IBM J9 as bootstrap JDK >> because they have different default implementations of idlj and rmic >> (see >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_) >> >> Fortunately, the IBM J9 also contains the original Oracle idlj and >> rmic versions and with the old build it was possible to use them by >> specifying the two variables: >> >> IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar >> com.sun.tools.corba.se.idl.toJavaPortable.Compile' >> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar >> sun.rmi.rmic.Main' >> >> I'm not sure if this is still possible with the new build system. >> >> By the way, the main problem why the IBM J9 idlj and rmic didn't work >> out of the box were some command line options which were only >> supported by the Oracle implementation. It would therefore be very >> nice if you could completely remove such options from the build. >> >> And you can easily check this by trying the IBM J9 as bootstrap JDK on >> Linux/x86_64. > > I tried building with J9, but it broke in Hotspot already so couldn't get to > the relevant parts of the build. Just realised this myself and opened "JDK-8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files" (https://bugs.openjdk.java.net/browse/JDK-8026703). The fix will follow in the next minutes... Unfortunately, this is not the last problem before getting to the "relevant parts" :( > But as David pointed out, this should work > as we aren't running the rmic or idlj in the bootjdk at all now. This sounds good! But nevertheless I'll try to verify it if I'll manage to get around the other build issues :) > > /Erik > >> Thank you and best regards, >> Volker >> >> >> On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman >> wrote: >>> >>> On 15/10/2013 15:30, Erik Joelsson wrote: >>>> >>>> Currently the RMI stubs in the jdk are built with the newly built rmic >>>> binary at the end of the build. This patch changes that and instead >>>> builds a >>>> bootstrap version of the rmic classes, much like bootstrap javac in >>>> langtools, which runs on the bootjdk, but generates classes for the new >>>> jdk. >>>> The new solution is more friendly to cross compilation. >>>> >>>> A few notes on the patch: >>>> >>>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a call >>>> to >>>> a jdk8 only constructor in java.lang.InternalError. >>>> * The packages included when compiling rmic were just picked by >>>> extending >>>> for each missing class until the compilation succeeded. If someone knows >>>> of >>>> a crucial package or class that needs to be included, please say so. >>>> * I renamed a parameter to SetupJavaCompilation. I do not consider the >>>> parameter a hack anymore, but a necessary option for this case. >>>> * In RMICompilation, the dependency file is now a real touch file >>>> instead >>>> of a virtual one. This was needed for proper dependencies in >>>> GenerateClasses.gmk. >>>> * All of corba is compiled twice since I have no idea which parts would >>>> actually be needed. This doesn't add much build time since it can be run >>>> effectively in parallel with the rest of the corba build. >>>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk >>>> directly >>>> instead of Tools.gmk. This was to not add much compile time, since >>>> Tools.gmk >>>> is included and therefore parsed a lot. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021 >>>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/ >>>> >>>> /Erik >>> >>> It's great to see a solution coming for this, it was always been >>> troublesome >>> to run the newly built rmic. >>> >>> So what are the implications of this? I assume it means that we need to >>> be >>> careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and >>> restrict >>> API usage to what is available in the boot JDK - is that right? >>> >>> -Alan. > > From erik.joelsson at oracle.com Wed Oct 16 13:53:54 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 13:53:54 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131016135529.AE6586245F@hg.openjdk.java.net> Changeset: 76a7c0bc74fd Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateClasses.gmk ! makefiles/Setup.gmk ! src/share/classes/sun/tools/tree/Node.java Changeset: e078fd8a78f6 Author: erikj Date: 2013-10-16 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e078fd8a78f6 Merge From andreas.lundblad at oracle.com Wed Oct 16 14:00:08 2013 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 16 Oct 2013 07:00:08 -0700 (PDT) Subject: RFR: 8004912: Repeating annotations - getAnnotationsByType is not working as expected Message-ID: <90b2a540-6237-446c-8389-e5d18597df47@default> Hi, Please review the fix for JDK-8004912 and JDK-8019420 below. Description: The behavior of Class.get[Declared]AnnotationsByType was wrong. These methods delegate to sun.reflect.annotation.AnnotationSupport which has been rewritten. NonInheritableContainee.java is added and contains the test referred to in JDK-8019420. RepeatedUnitTest.java have been updated to include the test cases in JDK-8004912. There are more tests available in tl/langtools/test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java (NB. this file is in the langtools repo) Link to web review: http://cr.openjdk.java.net/~alundblad/8019420-and-8004912/ Link to bug reports: https://bugs.openjdk.java.net/browse/JDK-8004912 https://bugs.openjdk.java.net/browse/JDK-8019420 -- Andreas Lundblad From rob.mckenna at oracle.com Wed Oct 16 14:08:57 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 16 Oct 2013 14:08:57 +0000 Subject: hg: jdk8/tl/jdk: 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Message-ID: <20131016140923.AF19E62460@hg.openjdk.java.net> Changeset: d8eec0e3a023 Author: robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8eec0e3a023 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Reviewed-by: chegar, alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/Socket/GetLocalAddress.java From michael.fang at oracle.com Wed Oct 16 14:43:03 2013 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 16 Oct 2013 07:43:03 -0700 Subject: RFR: 8025255: (tz) Support tzdata2013g In-Reply-To: <525CD04E.60003@oracle.com> References: <5256ABDD.9060900@oracle.com> <5257846F.6020509@oracle.com> <52583852.3010004@oracle.com> <52584F89.3030007@oracle.com> <525A74B3.6040300@oracle.com> <525BBB02.9060805@oracle.com> <525CC53A.6020809@oracle.com> <525CD04E.60003@oracle.com> Message-ID: <525EA5F7.6090507@oracle.com> Hi Aleksej and Masayoshi, The translation of the timezone names are correct according to the translators. So, the files in your webrev look fine to me. thanks, -michael On 13?10?14? 10:19 ??, Michael Fang wrote: > Hi Masayoshi, > > I am not sure if the changes are correct. I need to check with > translation team for confirmation. There are several other similar cases. > > About the upper casing, it's the way Oracle translation team returns > their translation. Nothing we can do about it. I think it's a way for > them to know if anyone else has changed the translation without their > knowledge. Translation changes has to be done on their translation > memory by them instead of manually editing the resource files. > Otherwise, the next time they deliver l10n resource files back, the > manually changes will not be there. > > thanks, > > -michael > > On 13?10?14? 09:31 ??, Masayoshi Okutsu wrote: >> Hi Aleksej and Michael, >> >> TimeZoneNames_de.java: >> - String DARWIN[] = new String[] {"Zentrale Normalzeit (Northern Territory)", "CST", >> + String DARWIN[] = new String[] {"Central Normalzeit (Northern Territory)", "CST", >> Is this change correct? >> >> BTW, is there any reason to change lower case to upper case for the >> \uxxxx notation? >> >> Thanks, >> Masayoshi >> >> On 10/14/2013 6:36 PM, Aleksej Efimov wrote: >>> Hi, >>> The second item is dropped - I was informed in a parallel review >>> thread, that I can have one approval from a Reviewer and another >>> approval[s] from members. >>> The hg patch was updated and located here: >>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch >>> >>> >>> Can I ask for a sponsor help to push this fix? >>> >>> Thank you and Best Regards, >>> Aleksej >>> >>> On 10/13/2013 02:23 PM, Aleksej Efimov wrote: >>>> Michael, Masayoshi, >>>> >>>> Looks like, we can commit this changes with following items in mind: >>>> 1. Generic names in TimeZoneNames_*.java should be added as part of >>>> JDK-8025051 resolution. >>>> 2. I need another one approval from a JDK 8 reviewer for this one. >>>> >>>> Anyway, the hg changeset patch can be found here: >>>> http://cr.openjdk.java.net/~aefimov/8025255/8/8025255_jdk8.patch >>>> >>>> Best Regards, >>>> Aleksej >>>> >>>> On 10/12/2013 12:43 AM, Michael Fang wrote: >>>>> Hi Aleksej, >>>>> >>>>> Yes, you are right. They can be handled separately. Thanks! >>>>> >>>>> Regards, >>>>> >>>>> Michael >>>>> Sent from my iPhone >>>>> >>>>> On Oct 11, 2013, at 12:20 PM, Aleksej Efimov wrote: >>>>> >>>>>> Hi Michael, >>>>>> As I can see this topic was touched a little here:http://mail.openjdk.java.net/pipermail/threeten-dev/2012-December/000314.html. AFAIU from the above discussion the CLDR generic names were translated in all locales, but the legacy JRE time zone names doesn't contain this translations. And actually we already have opened bug for this task:https://bugs.openjdk.java.net/browse/JDK-8025051. I will work on it right after the tzdata update and it will include this changes. >>>>>> But anyway, it's not highly related to tzdata updates. I think, this two processes can go separately. Do you agree? >>>>>> >>>>>> Thanks and Best Regards, >>>>>> Aleksej >>>>>> >>>>>> On 11.10.2013 21:41, Michael Fang wrote: >>>>>>> Hi Aleksej, >>>>>>> >>>>>>> I took a look at the localized TimeZoneNames_*.java files. They do not contain generic time zone names for JSR310... >>>>>>> >>>>>>> I think we can file a separate bug to track that issue. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> -michael >>>>>>> >>>>>>> On 13?10?10? 09:54 ??, Masayoshi Okutsu wrote: >>>>>>>> Hi Aleksej, >>>>>>>> >>>>>>>> Here are my review comments. >>>>>>>> >>>>>>>> - The copyright header of the data files shouldn't be removed. >>>>>>>> >>>>>>>> - TimeZoneNames.java: >>>>>>>> >>>>>>>> - "Middle Europe Time", "MET"}}, >>>>>>>> + "MET", "MET"}}, >>>>>>>> >>>>>>>> I don't think the long name should be changed. >>>>>>>> >>>>>>>> I didn't review the localized TimeZoneNames_*.java files. If L10N Team is OK with them, I'm fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Masayoshi >>>>>>>> >>>>>>>> On 10/10/2013 10:30 PM, Aleksej Efimov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please, review the changes [1] needed to address the tz data update in JDK 8 from tzdata2013d to tzdata2013g. >>>>>>>>> >>>>>>>>> The brief list of changes: >>>>>>>>> 1. tzdata2013g data was integrated to tzdb data files (make/sun/javazic/tzdata/* changes) and to sun/util/calendar test data files (test/sun/util/calendar/zi/tzdata/* changes). >>>>>>>>> 2. a) Updates to long time zone names >>>>>>>>> b) Updates to short name changes to address corresponding changes in tzdata2013e(WIT/CIT/EIT/WARST -> WIB/WITA/WIT/ART) >>>>>>>>> c) Removed unused ACT[] array >>>>>>>>> d) Added "Europe/Busingen" time zone name >>>>>>>>> All this changes a)->d) relates to src/share/classes/sun/util/resources/TimeZoneNames*.java files >>>>>>>>> >>>>>>>>> The following tests were executed on JDK 8 with fix: >>>>>>>>> test/java/util/TimeZone >>>>>>>>> test/java/util/Calendar >>>>>>>>> test/java/util/Formatter >>>>>>>>> test/sun/util/calendar >>>>>>>>> test/java/time >>>>>>>>> >>>>>>>>> Testing result: All test passed >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Aleksej >>>>>>>>> >>>>>>>>> [1]http://cr.openjdk.java.net/~aefimov/8025255/8/webrev.00/ >>> >> From pbenedict at apache.org Wed Oct 16 15:13:07 2013 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 16 Oct 2013 10:13:07 -0500 Subject: JavaDoc is indenting documented annotations Message-ID: If you look at the current classes (b111) that have documented annotations, the first annotation is correctly left-aligned but all others are indented by one space. If this is already reported, my apologies; if not, please confirm. Example: http://download.java.net/jdk8/docs/api/java/lang/FunctionalInterface.html -- Cheers, Paul From daniel.fuchs at oracle.com Wed Oct 16 15:22:37 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 16 Oct 2013 15:22:37 +0000 Subject: hg: jdk8/tl/jdk: 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Message-ID: <20131016152401.B019A62465@hg.openjdk.java.net> Changeset: 445667b19e32 Author: dfuchs Date: 2013-10-16 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445667b19e32 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Reviewed-by: psandoz, mchung, alanb, chegar ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java From pavel.punegov at oracle.com Wed Oct 16 16:31:48 2013 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 16 Oct 2013 20:31:48 +0400 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <525D9B2A.2020109@oracle.com> References: <1888522.a2LG2QfRuS@trisuli> <5717680.T8GSN6ymjz@work-dell> <525D9B2A.2020109@oracle.com> Message-ID: <13685006.dSYo2Jo7FK@work-dell> Alan, I've updated the fix. New changes are: 1. Make processB fail if interrupted, 2. Replace Error throwing by RuntimeException. Here is a link to webrev: http://cr.openjdk.java.net/~robm/8024660/webrev.02/[1] On Tue, 15 of Oct 2013 20:44:42 Alan Bateman wrote: > On 15/10/2013 16:46, Pavel Punegov wrote: >> Anyone to review this? >> >> Alan, do you have any updates on this? > > The only thing is the catching of InterruptedException where it should > be a test failure if that happens. However I'm okay with what you have > (and Rob has agreed to sponsor this one). > > -Alan. -- Thanks, Pavel Punegov -------- [1] http://cr.openjdk.java.net/%7Erobm/8024660/webrev.02/ From kumar.x.srinivasan at oracle.com Wed Oct 16 16:41:14 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 16 Oct 2013 09:41:14 -0700 Subject: RFR: 8026504: [asm] update internal ASM to the Beta version In-Reply-To: <525DAF2E.8070209@oracle.com> References: <525DAF2E.8070209@oracle.com> Message-ID: <525EC1AA.90604@oracle.com> Hello, As per Nashorn teams request, I have also run the octane test, and it passes. I need reviewers from Lambda, Nashorn and ASM projects to approve this. Thanks Kumar > Hello, > > Please review refreshing the internal ASM sources to ASM_5_0_BETA, > I have run all the lambda test-ng tests using the lambda repo as well > as the nashorn > regression tests and test262parallel. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8026504 > > Webrev: > http://cr.openjdk.java.net/~ksrini/8026504/webrev/ > > Thanks > Kumar > > > From Alan.Bateman at oracle.com Wed Oct 16 16:50:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Oct 2013 17:50:15 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <13685006.dSYo2Jo7FK@work-dell> References: <1888522.a2LG2QfRuS@trisuli> <5717680.T8GSN6ymjz@work-dell> <525D9B2A.2020109@oracle.com> <13685006.dSYo2Jo7FK@work-dell> Message-ID: <525EC3C7.4050702@oracle.com> On 16/10/2013 17:31, Pavel Punegov wrote: > > Alan, > > I've updated the fix. New changes are: > > 1. Make processB fail if interrupted, > > 2. Replace Error throwing by RuntimeException. > > Here is a link to webrev: > > http://cr.openjdk.java.net/~robm/8024660/webrev.02/ > > > Thanks for that, I'm happy now. Rob - are you going to push this for Pavel? From brian.burkhalter at oracle.com Wed Oct 16 17:03:09 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Oct 2013 10:03:09 -0700 Subject: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE In-Reply-To: <525E7C88.9040405@oracle.com> References: <4A5E9F89-840C-4DB0-9989-5CFF9807FF7D@oracle.com> <524E0D4B.8050601@oracle.com> <5AB3A3D5-7B0F-4B19-BE47-EB4E8FB3807A@oracle.com> <935D328F-6035-46B1-9346-13BD954480FC@oracle.com> <5253E7C8.3030707@oracle.com> <52552AB9.803@oracle.com> <52561FB6.1060301@oracle.com> <7F7F9DC0-F6CF-4816-BDA9-5E8585A1346E@oracle.com> <845A9886-54B8-4162-A1FD-DF0FFF024CDB@oracle.com> <525778B9.5040208@oracle.com> <525819D0.4060302@oracle.com> <525E7C88.9040405@oracle.com> Message-ID: <6F2F1C03-75E3-4407-8503-90443A9BE570@oracle.com> On Oct 16, 2013, at 4:46 AM, Alan Bateman wrote: > This version looks okay too. For JDK-8026517 then you could add a note to say that the tests for it are in the NullURLTest.java test case, alternatively remove the commented-out tests and leave it to when JDK-8026517 is re-examined. I'll update 8026517 with a note about the test and integrate this change after the CCC request has been approved. Thanks, Brian From rob.mckenna at oracle.com Wed Oct 16 17:37:13 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 16 Oct 2013 18:37:13 +0100 Subject: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds In-Reply-To: <525EC3C7.4050702@oracle.com> References: <1888522.a2LG2QfRuS@trisuli> <5717680.T8GSN6ymjz@work-dell> <525D9B2A.2020109@oracle.com> <13685006.dSYo2Jo7FK@work-dell> <525EC3C7.4050702@oracle.com> Message-ID: <525ECEC9.7010504@oracle.com> Yup. -Rob On 16/10/13 17:50, Alan Bateman wrote: > On 16/10/2013 17:31, Pavel Punegov wrote: >> >> Alan, >> >> I've updated the fix. New changes are: >> >> 1. Make processB fail if interrupted, >> >> 2. Replace Error throwing by RuntimeException. >> >> Here is a link to webrev: >> >> http://cr.openjdk.java.net/~robm/8024660/webrev.02/ >> >> >> > Thanks for that, I'm happy now. > > Rob - are you going to push this for Pavel? From dmitry.nadezhin at gmail.com Wed Oct 16 17:46:21 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Wed, 16 Oct 2013 21:46:21 +0400 Subject: RFC 6910473: BigInteger negative bit length, value range, and future prospects In-Reply-To: References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com> <51D38710.30804@oracle.com> <524B2670.9050700@bbs.darktech.org> <524B89F1.7090602@bbs.darktech.org> <6C439E28-AA0C-4C86-AFB0-22E9DE564D2B@oracle.com> <0A722FED-1A87-4E68-B500-1F69034F0767@oracle.com> Message-ID: Thank you, Paul. I tried to combine your and Joe's suggestions in the updated WebRev: http://cr.openjdk.java.net/~bpb/6910473/webrev.2/ -Dima On Tue, Oct 15, 2013 at 12:20 PM, Paul Sandoz wrote: > Hi, > > I took a look at the patch, but i am not an expert in this area. > > On BigInteger: > > 99 * @implNote > 100 * BigInteger constructors and operations throw {@code > ArithmeticException} when > 101 * the result is out of the supported range. The supported range in > JDK 8 is > 102 * -2{@code Integer.MAX_VALUE} to > 103 * 2{@code Integer.MAX_VALUE}, exclusive. > > I suggest changing to: > > @implNote > BigInteger constructors and operations throw {@code ArithmeticException} > when > the result is out of the supported range of -2{@code > Integer.MAX_VALUE} > (exclusive) to 2{@code Integer.MAX_VALUE} (exclusive). > > I don't think it is worth declaring @throws ArithmeticException for all > relevant constructors and operations. This is likely to be noise for most > people and the implNote is sufficient. > > Paul. > > On Oct 15, 2013, at 2:27 AM, Brian Burkhalter > wrote: > > > Ping! > > > > This proposal could use more comments, not to mention review(s). > > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html > > > > Thanks, > > > > Brian > > > > On Oct 3, 2013, at 5:58 PM, Brian Burkhalter wrote: > > > >> I have reviewed this proposed change a couple of times in its current > form and it looks good to me. > >> > >> It would be good to see some comments about the general concept from > BigInt cognoscenti, and from (a) Reviewer(s) as concerns the @implNote > addition as well as the new ArithmeticExceptions added at several points in > the javadoc. > > > > From jonathan.gibbons at oracle.com Wed Oct 16 17:49:47 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Oct 2013 17:49:47 +0000 Subject: hg: jdk8/tl/langtools: 8026704: Build failure with --enable-debug Message-ID: <20131016174953.24F266246F@hg.openjdk.java.net> Changeset: d7e155f874a7 Author: jjg Date: 2013-10-16 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d7e155f874a7 8026704: Build failure with --enable-debug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - test/tools/javac/lambda/LocalVariableTable.java From daniel.fuchs at oracle.com Wed Oct 16 18:50:18 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 16 Oct 2013 18:50:18 +0000 Subject: hg: jdk8/tl/jdk: 8013839: Enhance Logger API for handling of resource bundles; ... Message-ID: <20131016185101.EFBBA62472@hg.openjdk.java.net> Changeset: 2ef43f3a901c Author: dfuchs Date: 2013-10-16 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ef43f3a901c 8013839: Enhance Logger API for handling of resource bundles 4814565: (rb) add method to get basename from a ResourceBundle Summary: adds Logger.setResourceBundle(ResourceBundle) and ResourceBundle.getBaseBundleName() Reviewed-by: mchung, naoto ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle_fr.java + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle.properties + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle_fr.java + test/java/util/logging/Logger/logrb/resources/PropertyBundle.properties + test/java/util/logging/Logger/logrb/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle_fr.java + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle.properties + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle_fr.properties From huizhe.wang at oracle.com Wed Oct 16 18:53:49 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 16 Oct 2013 11:53:49 -0700 Subject: RFR (JAXP) : 8015243 : SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI. Message-ID: <525EE0BD.2050802@oracle.com> Hi, This is a conformance issue. The issue is that a JCK test fails since invalid URI such as "//" was not caught. The fix is to check and allow empty authority only if there's non empty path, query component or fragment identifier. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8015243/webrev/ Thanks, Joe From mike.duigou at oracle.com Wed Oct 16 20:12:51 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 16 Oct 2013 20:12:51 +0000 Subject: hg: jdk8/tl/jdk: 8025910: rename substream(long) -> skip and remove substream(long, long) Message-ID: <20131016201329.3606C6247F@hg.openjdk.java.net> Changeset: cf9cb3d241a3 Author: mduigou Date: 2013-10-16 13:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf9cb3d241a3 8025910: rename substream(long) -> skip and remove substream(long,long) Reviewed-by: psandoz, henryjen ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java From roger.riggs at oracle.com Wed Oct 16 20:15:53 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 16 Oct 2013 16:15:53 -0400 Subject: Please Review javadoc cleanup 8026516 Message-ID: <525EF3F9.7090909@oracle.com> Hi, Javadoc cleanup to satisfy javadoc -Xlint. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/ Thanks, Roger From mike.duigou at oracle.com Wed Oct 16 20:22:02 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 16 Oct 2013 13:22:02 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <521DDAD7.9000701@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> Message-ID: Hello all; With the imminent promotion of JTReg 4.1b07 it's possible to finally consider completing this changeset! http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/ This updated webrev includes handling of the shared library permissions. Thanks, Mike On Aug 28 2013, at 04:11 , Alan Bateman wrote: > On 28/08/2013 00:17, Mike Duigou wrote: >> Hello all; >> >> I have updated the changeset for this issue based upon feedback from the earlier version. As a result of intervening work this version contains even more cleanup. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/ >> >> Since the last revision: >> >> - One open issue remains--handling of shared_library_permissions. The proposed patch uses a pattern rule, "jdk_%", rather than explicit make targets. This means the knowledge of which targets required shared_library_permissions has been lost. The shared_library_permissions target could be run unconditionally as part of prep but I am uncertain if this is reasonable. Alternatives? >> >> - The previously proposed behaviour of writing testoutput to the current directory if not ALT_OUTPUTDIR is provided has been changed in response to feedback. Output will now be written to jdk/testoutput and this directory has been added to the .hgignore. Since most people are expected to use only the root repo make which sets ALT_OUTPUTDIR it is not expected that this change will make any difference for most users. >> >> As before, testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. This changeset will not be integrated until after the next JTReg promotion. >> >> Mike >> > The updated webrev looks good to me too although I expect the output location will be visited again in the future. > > (I like Kelly's suggestion for hazard pay for those working on these make files). > > -Alan. From mike.duigou at oracle.com Wed Oct 16 20:30:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 16 Oct 2013 13:30:16 -0700 Subject: Please Review javadoc cleanup 8026516 In-Reply-To: <525EF3F9.7090909@oracle.com> References: <525EF3F9.7090909@oracle.com> Message-ID: <050C7A81-AE57-4F75-BFEE-75655AACC756@oracle.com> Looks fine. To make things easier I reviewed the patch rather than the individual file diffs. Mike On Oct 16 2013, at 13:15 , roger riggs wrote: > Hi, > > Javadoc cleanup to satisfy javadoc -Xlint. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/ > > Thanks, Roger > From eric.mccorkle at oracle.com Wed Oct 16 20:33:46 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 16 Oct 2013 20:33:46 +0000 Subject: hg: jdk8/tl/langtools: 8026286: Improper locking of annotation queues causes assertion failures.; ... Message-ID: <20131016203408.AFEED62487@hg.openjdk.java.net> Changeset: 7f6481e5fe3a Author: emc Date: 2013-10-16 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7f6481e5fe3a 8026286: Improper locking of annotation queues causes assertion failures. 8026063: Calls to annotate.flush() cause incorrect type annotations to be generated. Summary: Fix locking in ClassReader.java Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/annotations/typeAnnotations/TestAnonInnerInstance1.java ! test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java From joe.darcy at oracle.com Wed Oct 16 20:35:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Oct 2013 13:35:36 -0700 Subject: Please Review javadoc cleanup 8026516 In-Reply-To: <525EF3F9.7090909@oracle.com> References: <525EF3F9.7090909@oracle.com> Message-ID: <525EF898.70804@oracle.com> Hi Roger, Looks good; approved to go back. Thanks, -Joe On 10/16/2013 1:15 PM, roger riggs wrote: > Hi, > > Javadoc cleanup to satisfy javadoc -Xlint. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/ > > Thanks, Roger > From Lance.Andersen at oracle.com Wed Oct 16 20:37:01 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 16 Oct 2013 16:37:01 -0400 Subject: Please Review javadoc cleanup 8026516 In-Reply-To: <525EF3F9.7090909@oracle.com> References: <525EF3F9.7090909@oracle.com> Message-ID: Hi Roger, I think what you have done is OK. I do have questions on should more be done in general so that we use

(as I thought that was no required vs just a solo

?). As I started to look through some of the JDBC warnings, I saw more tags that I thought should have been reported by doclint as there were no closing

. I see similar scenarios in for example Instant.java Trying to figure out how much we really need to do Best Lance On Oct 16, 2013, at 4:15 PM, roger riggs wrote: > Hi, > > Javadoc cleanup to satisfy javadoc -Xlint. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026516/ > > Thanks, Roger > -------------- 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 sean.coffey at oracle.com Wed Oct 16 20:21:42 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 16 Oct 2013 20:21:42 +0000 Subject: hg: jdk8/tl/jdk: 8025255: (tz) Support tzdata2013g Message-ID: <20131016202214.A84AF62480@hg.openjdk.java.net> Changeset: 60e3cdbe8cdf Author: aefimov Date: 2013-10-13 14:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf 8025255: (tz) Support tzdata2013g Reviewed-by: okutsu, mfang ! 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/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.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/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab From roger.riggs at oracle.com Wed Oct 16 20:50:45 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 16 Oct 2013 16:50:45 -0400 Subject: Please Review javadoc cleanup 8026516 In-Reply-To: References: <525EF3F9.7090909@oracle.com> Message-ID: <525EFC25.80900@oracle.com> Hi Lance, The empty

tag is because in most cases it precedes a