[loc-en-dev] Java Identifiers unstable?

[Mark Davis ☕]

I don't remember who it was at Sun.


For the unicodeStart and unicodePart, you should either shift to the Unicode
definition, or at a minimum, document that it is not the same as the Unicode
definition. And then document whether or not you keep it stable.

For the javaStart and javaPart, it really needs to be stable.

   - You could keep basically the same definition, but note that characters
   may be added for backwards compatibility. Internally, what you'd need to do
   is whenever you update to a new version of Unicode, check that all
   characters are retained; if any aren't, then grandfather them in with a
   hard-coded list.
   - Alternatively, you could base it on Unicode definition, with a set of
   grandfathered characters for backwards compatibility.


Mark

*— Il meglio è l’inimico del bene —*


On Thu, Oct 7, 2010 at 11:54, Naoto Sato <naoto.sato at oracle.com> wrote:

> Hi Mark,
>
> It looks like the javadoc has been the same since JDK 1.1 days ("char"
> version of the APIs), and AFAIK, the implementation does not follow the
> TR31.
>
> Do you remember who at Sun brought this issue to the consortium? I would
> like to know to what extent s/he went about this, but probably we end up
> filing a bug to correct the APIs and their implementations.
>
> Naoto
>
>
> (10/7/10 8:07 AM), Mark Davis ☕ wrote:
>
>> I know this isn't the right forum, but I'm not sure how to report it.
>>
>> Unicode has mechanisms to guarantee that program identifiers are stable
>> over versions of Unicode, and defines properties that have that
>> guarantee: XID_Start and XID_Continue (see
>> http://unicode.org/reports/tr31/).
>>
>> Sun was actually the one that brought up this issue, back some 6 or 7
>> years, prompting the Consortium to develop a definition that guaranteed
>> stability.
>>
>> However, when I look at the documentation for isJavaIdentifierPart,
>> isCharacteIdentifierPart, etc., it appears that these are defined not in
>> terms of those properties, but in terms of properties that are *not*
>> stable over releases.
>>
>>
>> http://download.oracle.com/javase/6/docs/api/java/lang/Character.html#isJavaIdentifierPart(int)
>> etc.
>>
>> That means that a program that was compiled under one release of Java
>> could fail under a future one, simply because the identifiers break
>> under the new release.
>>
>> It may be a matter of just documentation being wrong, or it could be the
>> underlying implementation. Anyway, how can I surface this?
>>
>> Mark
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20101007/a5b64c16/attachment.html