Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-20 Thread Jim Laskey
revised webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-02/index.html > On Sep 19, 2018, at 11:57 AM, Jim Laskey wrote: > > Will do. > > >> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons >> wrote: >> >> If you're making the change, then you might add a test case based on Jan's >

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-20 Thread Jim Laskey
Modified as per Stuart's suggestion. > On Sep 20, 2018, at 7:45 AM, Chris Hegarty wrote: > > >> On 19 Sep 2018, at 23:21, Stuart Marks wrote: >> >> ... >> >> 2979 * Each unicode escape in the form \u is translated to the >> 2980 * unicode character whose code point is {@code 0x

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-20 Thread Jim Laskey
> On Sep 19, 2018, at 7:21 PM, Stuart Marks wrote: > > > > On 9/18/18 10:51 AM, Jim Laskey wrote: >> Please review the code for String::unescape. Used to translate escape >> sequences in a string, typically in a raw string literal, into characters >> represented by those escapes. >> webrev

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-20 Thread Chris Hegarty
> On 19 Sep 2018, at 23:21, Stuart Marks wrote: > > ... > > 2979 * Each unicode escape in the form \u is translated to the > 2980 * unicode character whose code point is {@code 0x}. Care should > be > 2981 * taken when using UTF-16 surrogate pairs to ensure that the hig

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Stuart Marks
On 9/18/18 10:51 AM, Jim Laskey wrote: Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html jbs: htt

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jim Laskey
Will do. > On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons > wrote: > > If you're making the change, then you might add a test case based on Jan's > suggestion, testing > > "\u005ct".equals(`\u005ct`.unescape()) > > -- Jon > > > On 9/19/18 7:40 AM, Jim Laskey wrote: >> I see and good p

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jonathan Gibbons
If you're making the change, then you might add a test case based on Jan's suggestion, testing     "\u005ct".equals(`\u005ct`.unescape()) -- Jon On 9/19/18 7:40 AM, Jim Laskey wrote: I see and good point. I think Jon is correct. If you are using the JLS as the basis of your argument, then

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jim Laskey
I see and good point. I think Jon is correct. If you are using the JLS as the basis of your argument, then you better damn well stick to the JLS. I’ll make the changes. Cheers, — Jim > On Sep 19, 2018, at 11:10 AM, Jan Lahoda wrote: > > I guess Jon's comment was that (per JLS) the outcome

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jonathan Gibbons
Jan, Yes, thanks for clarifying my comment. And to repeat, my comment was just to raise awareness in the different treatment according to JLS and to .unescape(). -- Jon On 9/19/18 7:10 AM, Jan Lahoda wrote: I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jan Lahoda
I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then participate in the escape sequences in String literals. So, this: "\u005ct" is (as far as I know) a single character-literal (a tab), while it seems that `\u005ct`.unescape() is two characters: \t Not sure if

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-19 Thread Jim Laskey
Updated. > On Sep 18, 2018, at 5:55 PM, Naoto Sato wrote: > > Hi Jim, > > At the last sentence in the method description, there's a line "otherwise a > CharacterCodingException may occur during UTF-8 decoding." It's not decoding > into UTF-8, so simply "during decoding (or unescaping)" sounds

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Naoto Sato
Hi Jim, At the last sentence in the method description, there's a line "otherwise a CharacterCodingException may occur during UTF-8 decoding." It's not decoding into UTF-8, so simply "during decoding (or unescaping)" sounds better to me. Naoto On 9/18/18 10:51 AM, Jim Laskey wrote: Please

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Jim Laskey
The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too. So a developer could have String s = ` \t\tTitle \t\t\tbody

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Jonathan Gibbons
Jim, In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes. I'm not suggesting you should do the same here, but you should be awa

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Jim Laskey
Revised to break up long exception statements; webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-01/index.html > On Sep 18, 2018, at 3:03 PM, Jim Laskey wrote: > > Do you mean the throws specifically? If so, of course. > > > >> On Sep 18, 2018, at 2:51 PM, Jim Laskey wrote: >> >>

Re: RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Jim Laskey
Do you mean the throws specifically? If so, of course. > On Sep 18, 2018, at 2:51 PM, Jim Laskey wrote: > > Please review the code for String::unescape. Used to translate escape > sequences in a string, typically in a raw string literal, into characters > represented by those escapes. > > w

RFR - JDK-8202442 - String::unescape (Code Review)

2018-09-18 Thread Jim Laskey
Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-820244