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
On 27/04/2013 1:46 AM, Paul Sandoz wrote:
On Apr 26, 2013, at 4:37 PM, Peter Levart wrote:
Another "interesting" usage:
Iterator i = ...;
i.forEachRemaining(e -> {
...
if (...) {
i.forEachRemaining(dummy -> {}); // drain it
}
...
});
It seems that mixing external and inte
Looks good to me.
Mandy
On Apr 26, 2013, at 5:12 PM, Mike Duigou 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
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
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; }
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
>
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
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
+ src/share/class
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
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 sugge
Hi,
Please review webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
It adds a method to BufferedReader.
public Stream lines() {}
A class java.io.UncheckedIOException is also added as a general approach
for wrapping up an IOException to be unchecked.
Cheers,
Henry
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 b
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
http://cr.openjdk.java.net/~sherman/8007395/webrev
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
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
cor
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 in
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
On Apr 26, 2013, at 4:37 PM, Peter Levart wrote:
>
> Another "interesting" usage:
>
> Iterator i = ...;
>
> i.forEachRemaining(e -> {
> ...
> if (...) {
> i.forEachRemaining(dummy -> {}); // drain it
> }
> ...
> });
>
> It seems that mixing external and internal iteration in the
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 t
> 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[]) ret
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 wrote:
>
>> On 04/26/2013 01:43 PM, Paul Sa
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 to
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
+ make/tools/crules/
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 wrote:
> I think, sometimes it is better to violate those 2 rules because
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
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 afte
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
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 afte
On Apr 26, 2013, at 3:25 PM, Remi Forax wrote:
> On 04/26/2013 01:43 PM, Paul Sandoz wrote:
>> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan
>> 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
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 getEnco
On 04/26/2013 01:43 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan
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
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 tested
On 04/26/2013 02:50 PM, Paul Sandoz wrote:
On Apr 26, 2013, at 2:06 PM, David Holmes 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 fa
On Apr 26, 2013, at 2:06 PM, David Holmes 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 last
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 "
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 hori
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 th
On 26/04/2013 9:52 PM, Paul Sandoz wrote:
On Apr 24, 2013, at 7:57 PM, Remi Forax 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
On Apr 24, 2013, at 7:57 PM, Remi Forax 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 added w
On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan
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 implement
>> Iterator di
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
! src/share/classes/com/sun/tools
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
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 agree.
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
! src/share/classes/com/sun/tools/javac/comp/Check.j
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) ar
43 matches
Mail list logo