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/
-Joe
On 6/26/18, 11:24 AM, Lance Andersen wrote:
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 shall relinquish and transfer the ownership of
* the byte array to the callee since the later will not make a copy.
*
* @param bytes the byte array source
* @param cs the Charset
* @return the newly created string
* @throws IllegalArgumentException for malformed or unmappable bytes
*/
String newStringNoRepl(byte[] bytes, Charset cs) throws
CharacterCodingException;
————————
include an @throws for CharacterCodingException?
On Jun 26, 2018, at 1:41 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
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
parameter and the different behavior between the existing usages of
the methods and the new ones. The existing code paths are kept
intact so there's no compatibility issue for the existing code.
This version also did not remove the try-catch in Files as Alan
suggested earlier.
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev02/
<http://cr.openjdk.java.net/%7Ejoehw/jdk11/8205058/webrev02/>
This version looks much better. In StringCoding, do you really need
throwCCE? The encode/decode methods do a replace or throw so I
assume one flag will do. If combined with Sherman suggestion then it
would be minimal changes to StringCoding. It would be nice to get
rid of the IAE completely but that is for another day. In Files then
you don't need to check if cause is null before testing its type.
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/
<http://cr.openjdk.java.net/%7Ejoehw/jdk11/8205058/webrev03/>
The update tests to check for UnmappedCharacterException and
MalformedInputException look good.
Thanks,
Joe
-Alan
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
