Thanks all! Glad to be able to get this done right before the deadline :-)
-Joe
On 6/27/18, 12:44 AM, Alan Bateman wrote:
On 26/06/2018 20:49, Joe Wang wrote:
:
Removed the null check. The internal impl and test guarantees it's
not null indeed:
On 26/06/2018 20:49, Joe Wang wrote:
:
Removed the null check. The internal impl and test guarantees it's not
null indeed:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev04/
Looks good.
-Alan
+1
On 6/26/18, 12:49 PM, Joe Wang wrote:
On 6/26/18, 11:57 AM, Alan Bateman wrote:
On 26/06/2018 18:41, Joe Wang wrote:
:
Yes, combined with Sherman's suggestion eliminated the need for the
new parameter. Here's the updated webrev:
On 6/26/18, 11:57 AM, Alan Bateman wrote:
On 26/06/2018 18:41, Joe Wang wrote:
:
Yes, combined with Sherman's suggestion eliminated the need for the
new parameter. Here's the updated webrev:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/
This looks good.
Just a minor nit
Thanks Lance! Indeed it has been changed to CCE. I'm still
familiarizing myself with IntelliJ. Opened it in NetBeans, it clearly
indicates "missing @throws tag for " CCE, but I don't see anything like
that in IntelliJ.
Updated webrev:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/
On 26/06/2018 18:41, Joe Wang wrote:
:
Yes, combined with Sherman's suggestion eliminated the need for the
new parameter. Here's the updated webrev:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/
This looks good.
Just a minor nit but newStringNoRepl and getBytesNoReply don't
Hi Joe,
Should src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java
—
/**
* Constructs a new {@code String} by decoding the specified subarray of
* bytes using the specified {@linkplain java.nio.charset.Charset charset}.
*
* The caller of this method
On 6/26/18, 6:54 AM, Alan Bateman wrote:
On 26/06/2018 05:50, Joe Wang wrote:
Hi Alan, Sherman,
Here's a version where we, as Sherman suggested, throw an IAE with
CCE as the cause. This approach reduces code duplication in SC,
although it complicates the impl a little bit with the added
Hi Sherman,
Combining the msg and cause is a great idea! That allowed us to satisfy
the existing code without changes/additional parameter and also the new
method for a CCE. I also moved the iae-catch into StringCoding, that
makes Files clean of such things.
Here's an updated webrev with
On 26/06/2018 05:50, Joe Wang wrote:
Hi Alan, Sherman,
Here's a version where we, as Sherman suggested, throw an IAE with CCE
as the cause. This approach reduces code duplication in SC, although
it complicates the impl a little bit with the added parameter and the
different behavior between
Hi Joe,
I would suggest always embed a malformed exception into the iae as showed
below, then the extra flag is no longer needed.
private static void throwMalformed(int off, int nb) {
String msg = "malformed input off : " + off + ", length : " + nb;
throw new
Hi Alan, Sherman,
Here's a version where we, as Sherman suggested, throw an IAE with CCE
as the cause. This approach reduces code duplication in SC, although it
complicates the impl a little bit with the added parameter and the
different behavior between the existing usages of the methods and
Hi Alan,
The test testMalformedRead and testMalformedWrite now expect an
UnmappableCharacterException instead of IOE:
webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev01/
Thanks,
Joe
On 6/25/18, 9:48 AM, Joe Wang wrote:
On 6/24/18, 12:11 PM, Alan Bateman wrote:
On
On 6/24/18, 12:11 PM, Alan Bateman wrote:
On 20/06/2018 04:32, Joe Wang wrote:
Thanks Alan. I created 8205058 to capture your suggestions. Please
see below for more details.
Changed the internal APIs to throw CCE instead. In the same way as
the previous changeset for 8201276, these
On 20/06/2018 04:32, Joe Wang wrote:
Thanks Alan. I created 8205058 to capture your suggestions. Please
see below for more details.
Changed the internal APIs to throw CCE instead. In the same way as the
previous changeset for 8201276, these methods are made specific for
the use cases
Thanks Alan. I created 8205058 to capture your suggestions. Please see
below for more details.
On 6/14/18, 4:30 AM, Alan Bateman wrote:
On 12/06/2018 17:52, Joe Wang wrote:
Hi all,
It's been a while since the 1st round of reviews. Thank you all for
the valuable comments and suggestions!
On 12/06/2018 17:52, Joe Wang wrote:
Hi all,
It's been a while since the 1st round of reviews. Thank you all for
the valuable comments and suggestions! Note that Roger's last
response went to nio-dev, but not core-libs-dev, I've therefore
attached it below.
CSR [2]: the CSR is now
Thanks Roger!
I pushed the changeset after s/unmappble/unmappable, it found three of
them :-)
Best,
Joe
On 6/12/18, 10:37 AM, Roger Riggs wrote:
Hi Joe,
Looks good to me.
Typo: StringCoding.java:1026 "unmappble" (no new webrev needed)
Regards, Roger
On 6/12/2018 12:52 PM, Joe Wang
Hi Joe,
Looks good to me.
Typo: StringCoding.java:1026 "unmappble" (no new webrev needed)
Regards, Roger
On 6/12/2018 12:52 PM, Joe Wang wrote:
Hi all,
It's been a while since the 1st round of reviews. Thank you all for
the valuable comments and suggestions! Note that Roger's last
Hi all,
It's been a while since the 1st round of reviews. Thank you all for the
valuable comments and suggestions! Note that Roger's last response went
to nio-dev, but not core-libs-dev, I've therefore attached it below.
CSR [2]: the CSR is now approved. Note the write method has been
Hi Hamlin,
Thanks for reviewing the test! Fixed now, by calling deleteOnExit.
Indeed, I didn't realize I got a few empty tmp files :-)
Best,
Joe
On 4/28/2018 12:35 AM, Hamlin Li wrote:
Hi Joe,
just a minor comment about the test in ReadWriteString.java.
For both testMalformedWrite and
Hi Joe,
just a minor comment about the test in ReadWriteString.java.
For both testMalformedWrite and testMalformedRead, temp files are not
deleted, as Files.deleteIfExists(path); is skipped by the expected
IOException. File.deleteOnExit() may help.
Thank you
-Hamlin
On 27/04/2018 12:50
On 4/27/2018 12:50 PM, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Joe Wang"
À: "Remi Forax" , "Alan Bateman"
Cc: "nio-dev" , "core-libs-dev"
Envoyé:
- Mail original -
> De: "Joe Wang"
> À: "Remi Forax" , "Alan Bateman"
> Cc: "nio-dev" , "core-libs-dev"
>
> Envoyé: Vendredi 27 Avril 2018 21:21:01
> Objet: Re:
Hi Rémi, Alan,
I'm not sure we'd want to replace system dependent line separators with
'\n'. There are cases as you described where the replacement makes
sense. However, there are other cases too. For example, the purpose is
to read, edit a text file and then write it back. If this is on
On 4/27/2018 4:13 AM, Alan Bateman wrote:
On 27/04/2018 05:50, Joe Wang wrote:
Hi,
We're looking into adding methods to Files to read a file into a
String/write a String to a file. Below is the current proposal.
Please review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8201276
Hi Alan,
People do not read the documentation.
So adding something in the documentation about when a method should be used or
not is never a solution.
Here the user want a String and provides a charset so you have no way but to
decode the content to substitute the line separator.
cheers,
Rémi
On 27/04/2018 12:29, Remi Forax wrote:
I think that having a readString that includes OS dependent line separators is
a mistake,
Java does a great job to try to shield the developer from the kind of things
that makes programs behave differently on different platforms.
readString should
I think that having a readString that includes OS dependent line separators is
a mistake,
Java does a great job to try to shield the developer from the kind of things
that makes programs behave differently on different platforms.
readString should subtitute (\r)?\n to \n otherwise either people
On 27/04/2018 05:50, Joe Wang wrote:
Hi,
We're looking into adding methods to Files to read a file into a
String/write a String to a file. Below is the current proposal. Please
review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8201276
webrev:
30 matches
Mail list logo