Hi Mandy,
Just a note on null keys (1st level)...
On 04/25/2013 11:53 PM, Mandy Chung wrote:
Hi Peter,
This looks great. I have imported your patch with slight modification
in WeakCache:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.01/
I believe WeakCache.get(K, P)
On 4/25/2013 11:53 PM, Peter Levart wrote:
I believe WeakCache.get(K, P) should throw NPE if key is null and I
fixed that.
Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V
value) should throw NPE if value is null.
Mandy
Here is the final form of this after CCC approval.
http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
For the traditional build of client+server we continue to use the
platform specific jvm.cfg files committed into the source repository.
Consequently no product builds (SE or Embedded) are
Changeset: 3c02d2f1a421
Author:vromero
Date: 2013-04-26 10:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3c02d2f1a421
8012723: strictfp interface misses strictfp modifer on default method
Reviewed-by: mcimadamore
!
On 04/26/2013 08:57 AM, Mandy Chung wrote:
On 4/25/2013 11:53 PM, Peter Levart wrote:
I believe WeakCache.get(K, P) should throw NPE if key is null and I
fixed that.
Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V
value) should throw NPE if value is null.
I
On 26/04/2013 1:29 PM, huizhe wang wrote:
On 4/18/2013 7:44 PM, David Holmes wrote:
On 19/04/2013 8:32 AM, huizhe wang wrote:
On 4/18/2013 2:13 AM, Alan Bateman wrote:
On 18/04/2013 07:28, huizhe wang wrote:
System.getProperties [1] returns all of the current system
properties. Is there a
Changeset: 2ca9e7d50136
Author:vromero
Date: 2013-04-26 10:17 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2ca9e7d50136
8008562: javac, a refactoring to Bits is necessary in order to provide a change
history
Reviewed-by: mcimadamore
!
On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
On 4/25/2013 3:53 PM, Mike Duigou wrote:
The restyling changes obfustucated things a bit but I didn't see anything of
concern in casual review.
I had hoped to see the updated SmallSet that didn't try to
On Apr 24, 2013, at 7:57 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 04/24/2013 07:24 PM, Akhil Arora wrote:
On 04/24/2013 06:19 AM, Alan Bateman wrote:
On 23/04/2013 20:18, Akhil Arora wrote:
On 04/22/2013 11:42 AM, Alan Bateman wrote:
One thing I meant to ask when forEachRemaining was
On 26/04/2013 9:52 PM, Paul Sandoz wrote:
On Apr 24, 2013, at 7:57 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 04/24/2013 07:24 PM, Akhil Arora wrote:
On 04/24/2013 06:19 AM, Alan Bateman wrote:
On 23/04/2013 20:18, Akhil Arora wrote:
On 04/22/2013 11:42 AM, Alan Bateman wrote:
One thing I
On 25/04/2013 15:41, Alexey Utkin wrote:
Alan,
Thanks for your comments.
I did the changes in code.
Please, read my answers below.
Here is fixed version:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.02/
The implementation changes look good now.
:
One thing I see is
I think, sometimes it is better to violate those 2 rules because:
- modern wide-screens have much horizontal, but less vertical space, especially
on labtops
- line break for only one/few word(s) looks ugly, disturbs read-flow
- it's no problem, if e.g. 1 of 50 lines must be scrolled a little
On 25/04/2013 21:53, Lance Andersen - Oracle wrote:
http://cr.openjdk.java.net/~lancea/8010416/webrev.03/ addresses the typos that
were pointed out and also fixes a couple javadoc warnings
This looks okay to me.
One small suggestion for DriverAction and the first statement where it
reads
On Apr 26, 2013, at 2:06 PM, David Holmes david.hol...@oracle.com wrote:
To avoid blocking the feature, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of
remove and other ListIterator methods after forEachRemaining returns.
I think the fact that the
On 04/26/2013 02:50 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 2:06 PM, David Holmes david.hol...@oracle.com wrote:
To avoid blocking the feature, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove
and other ListIterator methods after forEachRemaining
On 25/04/2013 21:25, Henry Jen wrote:
Hi,
Please review two default methods add to CharSequence returns IntStream
of char value or code point value.
http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
The synchronization test is relieved so lambda and other synthetic
method is not
On 04/26/2013 01:43 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
On 4/25/2013 3:53 PM, Mike Duigou wrote:
The restyling changes obfustucated things a bit but I didn't see anything of
concern in casual review.
I had hoped to see
Hi,
please oblige with a review of the fix for the issue JDK-8007799 as
shown in the webrev
below:
http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/
This fix takes into account the feedback from the initial review and
condenses the solution to a check on the line length in the
On Apr 26, 2013, at 3:25 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 04/26/2013 01:43 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan
kumar.x.sriniva...@oracle.com wrote:
On 4/25/2013 3:53 PM, Mike Duigou wrote:
The restyling changes obfustucated things a bit but I
On 04/26/2013 03:06 PM, Remi Forax wrote:
On 04/26/2013 02:50 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 2:06 PM, David Holmes david.hol...@oracle.com
wrote:
To avoid blocking the feature, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the
behavior of remove and other
On 04/26/2013 03:06 PM, Remi Forax wrote:
On 04/26/2013 02:50 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 2:06 PM, David Holmes david.hol...@oracle.com
wrote:
To avoid blocking the feature, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the
behavior of remove and other
Ulf, I have my opinions too on code style. However, the published
guidelines for Java code is what Oracle/Sun set out for themselves. AFAIK,
it is what's expected for JDK source.
On Fri, Apr 26, 2013 at 7:29 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
I think, sometimes it is better to violate
Changeset: f3f3ac1273e8
Author:vromero
Date: 2013-04-26 15:59 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3f3ac1273e8
8010304: javac should detect all mutable implicit static fields in langtools
using a plugin
Reviewed-by: jjg
! make/build.xml
+
On 4/26/13 6:55 AM, Mark Sheppard wrote:
Hi,
please oblige with a review of the fix for the issue JDK-8007799 as
shown in the webrev
below:
http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/
This fix takes into account the feedback from the initial review and
condenses the solution
How many years ago was this done? Hasn't the hardware reality changed since
then? What might have been a justifiable crime then may just be a crime now.
On Apr 26, 2013, at 10:12 AM, Paul Sandoz wrote:
On Apr 26, 2013, at 3:25 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 04/26/2013
The copyright should be 2012, 2013,?
I agree. The copyright year should be updated as Sherman indicated.
iris
-Original Message-
From: Xueming Shen
Sent: Friday, April 26, 2013 8:05 AM
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR: JDK-8007799 Base64.getEncoder(0, byte[])
Brian
For any individual case, there is always an argument that adding a couple of
extra classes won't matter, but if that is the answer to every question, the
result is something slow and bloated. Also, what frequently happens is that
hardware advances are used to deliver lower cost rather
On Apr 26, 2013, at 4:37 PM, Peter Levart peter.lev...@gmail.com wrote:
Another interesting usage:
Iterator? i = ...;
i.forEachRemaining(e - {
...
if (...) {
i.forEachRemaining(dummy - {}); // drain it
}
...
});
It seems that mixing external and internal iteration
Looks good. It's nice to see the legacy entries finally get removed.
Mike
On Apr 26 2013, at 00:27 , David Holmes wrote:
Here is the final form of this after CCC approval.
http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
For the traditional build of client+server we continue to use
Hi David
Looks good to me.
Tim
On 04/26/13 12:27 AM, David Holmes wrote:
Here is the final form of this after CCC approval.
http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
For the traditional build of client+server we continue to use the
platform specific jvm.cfg files committed
Hi
Please help review the proposed fix for
8007395: StringIndexOutofBoundsException in Match.find() when input String
contains surrogate UTF-16 characters
http://cr.openjdk.java.net/~sherman/8007395/webrev
The root cause is the iterative optimization class GroupCurly fails to
backtrack
On 4/26/2013 10:25 AM, Xueming Shen wrote:
Hi
Please help review the proposed fix for
8007395: StringIndexOutofBoundsException in Match.find() when input
String contains surrogate UTF-16 characters
http://cr.openjdk.java.net/~sherman/8007395/webrev
This looks fine with me.
The new test
On 04/26/2013 01:09 PM, Mandy Chung wrote:
On 4/26/2013 10:25 AM, Xueming Shen wrote:
Hi
Please help review the proposed fix for
8007395: StringIndexOutofBoundsException in Match.find() when input String
contains surrogate UTF-16 characters
Changeset: 5144db7f0f88
Author:sherman
Date: 2013-04-26 13:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5144db7f0f88
8007395: StringIndexOutofBoundsException in Match.find() when input String
contains surrogate UTF-16 characters
Summary: updated GroupCurly.match0() to
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
It adds a method to BufferedReader.
public StreamString lines() {}
A class java.io.UncheckedIOException is also added as a general approach
for wrapping up an IOException to be unchecked.
Cheers,
Henry
On Apr 26, 2013, at 8:35 AM, Alan Bateman wrote:
On 25/04/2013 21:53, Lance Andersen - Oracle wrote:
http://cr.openjdk.java.net/~lancea/8010416/webrev.03/ addresses the typos
that were pointed out and also fixes a couple javadoc warnings
This looks okay to me.
One small suggestion for
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
The API doc in specdiff format is at
http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
Cheers,
Henry
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
7123493: (proxy) Proxy.getProxyClass doesn't scale under high load
Reviewed-by: mchung
! src/share/classes/java/lang/reflect/Proxy.java
+
Peter,
I have pushed the changeset:
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
Mandy
Looks good. Two minor non-blocking nits:
ZipFile.java::
- Create an ordered - Return an ordered
- could mention ordered in @return as well.
Mike
On Apr 26 2013, at 16:08 , Henry Jen wrote:
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
The API
I would suggest a new line at the end of each file.
Plus there is some very stylised formatting in terms of making things
align vertically that I wouldn't do personally, and seem to waste a
lot of screen space. Plus a single line which should be three lines.
public void close() { closed = true; }
Hello all;
A very small change to review.
http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
The change removes some erroneous documentation from the Deque push() method.
Mike
Looks good to me.
Mandy
On Apr 26, 2013, at 5:12 PM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
A very small change to review.
http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
The change removes some erroneous documentation from the Deque push() method.
Mike
On 27/04/2013 1:46 AM, Paul Sandoz wrote:
On Apr 26, 2013, at 4:37 PM, Peter Levart peter.lev...@gmail.com wrote:
Another interesting usage:
Iterator? i = ...;
i.forEachRemaining(e - {
...
if (...) {
i.forEachRemaining(dummy - {}); // drain it
}
...
});
It seems that
I thought that in this case parent is just ignored and it's still the
child itself. Turns out this is not true, and
new File(/tmp, /etc/passwd) is /tmp/etc/passwd
Is this really useful in any way?
Thanks
Max
45 matches
Mail list logo
