Hi Vicente,
For purposes of a better exception message, do you want to explicitly
check moreNestedNames for null in some way before accessing its
contents? Also, I'd commend the spec be updated slightly to
@throws NullPointerException if any argument or its contents is
{@code null}
ass
Hi Semyon,
Looks good.
Thanks,
Alexander
On 4/26/2019 12:28 PM, semyon.sadet...@oracle.com wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8223038
webrev: http://cr.openjdk.java.net/~ssadetsky/8223038/webrev.00/
This is a regression of 8219683 where Java runtime was moved out from
Plug
bug: https://bugs.openjdk.java.net/browse/JDK-8223038
webrev: http://cr.openjdk.java.net/~ssadetsky/8223038/webrev.00/
This is a regression of 8219683 where Java runtime was moved out from
PlugIns which made codesign unable to detect the bundle type. The fix
points codesign to the valid path i
I filed https://bugs.openjdk.java.net/browse/JDK-8223039
Hi Daniel,
I actually caught that already: the diff I included before was stale (from a
scroll-up in the terminal!).
Thanks!
Brian
> On Apr 26, 2019, at 11:45 AM, Daniel Fuchs wrote:
>
> Looks good Brian!
>
> nit:
>
> > +reader.reset(); // reset to position after '\n'
>
> actu
Looks good Brian!
nit:
> +reader.reset(); // reset to position after '\n'
actually it's 'after '\r'' now.
No need for new review!
best regards,
-- daniel
On 26/04/19 19:27, Brian Burkhalter wrote:
Daniel,
I modified the test as shown below. It passes both before and after the
Daniel,
I modified the test as shown below. It passes both before and after the
implementation change.
Thanks,
Brian
--- a/test/jdk/java/io/LineNumberReader/MarkSplitCRLF.java
+++ b/test/jdk/java/io/LineNumberReader/MarkSplitCRLF.java
@@ -56,6 +56,24 @@
}
@Test
+public static v
Please review. Thank you.
Cheers,
-- Jim
Summary: Add the method ClassDesc::displayFullName to return the fully
qualified class name from a ClassDesc. Add a second method
MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc
descriptor using fully qualified class names.
cs
Hi Lance,
ok, then I’ll remove the commented printf in ZipFSTester altogether. In case
anybody debugs this again, he or she will probably add their own printfs anyway.
Have a nice weekend, too 😊
/Christoph
From: Lance Andersen
Sent: Freitag, 26. April 2019 18:54
To: Langer, Christoph
Cc: cor
Hi Christoph,
> On Apr 26, 2019, at 12:50 PM, Langer, Christoph
> wrote:
>
> Hi Lance,
>
> thanks for reviewing.
:-)
>
> As for ZipFSTester: the printf is anyway commented out, probably only used
> for debugging. Removing the variable was just because the IDE said it’s
> unused. I’d rath
Great, thank you. This one is a bit larger and will probably need a few
iterations…
From: Lance Andersen
Sent: Freitag, 26. April 2019 18:45
To: Langer, Christoph
Cc: core-libs-dev ; nio-dev
; Alan Bateman
Subject: Re: RFR: 876: (zipfs) Refactoring and cleanups to prepare for
JDK-8213031
Hi Lance,
thanks for reviewing.
As for ZipFSTester: the printf is anyway commented out, probably only used for
debugging. Removing the variable was just because the IDE said it's unused. I'd
rather leave it as is.
As for the jarfs tests: OK, it probably makes sense to separate these out into
The java.base portion looks good to me.
-Brent
On 4/25/19 1:32 PM, Philip Race wrote:
And the complete CSR link is this :
https://bugs.openjdk.java.net/browse/JDK-8222990
On 4/25/19, 1:31 PM, Philip Race wrote:
Sorry, meant to include core-libs on this !
-phil.
On 4/25/19, 1:12 PM, Phil Ra
On my todo list, will get to it either later today or over the weekend.
Thank you for the reminder :-)
> On Apr 26, 2019, at 11:37 AM, Langer, Christoph
> wrote:
>
> Hi,
>
> ping 😊
>
> I’ve rebased this change after the latest zipfs updates. I also made some
> further modifications. Apart
Hi,
Please review fix [1] and CSR [2] for [3]. The API for method
j.l.c.ClassDesc::nested(String, String...) states that it should throw
NPE if any of the arguments is null. The implementation is not in sync
with the API and should be corrected,
Thanks,
Vicente
[1] http://cr.openjdk.java.ne
Hi Christoph,
Thank you for doing this. Overall the changes look good.
A few minor thoughts
ZIpFSTester.java - 537: Given you removed the method variable, I would tweak
the printf string to make it a bit clearer that what the output its.
JFSTester.java and MultiReleaseJarTest.java - I had
Not content with the fact that we generate one tree for "foo"+bar+baz
and another for foo+bar+"baz", I did a little "Hold my beer!"-style
experiment with a constant folder that greedily folds prefix and suffix
constants around an argument (so "foo"+bar would be prepended in one go,
and bar+"baz" i
Hi,
ping 😊
I’ve rebased this change after the latest zipfs updates. I also made some
further modifications. Apart from minor things, I modified the constructors of
the ZipFileSystem.Entry class and I also made some post JDK-8222440 cleanup.
Please find the new webrev here:
http://cr.openjdk.j
On 25/04/2019 17:34, Andrew Dinn wrote:
Also, here is a new webrev including the updated implementations for
mappingAddress/Offset/Length as described below
JIRA: https://bugs.openjdk.java.net/browse/JDK-8221696
webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.02
This looks right and
Hi Peter,
thanks for looking at this!
On 2019-04-26 11:08, Peter Levart wrote:
Hi Claes,
I wonder if it is even possible to create a test that would do something
like the following:
String s = ...
String s2 = s + "const1" + "const2" + s;
...since javac concatenates consec
> On 26 Apr 2019, at 02:20, Brian Burkhalter
> wrote:
>
> For issue [1] please review the patch [2].
Looks good to me.
Thank you, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Freitag, 26. April 2019 14:44
> To: Langer, Christoph ; core-libs-
> d...@openjdk.java.net; nio-...@openjdk.java.net
> Subject: Re: RFR (S): 8223015: Cleanups for zipfs tests
>
> Looks good to me.
>
> I took some extr
Looks good to me.
I took some extra care to check that use of new Integer in
MultiReleaseJarTest wasn't intentional but that doesn't seem to be the
case here.
Thanks!
/Claes
On 2019-04-26 14:35, Langer, Christoph wrote:
Hi,
please help reviewing these cleanups to the zipfs tests. In detail:
Hi,
please help reviewing these cleanups to the zipfs tests. In detail:
- Fix warnings in test/jdk/jdk/nio/zipfs/Demo.java (not a real testcase but
Demo coding)
- change some calls of Runtime.version().major() to Runtime.version().feature()
(the former is deprecated)
- change occurences of new
On 26/04/2019 7:25 pm, Alan Bateman wrote:
On 26/04/2019 06:32, David Holmes wrote:
I pushed this today based on Dan and Robbin's reviews, but realized
just after the act that I should have waited for any feedback from
core-libs - apologies about that. If there are concerns I will roll it
back
Hi Brian,
I believe this looks good.
I had to convince myself that there was no issue when
'\r' is not followed by '\n' but I couldn't fault the
logic.
I wonder if adding a third test case with '\r' not
followed by '\n' would be a good idea?
best regards,
-- daniel
On 26/04/2019 02:20, Brian
On 26/04/2019 06:32, David Holmes wrote:
I pushed this today based on Dan and Robbin's reviews, but realized
just after the act that I should have waited for any feedback from
core-libs - apologies about that. If there are concerns I will roll it
back.
I don't think there are any concerns, it i
On 4/26/19 11:08 AM, Peter Levart wrote:
I wonder if it is even possible to create a test that would do
something like the following:
String s = ...
String s2 = s + "const1" + "const2" + s;
...since javac concatenates consecutive constants into a single
constant. So this ac
Hi Claes,
I wonder if it is even possible to create a test that would do something
like the following:
String s = ...
String s2 = s + "const1" + "const2" + s;
...since javac concatenates consecutive constants into a single
constant. So this actually becomes:
String
Hello!
Great optimization!
+// overflow-conscious code
+int resultLen = valLen + (++p) * deltaLen;
+if (Integer.MAX_VALUE / p < deltaLen ||
+Integer.MAX_VALUE - resultLen < 0) {
+throw new OutOfMemoryError();
+}
Is it really necessary t
I'll file a RFE for that.
Great, thanks!
/Robbin
Thanks,
David
Thanks, Robbin
On 4/24/19 9:12 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
The original implementation of Unsafe.unpark simply e
31 matches
Mail list logo
