hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

[Martin Buchholz]

Xueming,

I believe you still owe me a review and bug filed for
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/javadoc-unicode-escapes/

Martin

On Wed, Sep 2, 2009 at 13:29, Martin Buchholz <martinrb at google.com> wrote:
> On Wed, Sep 2, 2009 at 12:46, Ulf Zibis<Ulf.Zibis at gmx.de> wrote:
>> Am 02.09.2009 19:11, David M. Lloyd schrieb:
>>>
>>> On 09/02/2009 12:03 PM, Martin Buchholz wrote:
>>>>
>>>> On Wed, Sep 2, 2009 at 09:40, David M. Lloyd <david.lloyd at redhat.com
>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>    Why not just do {@code \uD800}?  I'm like 60% sure that would work
>>>>    just fine. :-)
>>>>
>>>>
>>>> I'm pretty sure it would fail.   Prove me wrong!
>>>> Searching the JDK sources for regex
>>>> ^ *\*.*\\u[0-9a-fA-F]{4}
>>>> is a good way to find javadoc bugs, e.g.
>>>> http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()
>>>
>>> Ah, you're right.  It worked in my previewer but not in the actual
>>> javadoc.  It's pretty bad that that sequence has special meaning but you
>>> can't escape a \ with another \.  I guess in the worst case you could always
>>> do \u005CD800 or something like that.
>>>
>>
>> Looks little better, but not much. Did somebody tried it (Martin)?
>
> Well.... learn something new every day.
> Let's turn this into a fix.
> It's yet another "turkish i" bug.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/javadoc-unicode-escapes/
>
> Xueming, please file a bug and review.
>
> Synopsis: Unreadable \uXXXX in javadoc
> Description: Replace \uXXXX by \u005CXXXX, or simply delete
>
> Martin
>
>> If it works in a previewer, is there any chance to change the javadoc spec,
>> staying backwards compatible?
>>
>> -Ulf
>>
>>
>>
>