Java fails with two-byte charsets

VERIFIED FIXED

Status

Core Graveyard
Java: OJI
P3
normal
VERIFIED FIXED
18 years ago
7 years ago

People

(Reporter: Allan Masri, Assigned: edburns)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
on WinNt4.0, with seamonkey 1999091608

steps to reproduce:
1. install jre
2. launch seamonkey.
3. load the url, http://kaze:8000/javademo.htm.

result:
Applet fails to run. Applet contains Japanese characters. This works with
Communicator 4.7.

Updated

18 years ago
Component: Internationalization → Java APIs to WebShell

Comment 1

18 years ago
The URL should be http://kaze:8000/javademo.html not
http://kaze:8000/javademo.htm

This is a Java problem. I am not sure which Component to assign to. Reassign to
Java API to WebShell for now.

Updated

18 years ago
Assignee: ftang → chofmann

Comment 2

18 years ago
who is working on Java ? Reassign this to chofmann

Updated

18 years ago
Assignee: chofmann → drapeau

Comment 3

18 years ago
teruko,  you'll have to put the test case on mozilla or send to
George Drapeau <george.drapeau@eng.Sun.COM>

Comment 4

18 years ago
I think we should make some new applets with JDK 1.2 compatibility.
Most of these applets have been made for 1.02 and only a few
for 1.1. Who know what classes have been deprecated since then?

Updated

18 years ago
Assignee: drapeau → edburns

Comment 5

18 years ago
I'm re-assigning this bug to Ed Burns, the module owner for WebShell (in our
group).  Thank you for assigning this to me.  If you have any test data that we
can use to reproduce the bug, I would much appreciate it.

Updated

18 years ago
QA Contact: teruko → amasri
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

18 years ago
Can you please make the applet available on the Internet.

Comment 7

18 years ago
Let me suggest 2 applets which have been externalized to public
sites as part of a papaer read by Frank Tang at a Unicode conf a few
years back. He has 5-6 examples but because of outdated links, only a
couple seem to be working now:

http://people.netscape.com/ftang/paper/unicode9/page0007.htm

and

http://people.netscape.com/ftang/paper/unicode9/page0027.htm

You need to have a font which includes Japanese glyphs for these
pages. Also as these applets were based on JDK 1.02, deprecated font
names are used. For this reason, you need to modify the font.properties
file to turn on font aliasing as follows:

alias.timesroman=serif
alias.helvetica=sansserif
alias.courier=monospaced

Comment 8

18 years ago
If you are in need of Windows Unicode font, we have externalized
Bistream Cyberbit 2.0 at:

ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/

get the Cyberbit.ZIP file.

I have a modified font.properties file with this font here:

http://home.netscape.com/eng/intl/docs/jdkfont/nt4/font.properties

you can use this as an exmple to modify your settings.

Also I have externalized more general info on this here:

http://home.netscape.com/eng/intl/jdkfontinfo.html
(Assignee)

Comment 9

18 years ago
Here's the stack trace:

stantiateFullPagePlugin.. returning
InstantiateEmbededPlugin for application/x-java-vm
InstantiateEmbededPlugin find stopped
Document http://people.netscape.com/ftang/paper/unicode9/page0007.htm loaded suc
cessfully
Document: Done (3.184 secs)
java.security.AccessControlException: access denied (java.net.SocketPermission j
ava.sun.com resolve)
        at java.security.AccessControlContext.checkPermission(Unknown Source)
        at java.security.AccessController.checkPermission(Unknown Source)
        at java.lang.SecurityManager.checkPermission(Unknown Source)
        at java.lang.SecurityManager.checkConnect(Unknown Source)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection.connect(Unknown Sour
ce)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unkno
wn Source)
        at java.net.HttpURLConnection.getResponseCode(Unknown Source)
        at sun.applet.AppletClassLoader.getBytes(Unknown Source)
        at sun.applet.AppletClassLoader.access$100(Unknown Source)
        at sun.applet.AppletClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.applet.AppletClassLoader.findClass(Unknown Source)
        at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadCode(Unknown Source)
        at sun.applet.AppletPanel.createApplet(Unknown Source)
        at sun.plugin.AppletViewer.createApplet(Unknown Source)
        at sun.applet.AppletPanel.runLoader(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

18 years ago
After making the modifications to my workstatation to accomodate SUN's firewall
policy, as suggested in http://bugzilla.mozilla.org/show_bug.cgi?id=1577 , I
have retested this bug and found that it now no longer manifests.

To verify, please use a Java Plugin from 10/14/99 or later.  Any attempts to
verify using an earlier version of the Java Plugin will be summarily rejected.
(Assignee)

Comment 11

18 years ago
*** Bug 13445 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
Questions:

1. When you say "Java Plugins later than 10/24/99", you don't mean
   what we get internally at Netscap,do you? For example, I tried
   the latest beta version available at JavaSoft and they
   generally work and we can see that problem applets actually
   run. But our internal JRE 1.2.2 distribution has not been
   updated since 9/15/99 or so. So, are you refering to the JRE 1.2.2
   or 1.3 Beta?

2. Now that these applets more or less run, we can see the real problem
   for i18n, i.e. that strings do not show correctly in Japanese
   and other multi-byte languages.

In our internal tests, there are still a few applets that will not run
but these can be dealt with in this bug.

For the display problem, we should file a separate bug, which is what I will
do now.

Comment 13

18 years ago
The Japanese (and other non-ASCII languges) display bug has been filed
as Bug 17169.
(Assignee)

Comment 14

18 years ago
Please talk to cyeh to get a more recent version of the JDK.

Updated

18 years ago
Component: Java APIs to WebShell → OJI
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED

Updated

7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.