hg: jdk8/tl/jdk: 8023954: MBean*Info.equals: throw NPE

Changeset: 8708569b5524 Author:sjiang Date: 2013-09-18 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8708569b5524 8023954: MBean*Info.equals: throw NPE Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/

RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation

Hi, Please review the webrev at http://cr.openjdk.java.net/~henryjen/ccc/8023524/0/webrev/ This webrev enable writing generated classes for lambda to disk at a directory specified with -Djdk.internal.lambda.dumpProxyClasses. The directory has to be an existing writable directory, otherwise, a me

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

On 09/18/2013 02:08 AM, Brian Burkhalter wrote: The proposed patch has been updated at the same location: http://cr.openjdk.java.net/~bpb/8024331/. Thanks, Brian looks good. Rémi On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote: I'll make the various updates and repost.

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

The proposed patch has been updated at the same location: http://cr.openjdk.java.net/~bpb/8024331/. Thanks, Brian On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote: > I'll make the various updates and repost.

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

On Sep 17, 2013, at 2:33 PM, Mike Duigou wrote: > The Map/Defaults.java changes only test HashMap. It should probably be > extended to test most/all of the other implementations. OK I will add those. > I have some worry that the superfluous assignment of the > Objects.requireNonNull() result

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

On Sep 17, 2013, at 3:00 PM, Remi Forax wrote: > apart from > foo(Object.requireNonNull(var)) > or > this.var = Objects.requireNonNull(var) in a constructor, > > I think that > Object.requireNonNull(var); > is more readable than > var = Object.requireNonNull(var); I don't feel strongly about

RFR: 8023339 & 8023340 : (xs) Refine throws UOE/NPE Conditions

Hello all; Another, hopefully final, attempt at refining the @throws UOE javadoc for Collections.removeIf and the @throws UOE and NPE javadoc for List.replaceAll(). This cycle adopts the verbiage suggested by Paul Sandoz in the last round of 8023339. Both changesets are combined into a single

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

On 09/17/2013 11:33 PM, Mike Duigou wrote: The Map/Defaults.java changes only test HashMap. It should probably be extended to test most/all of the other implementations. I have some worry that the superfluous assignment of the Objects.requireNonNull() result might have a non-negligible cost.

RFR: 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists

Hi, Please help the small update to the test case tools/jar/ChangeDir.java, which might fail if the "dedicated" test directory /tmp/a exists and the user does not have privilege to delete/clean it up. The proposed change here is to use a random file name (from File.getTempFile()) for the top tes

Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

The Map/Defaults.java changes only test HashMap. It should probably be extended to test most/all of the other implementations. I have some worry that the superfluous assignment of the Objects.requireNonNull() result might have a non-negligible cost. Mike On Sep 17 2013, at 13:49 , Brian Burkh

Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent

Please review this proposed patch at your convenience. Summary:Explicitly check for null remappingFunction parameter (and clean up similar code for consistency). Issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024331 Webrev: http://cr.openjdk.java.net/~bpb/8024

hg: jdk8/tl/langtools: 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL

Changeset: fdfbc5f0c4ed Author:jjg Date: 2013-09-17 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdfbc5f0c4ed 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 9/17/13 10:32 AM, cowwoc wrote: Hi, Has this been any new progress on this thread? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480 I have sent my feedback a couple weeks ago on this proposed patch but haven't heard back from Nick. You asked at

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

On Sep 17, 2013, at 11:19 AM, Sergey Kuksenko wrote: > On 09/17/2013 04:41 AM, John Rose wrote: >> The algorithmic change (string cache) is acceptable, although it will tend >> to increase footprint somewhat. > I don't think that it would be visible footprint increasing. MethodTypes > are int

Review: demos for try-with-resources feature

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.

Review: lamda expressions and bulk data operations on collections.

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.

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

Ok, I've tried this out with my app in the sandbox. I can confirm that opening a file dialog (NSSavePanel underneath), with a directory pointing to the Container's Documents directory (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the s

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

Hi, Has this been any new progress on this thread? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480 I'd like to second Jörn concerns that shipping JDK8 (less than a month to go!) without a fix would be extremely problematic. The performance impact

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

On 09/17/2013 04:41 AM, John Rose wrote: > The algorithmic change (string cache) is acceptable, although it will tend to > increase footprint somewhat. I don't think that it would be visible footprint increasing. MethodTypes are interned by implementation, so I don't expect that this "overhead"

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

Miran, are you on schedule to push this fix into jdk8/tl ? I'd like to get it ported to jdk7u also. If no push is pending for jdk8 from jaxws group, I might go ahead and push the fix to jdk. We have a testcase in different repo to catch any sync issues if necessary. regards, Sean. On 03/09/

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

On Sep 17 2013, at 00:21 , David Holmes wrote: > Hi Mike, > > Looks like there is one test that knows it has to exercise the alt-rt.jar > version: > > ./java/util/TreeMap/Clone.java > > * @run main/othervm Clone > * @run main/othervm -XX:+AggressiveOpts Clone > > but it's harmless to leave t

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

+1, good riddance to this, which has caused other woes. Thanks! Kumar Hello all; This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations)

Re: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load

Rob, Thanks for backporting this fix. Looks good to me. Mandy On 9/14/2013 4:32 PM, Rob McKenna wrote: ...and the actual webrev: http://cr.openjdk.java.net/~robm/7123493/webrev.01/ -Rob On 15/09/13 00:21, Rob McKenna wrote: Hi

Re: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows

Hi Alan! On 15.09.2013 23:49, Alan Bateman wrote: On 15/09/2013 12:06, Ivan Gerasimov wrote: : I decided to check whether this test really detects the failure, and run JPRT job with the new test but no fix included. Unfortunately, the new test *does not* fail with unmodified jdk. The same t

hg: jdk8/tl/jdk: 7097386: Correct error in Predicate javadoc example

Changeset: 657482758408 Author:lancea Date: 2013-09-17 07:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/657482758408 7097386: Correct error in Predicate javadoc example Reviewed-by: alanb, shade ! src/share/classes/javax/sql/rowset/Predicate.java

Re: RFR(M): 8024265: Enable new build on AIX (jdk part)

Hi Erik, thank for the review! On Tue, Sep 17, 2013 at 9:09 AM, Erik Joelsson wrote: > Hello Volker, > > This looks good to me. I think the mapfile situation could be solved better, > but your solution is probably the simplest, at least if you anticipate using > them in the future. Yes, you're

RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH NODE LIST OF LENGTH =1 IN JAXP

Hi Everyone, There is a bug [1] in JAXP about transformation of one-item sized node list: When the length of nodelist which is passed to a XSLT extension function is 1, the node gotten from the node list becomes null. New test illustrates this issue [2]. Full webrev with proposed fix can be fou

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

On 09/17/2013 04:41 AM, John Rose wrote: > But, please don't hand-inline methods (checkPtype, checkSlotCount). > That is usually the wrong answer. If there is a JIT inlining > decision that isn't going right, we need to fix that, not distort the > Java code. I thought this issue is one of those r

Re: review request 7097386: Correct error in Predicate javadoc example --- Still need an approval from a reviewer

On Sep 17, 2013, at 7:14 AM, Alan Bateman wrote: > On 17/09/2013 11:55, Lance Andersen - Oracle wrote: >> Hi Folks, >> >> Aleksey has been kind enough to review this change. Still need the blessing >> of a reviewer to put this back... >> >> any takers :-) > It looks okay although if is this i

Re: Fwd: review request 7097386: Correct error in Predicate javadoc example --- Still need an approval from a reviewer

On 17/09/2013 11:55, Lance Andersen - Oracle wrote: Hi Folks, Aleksey has been kind enough to review this change. Still need the blessing of a reviewer to put this back... any takers :-) It looks okay although if is this is sample code that we expect developers to copy then we could do more,

Fwd: review request 7097386: Correct error in Predicate javadoc example --- Still need an approval from a reviewer

Hi Folks, Aleksey has been kind enough to review this change. Still need the blessing of a reviewer to put this back... any takers :-) Best Lance Begin forwarded message: > From: Lance Andersen - Oracle > Date: September 16, 2013 7:12:09 AM EDT > To: Aleksey Shipilev > Cc: core-libs-dev Co

RFR: 8007072: Update Core Reflection for Type Annotations to match latest spec

Hi, Here is an update to the javadoc and implementation of reflection for type annotations. The biggest change is an update to the javadoc of Class and Executable to match return types of the getGeneric* functions. That is, when getGenericFoo returns an empty array getAnnotatedFoo should return a

Re: RFR: 8014659: NPG: performance counters for compressed klass space

Hi Staffan, On 2013-09-12, Staffan Larsen wrote: > Looks good (I'll take your word that the nasty awk scripts are correct...). thanks for the review! On 2013-09-12, Staffan Larsen wrote: > I think you should have included serviceability-dev on this review request. Agree, I'm adding them as part

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

On 09/17/2013 04:16 AM, Mike Duigou wrote: > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ I, for one who is responsible for eliminating the need for alt-rt.jar, greatly applaud this change. -Aleksey.

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

The changes look fine to me too. With such a trivial change to hotspot it may be possible to push this through TL? Trivially, and separate to this change, I can see further cleanup opportunities [1], as well as some tests that ref alt-rt.jar [2] [3]. Not that I really care (but I know other

Re: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load

Hi Rob, I can confirm that this is a faithful backport of JDK8 fix. I'm glad that it could be made without too much hassle, since there were other changes to JDK8 Proxy code before that fix (some of them, I can see, have been backported already)... Regards, Peter On 09/15/2013 01:32 AM, Rob

Re: RFR(M): 8024265: Enable new build on AIX (jdk part)

On Mon, Sep 16, 2013 at 11:32 PM, Vladimir Kozlov wrote: > Volker, > > You need different bug ID for these JDK changes. > 8024265 (top level changes) is already fixed: > > https://bugs.openjdk.java.net/browse/JDK-8024265 > Erik Joelsson told me that it is possible to use the same BugID for relate

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

Hi Mike, Looks like there is one test that knows it has to exercise the alt-rt.jar version: ./java/util/TreeMap/Clone.java * @run main/othervm Clone * @run main/othervm -XX:+AggressiveOpts Clone but it's harmless to leave the second invocation. I didn't see anything in JDK or hotspot regr

Re: RFR(M): 8024265: Enable new build on AIX (jdk part)

Hello Volker, This looks good to me. I think the mapfile situation could be solved better, but your solution is probably the simplest, at least if you anticipate using them in the future. /Erik On 2013-09-16 17:20, Volker Simonis wrote: Hi, could you please review the following webrev whic

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

On 17/09/2013 01:16, Mike Duigou wrote: Hello all; This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained