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
- * supp
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 co
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
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.
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 th
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 th
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
+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 wi
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
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
>> * Docume
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 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
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 , B
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/
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/.
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()
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
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
Cl
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 // l
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 nul
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_idn
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_Stac
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);
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(t
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 PD
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 cau
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
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 requireNon
> 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
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
Contr
> 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
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
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
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
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
(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 pref
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.
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
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
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, R
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 rem
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 NullPointerEx
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(Res
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
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 contra
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
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
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 wheth
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
[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, Doubl
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 diffe
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.uti
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/201
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 meaning
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
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 o
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 transi
57 matches
Mail list logo
