Bugzilla – Full Text Bug Listing
| Summary: | \u1369 no longer accepted as a valid java identifier part | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> |
| Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | raksha.vasisht |
| Version: | 3.7 | ||
| Target Milestone: | 3.7.1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
I think the way to fix this would be to use the Unicode6.xml data to generate the scanner tables and then using the Unicode 4 data to "update" the tables according to the original Unicode 4 specifications. I'll build a list of all characters that have changed for Unicode 4.0. Released in BETA_JAVA7 branch only. Verified. |
The original Unicode 4.0 specification (java version <= 1.6) specifies that this character is a valid java identifier part (Nd category). 1369;ETHIOPIC DIGIT ONE;Nd;0;L;;1;1;1;N;;;;; When working on adding Unicode 6 support, I rebuilt the scanner resource file for java 1.6 also and I introduced a problem for this character since in the Unicode 6 specification, it has been reclassified inside the No category which does no longer make it a valid java identifier part. This was done even if the character was introduced in Unicode 3.0. <char cp="1369" age="3.0" na="ETHIOPIC DIGIT ONE" JSN="" gc="No" .../> So this code: public class X { int a\u1369b; } should compile with compliance 1.6, but no longer compile with compliance 1.7 or above. You can check that by compiling it using javac 1.6 and then using latest (b147) javac 1.7.