Am 02.09.2009 22:29, Martin Buchholz schrieb:
On Wed, Sep 2, 2009 at 12:46, Ulf Zibis<ulf.zi...@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.ll...@redhat.com
<mailto:david.ll...@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
Doesn't {...@code "t\u005Cu0131tle"} work too ?
If not, can this be seen as a bug ?
Searching the JDK sources for regex
^ *\*.*\\u[0-9a-fA-F]{4}
Doesn't it make sense to cover all occurrences in JDK ?
-Ulf
