A typical way to refer to a particular Unicode character by code point hex value
is U+xxxx (with more x's if necessary). For example,
2602 * Returns a string whose value is this string, with all leading
2603 * and trailing space removed, where space is defined
2604 * as any character whose codepoint is less than or equal to
2605 * U+0020 (the space character).
It doesn't even need to be the code font.
Oh well, you pushed already. Maybe fix this up in your next change to
String.java.
s'marks
On 5/8/18 6:43 AM, Roger Riggs wrote:
Hi Jim,
I would agree about code points in methods that refer to code points and need a
more
precise notation. However, trim() is not one of them and the alternative 0x
format is quite acceptable.
Would the syntax for raw string literals (not there yet) make the source more
readable?
Roger
On 5/8/2018 9:36 AM, Jim Laskey wrote:
Roger,
You withdrew the comment from the CSR so I assumed that you had changed your
mind.
Stuart, Sherman and Joe have be pushing the use of codepoints versus char (or
ASCII) in new character related comments hence the choice of ‘\unnnn'
notation. Unfortunately, unicode preprocessing vs backslash processing vs
Javadoc does not allow the '\\u0020' in comments (it ends up being '\\u0020’
in the Javadoc) and '\u0020’ just ends up being ‘ ‘.
Cheers,
— Jim
On May 8, 2018, at 10:04 AM, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi Jim,
The use of \u005c in the source makes the source code unreadable.
The more conventional use of the 0x prefix (i.e. 0x0130) is preferred.
Though \u is necessary in some cases, it should be avoided where a more
readable alternative is available.
Thanks, Roger
On 5/8/2018 8:19 AM, Jim Laskey wrote:
Comment change approved in CSR
webrev: http://cr.openjdk.java.net/~jlaskey/8200372/webrev/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8200372
CSR: https://bugs.openjdk.java.net/browse/JDK-8196005
