Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39434 > unrolled thread

Character.isIdentifierIgnorable

Back to article view | Back to comp.lang.java.programmer

Contents

  Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 18:46 -0400
    Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-24 18:54 -0400
      Re: Character.isIdentifierIgnorable Martin Gregorie <martin@mydomain.invalid> - 2020-04-24 23:07 +0000
      Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 20:12 -0400
        Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-24 20:29 -0400
          Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 20:37 -0400
            Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-24 22:24 -0400
              Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 23:36 -0400
                Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-25 12:57 -0400
                  Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-25 13:01 -0400
                    Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-25 13:39 -0400
                      Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-25 13:51 -0400
                        Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-25 14:36 -0400
              Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 23:41 -0400
      Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 20:25 -0400
        Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-24 20:32 -0400
          Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-24 20:42 -0400
            Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-25 09:53 -0400
              Re: Character.isIdentifierIgnorable Arne Vajhøj <arne@vajhoej.dk> - 2020-04-25 12:55 -0400
                Re: Character.isIdentifierIgnorable Jeff Higgins <invalid@invalid.org> - 2020-04-25 13:43 -0400

#39434 — Character.isIdentifierIgnorable

Recently I wanted to implement a system of names and a hierarchic
namespace. My first thought was to use Java names, simply ignoring
the Java language semantics. So, investigating what exactly is a Java
name I came across this paragraph in the JLS Chapter 3.8.

quote
Two identifiers are the same only if, after ignoring characters that are
ignorable, the identifiers have the same Unicode character for each 
letter or digit. An ignorable character is a character for which the 
method Character.isIdentifierIgnorable(int) returns true. Identifiers 
that have the same external appearance may yet be different.
unquote

So, in my system of names I don't have to follow exactly follow the JLS,
but thinking more about this paragraph I began to wonder and hope that
someone here could help me understand.

What is the motivation for including these ignorable characters in
Java identifiers?

Where exactly in the Java environment (tools, language, standard 
libraries, etc.) are two identifiers checked according to the above 
specification?

For instance I can do:

class IdentifierTest {
   class _\u0001 {}
   class _\u0001\u0001 {}
}

and javac doesn't complain, which is understandable because those are
two different names - but then again these are the same identifier if
the ignorable \u001 are ignored - and even more curious - in Java later 
than 8 the underscore is a keyword so if the \u0001's are ignored then
I have two classes with the simple name of _?

[toc] | [next] | [standalone]

#39435

On 4/24/2020 6:46 PM, Jeff Higgins wrote:
> Recently I wanted to implement a system of names and a hierarchic
> namespace. My first thought was to use Java names, simply ignoring
> the Java language semantics. So, investigating what exactly is a Java
> name I came across this paragraph in the JLS Chapter 3.8.
> 
> quote
> Two identifiers are the same only if, after ignoring characters that are
> ignorable, the identifiers have the same Unicode character for each 
> letter or digit. An ignorable character is a character for which the 
> method Character.isIdentifierIgnorable(int) returns true. Identifiers 
> that have the same external appearance may yet be different.
> unquote
> 
> So, in my system of names I don't have to follow exactly follow the JLS,
> but thinking more about this paragraph I began to wonder and hope that
> someone here could help me understand.
> 
> What is the motivation for including these ignorable characters in
> Java identifiers?
> 
> Where exactly in the Java environment (tools, language, standard 
> libraries, etc.) are two identifiers checked according to the above 
> specification?
> 
> For instance I can do:
> 
> class IdentifierTest {
>    class _\u0001 {}
>    class _\u0001\u0001 {}
> }
> 
> and javac doesn't complain, which is understandable because those are
> two different names - but then again these are the same identifier if
> the ignorable \u001 are ignored - and even more curious - in Java later 
> than 8 the underscore is a keyword so if the \u0001's are ignored then
> I have two classes with the simple name of _?

My javac complains.

:-)

C:\Work>type Z.java
class Z {
   class _\u0001 {}
   class _\u0001\u0001 {}
}
C:\Work>javac -version
javac 1.8.0_192

C:\Work>javac Z.java
Z.java:2: warning: '_' used as an identifier
   class _\u0001 {}
         ^
   (use of '_' as an identifier might not be supported in releases after 
Java SE
8)
Z.java:3: warning: '_' used as an identifier
   class _\u0001\u0001 {}
         ^
   (use of '_' as an identifier might not be supported in releases after 
Java SE
8)
Z.java:3: error: class Z._ is already defined in class Z
   class _\u0001\u0001 {}
   ^
1 error
2 warnings

Arne

[toc] | [prev] | [next] | [standalone]

#39436

On Fri, 24 Apr 2020 18:54:54 -0400, Arne Vajhøj wrote:

> My javac complains.
>
So does mine:

$ javac -version
javac 1.8.0_242

$ javac Z.java
Z.java:4: warning: '_' used as an identifier
   class _\u0001 {}
         ^
  (use of '_' as an identifier might not be supported in releases after 
Java SE 8)
Z.java:6: warning: '_' used as an identifier
   class _\u0001\u0001 {}
         ^
  (use of '_' as an identifier might not be supported in releases after 
Java SE 8)
Z.java:6: error: class Z._ is already defined in class Z
   class _\u0001\u0001 {}
   ^
1 error
2 warnings


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#39437

On 4/24/20 6:54 PM, Arne Vajhøj wrote:
>>
>> For instance I can do:
>>
>> class IdentifierTest {
>>    class _\u0001 {}
>>    class _\u0001\u0001 {}
>> }
>>
>> and javac doesn't complain

> 
> My javac complains.
> 
> :-)
Well, I guess that is what I get for not doing what I said.

I used the Eclipse Java compiler to compile my example above.

When I use javac I get:

javac -version
javac 1.8.0_252

javac Z.java
Z.java:2: warning: '_' used as an identifier
   class _\u0001{}
         ^
   (use of '_' as an identifier might not be supported in releases after 
Java SE 8)
Z.java:3: error: illegal unicode escape
   class _\u001\u0001{}
               ^
Z.java:3: warning: '_' used as an identifier
   class _\u001\u0001{}
         ^
   (use of '_' as an identifier might not be supported in releases after 
Java SE 8)
1 error
2 warnings

When I compile and run in Eclipse using OpenJDK 8 and 11 :

class Z {
   public static void main(String[] args) {
     class _\u0001{String z = "z";}
     class _\u0001\u0001{String z = "zz";}
     _\u0001 Z = new _\u0001();
     _\u0001\u0001 ZZ = new _\u0001\u0001();
     System.out.println(Z.z + ZZ.z);
   }
}
prints "zzz"

That's worrisome!

[toc] | [prev] | [next] | [standalone]

#39439

On 4/24/2020 8:12 PM, Jeff Higgins wrote:
> On 4/24/20 6:54 PM, Arne Vajhøj wrote:
>>>
>>> For instance I can do:
>>>
>>> class IdentifierTest {
>>>    class _\u0001 {}
>>>    class _\u0001\u0001 {}
>>> }
>>>
>>> and javac doesn't complain
> 
>>
>> My javac complains.
>>
>> :-)

> Well, I guess that is what I get for not doing what I said.
> 
> I used the Eclipse Java compiler to compile my example above.

> When I compile and run in Eclipse using OpenJDK 8 and 11 :
> 
> class Z {
>    public static void main(String[] args) {
>      class _\u0001{String z = "z";}
>      class _\u0001\u0001{String z = "zz";}
>      _\u0001 Z = new _\u0001();
>      _\u0001\u0001 ZZ = new _\u0001\u0001();
>      System.out.println(Z.z + ZZ.z);
>    }
> }
> prints "zzz"

With Eclipse 2019-12 and Java 8 I get a weird build error
about illegal char.

> That's worrisome!

I think we are in the far out corners of the language.

Arne

[toc] | [prev] | [next] | [standalone]

#39441

On 4/24/20 8:29 PM, Arne Vajhøj wrote:
> On 4/24/2020 8:12 PM, Jeff Higgins wrote:
>> On 4/24/20 6:54 PM, Arne Vajhøj wrote:

> 
> With Eclipse 2019-12 and Java 8 I get a weird build error
> about illegal char.
> 

2020-03 here

>> That's worrisome!

even more so
> 
> I think we are in the far out corners of the language.
> 
Well, yeah, but still.
And still leaves me questioning motivation for ignorable chars.
> Arne

[toc] | [prev] | [next] | [standalone]

#39443

On 4/24/2020 8:37 PM, Jeff Higgins wrote:
> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>> I think we are in the far out corners of the language.
>>
> Well, yeah, but still.
> And still leaves me questioning motivation for ignorable chars.

We would need to find someone working at SUN back in the mid 90's
to know.

If I were to guess then somebody got the "smart" idea that
the language should not distinguish between names where
the difference could not be seen when type'd/cat'ed and
then someone else later added the \uXXXX feature.

Arne

[toc] | [prev] | [next] | [standalone]

#39444

On 4/24/20 10:24 PM, Arne Vajhøj wrote:
> On 4/24/2020 8:37 PM, Jeff Higgins wrote:
>> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>>> I think we are in the far out corners of the language.
>>>
>> Well, yeah, but still.
>> And still leaves me questioning motivation for ignorable chars.
> 
> We would need to find someone working at SUN back in the mid 90's
> to know.
> 
> If I were to guess then somebody got the "smart" idea that
> the language should not distinguish between names where
> the difference could not be seen when type'd/cat'ed and
> then someone else later added the \uXXXX feature.
> 
Maybe not that far back.

from JLS-3.8 for JavaSE 9
Two identifiers are the same only if they are identical, that is, have 
the same
Unicode character for each letter or digit. Identifiers that have the 
same external
appearance may yet be different.

from JLS-3.8 for JavaSE 10
Two identifiers are the same only if, after ignoring characters that are
ignorable, the identifiers have the same Unicode character for each letter
or digit. An ignorable character is a character for which the method
Character.isIdentifierIgnorable(int) returns true. Identifiers that have the
same external appearance may yet be different.

from OpenJDK com/sun/tools/javac/parser/JavaTokenizer.scanIdent()

if (Character.isIdentifierIgnorable(reader.ch)) {
   reader.scanChar();
   continue;
}

So openJDK javac eliminates ignorable chars before he even attemps to 
build AST

Looking at org.eclipse.jdt.internal.compiler.parser.Scanner right now
but is a real clusterfk.

No response from Eclipse JDT forum yet.

[toc] | [prev] | [next] | [standalone]

#39448

On 4/24/2020 11:36 PM, Jeff Higgins wrote:
> On 4/24/20 10:24 PM, Arne Vajhøj wrote:
>> On 4/24/2020 8:37 PM, Jeff Higgins wrote:
>>> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>>>> I think we are in the far out corners of the language.
>>>>
>>> Well, yeah, but still.
>>> And still leaves me questioning motivation for ignorable chars.
>>
>> We would need to find someone working at SUN back in the mid 90's
>> to know.
>>
>> If I were to guess then somebody got the "smart" idea that
>> the language should not distinguish between names where
>> the difference could not be seen when type'd/cat'ed and
>> then someone else later added the \uXXXX feature.
>>
> Maybe not that far back.
> 
> from JLS-3.8 for JavaSE 9
> Two identifiers are the same only if they are identical, that is, have 
> the same
> Unicode character for each letter or digit. Identifiers that have the 
> same external
> appearance may yet be different.
> 
> from JLS-3.8 for JavaSE 10
> Two identifiers are the same only if, after ignoring characters that are
> ignorable, the identifiers have the same Unicode character for each letter
> or digit. An ignorable character is a character for which the method
> Character.isIdentifierIgnorable(int) returns true. Identifiers that have 
> the
> same external appearance may yet be different.

But Java 8 javac did ignore them??

Arne

[toc] | [prev] | [next] | [standalone]

#39449

On 4/25/2020 12:57 PM, Arne Vajhøj wrote:
> On 4/24/2020 11:36 PM, Jeff Higgins wrote:
>> On 4/24/20 10:24 PM, Arne Vajhøj wrote:
>>> On 4/24/2020 8:37 PM, Jeff Higgins wrote:
>>>> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>>>>> I think we are in the far out corners of the language.
>>>>>
>>>> Well, yeah, but still.
>>>> And still leaves me questioning motivation for ignorable chars.
>>>
>>> We would need to find someone working at SUN back in the mid 90's
>>> to know.
>>>
>>> If I were to guess then somebody got the "smart" idea that
>>> the language should not distinguish between names where
>>> the difference could not be seen when type'd/cat'ed and
>>> then someone else later added the \uXXXX feature.
>>>
>> Maybe not that far back.
>>
>> from JLS-3.8 for JavaSE 9
>> Two identifiers are the same only if they are identical, that is, have 
>> the same
>> Unicode character for each letter or digit. Identifiers that have the 
>> same external
>> appearance may yet be different.
>>
>> from JLS-3.8 for JavaSE 10
>> Two identifiers are the same only if, after ignoring characters that are
>> ignorable, the identifiers have the same Unicode character for each 
>> letter
>> or digit. An ignorable character is a character for which the method
>> Character.isIdentifierIgnorable(int) returns true. Identifiers that 
>> have the
>> same external appearance may yet be different.
> 
> But Java 8 javac did ignore them??

So does Java 7 javac.

Java 6 javac gives me an error when trying to create the class file,
which likely means that it is not ignoring these characters.

Arne

[toc] | [prev] | [next] | [standalone]

#39450

On 4/25/20 1:01 PM, Arne Vajhøj wrote:
> On 4/25/2020 12:57 PM, Arne Vajhøj wrote:
>> On 4/24/2020 11:36 PM, Jeff Higgins wrote:
>>> On 4/24/20 10:24 PM, Arne Vajhøj wrote:
>>>> On 4/24/2020 8:37 PM, Jeff Higgins wrote:
>>>>> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>>>>>> I think we are in the far out corners of the language.
>>>>>>
>>>>> Well, yeah, but still.
>>>>> And still leaves me questioning motivation for ignorable chars.
>>>>
>>>> We would need to find someone working at SUN back in the mid 90's
>>>> to know.
>>>>
>>>> If I were to guess then somebody got the "smart" idea that
>>>> the language should not distinguish between names where
>>>> the difference could not be seen when type'd/cat'ed and
>>>> then someone else later added the \uXXXX feature.
>>>>
>>> Maybe not that far back.
>>>
>>> from JLS-3.8 for JavaSE 9
>>> Two identifiers are the same only if they are identical, that is, 
>>> have the same
>>> Unicode character for each letter or digit. Identifiers that have the 
>>> same external
>>> appearance may yet be different.
>>>
>>> from JLS-3.8 for JavaSE 10
>>> Two identifiers are the same only if, after ignoring characters that are
>>> ignorable, the identifiers have the same Unicode character for each 
>>> letter
>>> or digit. An ignorable character is a character for which the method
>>> Character.isIdentifierIgnorable(int) returns true. Identifiers that 
>>> have the
>>> same external appearance may yet be different.
>>
>> But Java 8 javac did ignore them??
> 
> So does Java 7 javac.
> 
> Java 6 javac gives me an error when trying to create the class file,
> which likely means that it is not ignoring these characters.
> 
Thanks. I don't have earlier than 8 easily available.
Was wondering.

I was wondering when Character,isIdentifierIgnorable(int codepoint)
became available. The earliest javadoc that i can find is 5 and is
available there. A Sun press release from 1997 features
"Global language support based on Unicode 2.0 standards" so maybe
available from then?

[toc] | [prev] | [next] | [standalone]

#39452

On 4/25/2020 1:39 PM, Jeff Higgins wrote:
> On 4/25/20 1:01 PM, Arne Vajhøj wrote:
>> On 4/25/2020 12:57 PM, Arne Vajhøj wrote:
>>> On 4/24/2020 11:36 PM, Jeff Higgins wrote:
>>>> from JLS-3.8 for JavaSE 9
>>>> Two identifiers are the same only if they are identical, that is, 
>>>> have the same
>>>> Unicode character for each letter or digit. Identifiers that have 
>>>> the same external
>>>> appearance may yet be different.
>>>>
>>>> from JLS-3.8 for JavaSE 10
>>>> Two identifiers are the same only if, after ignoring characters that 
>>>> are
>>>> ignorable, the identifiers have the same Unicode character for each 
>>>> letter
>>>> or digit. An ignorable character is a character for which the method
>>>> Character.isIdentifierIgnorable(int) returns true. Identifiers that 
>>>> have the
>>>> same external appearance may yet be different.
>>>
>>> But Java 8 javac did ignore them??
>>
>> So does Java 7 javac.
>>
>> Java 6 javac gives me an error when trying to create the class file,
>> which likely means that it is not ignoring these characters.
>>
> Thanks. I don't have earlier than 8 easily available.
> Was wondering.
> 
> I was wondering when Character,isIdentifierIgnorable(int codepoint)
> became available. The earliest javadoc that i can find is 5 and is
> available there. A Sun press release from 1997 features
> "Global language support based on Unicode 2.0 standards" so maybe
> available from then?

http://www-evasion.imag.fr/Membres/Francois.Faure/enseignement/ressources/java/jdk1.3/api/index.html

shows it in 1.3 and says "Since: JDK1.1".

Arne

[toc] | [prev] | [next] | [standalone]

#39453

On 4/25/20 1:51 PM, Arne Vajhøj wrote:

> 
> http://www-evasion.imag.fr/Membres/Francois.Faure/enseignement/ressources/java/jdk1.3/api/index.html 
> 
> 
> shows it in 1.3 and says "Since: JDK1.1".
> 

Ah, thanks for that. So, since forever.

In one of the bug reports that I mentioned upthread a fellow
compiled his library using maven and javac, then uploaded to
maven central, created a maven project in Eclipse and would
not compile due to a spurious \u00?? in his source!!
So even far flung language features sometime can cause bug bites.

I mention in my post to JDT this from Java VM Spec 14:

Module names may be drawn from the entire Unicode codespace, subject to 
the following constraints:

• A module name must not contain any code point in the range
' \u0000 ' to ' \u001F ' inclusive.

But no mention in JLS as far as I can tell?

I wonder if this will be an inconsistency waiting to bite?

[toc] | [prev] | [next] | [standalone]

#39445

On 4/24/20 10:24 PM, Arne Vajhøj wrote:
> On 4/24/2020 8:37 PM, Jeff Higgins wrote:
>> On 4/24/20 8:29 PM, Arne Vajhøj wrote:
>>> I think we are in the far out corners of the language.
>>>
>> Well, yeah, but still.
>> And still leaves me questioning motivation for ignorable chars.
> 
> We would need to find someone working at SUN back in the mid 90's
> to know.
> 
> If I were to guess then somebody got the "smart" idea that
> the language should not distinguish between names where

> the difference could not be seen when type'd/cat'ed and

This has been my only guess at motivation.

> then someone else later added the \uXXXX feature.
> 
Yeah, between SE 9 and 10.

[toc] | [prev] | [next] | [standalone]

#39438

On 4/24/20 6:54 PM, Arne Vajhøj wrote:

>> Where exactly in the Java environment (tools, language, standard 
>> libraries, etc.) are two identifiers checked according to the above 
>> specification?
>>
>> For instance I can do:
>>
>> class IdentifierTest {
>>    class _\u0001 {}
>>    class _\u0001\u0001 {}
>> }
>>
>> and javac doesn't complain
> 
> My javac complains.
> 
> :-)
> 
Anyways, thanks for the answer to above.

Now, just to figure out why Eclipse is happy with above.

[toc] | [prev] | [next] | [standalone]

#39440

On 4/24/2020 8:25 PM, Jeff Higgins wrote:
> On 4/24/20 6:54 PM, Arne Vajhøj wrote:
> 
>>> Where exactly in the Java environment (tools, language, standard 
>>> libraries, etc.) are two identifiers checked according to the above 
>>> specification?
>>>
>>> For instance I can do:
>>>
>>> class IdentifierTest {
>>>    class _\u0001 {}
>>>    class _\u0001\u0001 {}
>>> }
>>>
>>> and javac doesn't complain
>>
>> My javac complains.
>>
>> :-)

> Anyways, thanks for the answer to above.
> 
> Now, just to figure out why Eclipse is happy with above.

Eclipse comes with its own Java compiler - I am not
quite sure how much if at all it relies on the JDK
tools.jar.

Different implementation of a compiler can behave
differently.

Any differences in normal code will be found pretty
quickly.

But differences in funky code may go undetected
for years.

Arne

[toc] | [prev] | [next] | [standalone]

#39442

On 4/24/20 8:32 PM, Arne Vajhøj wrote:
> On 4/24/2020 8:25 PM, Jeff Higgins wrote:
>> On 4/24/20 6:54 PM, Arne Vajhøj wrote:
>>
> 
> Different implementation of a compiler can behave
> differently.
> 
> Any differences in normal code will be found pretty
> quickly.
> 
> But differences in funky code may go undetected
> for years.

Yes, is funky.
I think I'll ask in an Eclipse forum.

> 
> Arne
> 
> 

[toc] | [prev] | [next] | [standalone]

#39446

On 4/24/20 8:42 PM, Jeff Higgins wrote:
> On 4/24/20 8:32 PM, Arne Vajhøj wrote:
>> On 4/24/2020 8:25 PM, Jeff Higgins wrote:
>>> On 4/24/20 6:54 PM, Arne Vajhøj wrote:
>>>
>>
>> Different implementation of a compiler can behave
>> differently.
>>
>> Any differences in normal code will be found pretty
>> quickly.
>>
>> But differences in funky code may go undetected
>> for years.
> 
> Yes, is funky.
> I think I'll ask in an Eclipse forum.
> 

Reply from Eclipse JDT forum points to a couple of bug reports.
Both made interesting reading for me.

Cf. https://bugs.eclipse.org/bugs/show_bug.cgi?id=547817 , 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547601
Feel free to join the discussion in either of these bugs.

So, for my own use; I think I will do more reading around
Unicode UAX#31 before I decide how to implement my names.

[toc] | [prev] | [next] | [standalone]

#39447

On 4/25/2020 9:53 AM, Jeff Higgins wrote:
> On 4/24/20 8:42 PM, Jeff Higgins wrote:
>> On 4/24/20 8:32 PM, Arne Vajhøj wrote:
>>> Different implementation of a compiler can behave
>>> differently.
>>>
>>> Any differences in normal code will be found pretty
>>> quickly.
>>>
>>> But differences in funky code may go undetected
>>> for years.
>>
>> Yes, is funky.
>> I think I'll ask in an Eclipse forum.
> 
> Reply from Eclipse JDT forum points to a couple of bug reports.
> Both made interesting reading for me.
> 
> Cf. https://bugs.eclipse.org/bugs/show_bug.cgi?id=547817 , 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=547601
> Feel free to join the discussion in either of these bugs.
> 
> So, for my own use; I think I will do more reading around
> Unicode UAX#31 before I decide how to implement my names.

If you stick to [A-Za-z0-9_] then I think you will be fine.

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#39451

On 4/25/20 12:55 PM, Arne Vajhøj wrote:

> If you stick to [A-Za-z0-9_] then I think you will be fine.
> 
> :-)

Until I start debating whether to allow 0-9 as start char.

:-(
:-)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web