JDK-4263520 : Can't compile source with ASCII digits on Arabic Solaris
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio.charsets
  • Affected Version: 1.1.6,1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_7,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1999-08-18
  • Updated: 1999-10-01
  • Resolved: 1999-09-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
JDK-4244305 - JDK1.3 javac does not work in 'ar' locale
Duplicate :  
JDK-4336300 - Arabic iso8859-6 encoding files are incorrect for numerals
Relates :  
JDK-4336841 - Arabic locales do not have \u0660 as zero digit base
Description
Solaris(locale set to ar)2.7/Sparc with N build.

javac can't compile any source that has a numeric number. If a source code 
doesn't have a number I was able to compile but wasn't able to run it. 

MyTest.java:?: illegal character: \????
      System.exit(5);
                  ^

[The following symptom is a duplicate of 42558439. Please disregard here - norbert@eng 1999-08-20]
When I run any precompiled code(for example, build N's SwingSet demo) it gives 
me like no matter what with or without -classic, 

java -jar SwingSet.jar
Exception in thread "main" java.lang.UnsatisfiedLinkError: initDisplay
        at sun.awt.X??GraphicsEnvironment.initDisplay(Native Method)

I can't compile or run anycode in arbic Solaris2.7 with solaris patch for 
kestrel.        
                            
(what we did)
. install arbic/hebrew locale
. install solaris patch for kestrel
. set JAVA_FONTS environment to [JDK]/jre/lib/fonts (we also tested without setting JAVA_FONTS we saw the same problem)

Unless we missed other steps build N doesn't work in ar Solaris2.7.

(notes)
When we run the same thing in hebrew locale Solaris2.7 it was perfectly fine.
classic/hotsparc vm returns the same problem in arabic locale Solaris2.7.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: kestrel VERIFIED IN: kestrel
14-06-2004
EVALUATION Since the basic symptom reported here is that the compiler fails to parse MyTest.java I suspect that this is not a Swing problem. I'll reassign the bug to subcategory compiler. hans.muller@Eng 1999-08-18 The problem is apparently that digits in the compiler input stream are not being represented by the correct unicode characters. The bogus values apparently print as '?' characters, and because names including such characters get inserted into the class files, the runtime problems are due to the same underlying cause. The compiler simply creates an InputStreamReader with the platform default encoding and expects it to return the digits and other characters used in Java source code correctly. This looks like a 2.7 platform problem to me. It would be helpful to see if the problem is reproducible using 'oldjavac', which I would expect to behave identically based on the analysis above. Note that if the input file is not in the platform default encoding, it will be necessary to specify the encoding using the '-encoding' command-line switch. This is correct compiler behavior. william.maddox@Eng 1999-08-18 Arabic Solaris uses the ISO 8859-6 encoding, which, according to the mapping table at www.unicode.org, doesn't have the ASCII digits. The second part of the bug description, the UnsatisfiedLinkError, is a duplicate of 4258439. We'll use this bug (4263520) to track only the compilation issue. norbert.lindenberg@Eng 1999-08-20 [xueming.shen@Eng 1999-09-07] In the latest version of the iso8859-6->unicode mapping table at unicode.org (27, July, 1999 updated), 0x30-0x39 has been remapped to the ASCII digits (U+0030..U+0039) instead of the Arabic digits (U+0660..U+0669), I will update our converters and its respective mapping based on the this updated table. (the unicode version is also updated to 3.0 in the latest mapping table)
11-06-2004
WORK AROUND Pass "-encoding ASCII" option to javac. You can't use ISO8859_1 because the digits, again, are translated to Arabic numerals, which don't match the class names. norbert.lindenberg@Eng 1999-08-20
20-08-1999