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
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
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
On Oct 1, 2013, at 6:03 PM, Joe Darcy joe.da...@oracle.com wrote:
On 10/1/2013 4:18 AM, Paul Sandoz wrote:
On Sep 20, 2013, at 5:30 PM, Martin Buchholz marti...@google.com wrote:
Looks good.
Random nitpicks:
I prefer the old variable name DOUBLE_UNIT to DOUBLE_ULP; else you are
[Catching up after J1]
On Sep 24, 2013, at 9:16 AM, Martin Buchholz marti...@google.com 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.
On Oct 3, 2013, at 7:13 AM, Alan Bateman alan.bate...@oracle.com 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
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
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
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
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
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,
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
!
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
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.
(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
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
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
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
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
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
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 christian.thalin...@oracle.com
Subject: Re: RFR (L) 8024761: JSR 292 improve performance of generic invocation
Date:
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:
Thanks Serguei!
Coleen
On 10/3/2013 3:50 PM, serguei.spit...@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
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 //
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
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/.
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:
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
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 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
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
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
+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
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
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
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
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.
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
38 matches
Mail list logo
