14202 - Java fails with two-byte charsets

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Allan Masri]

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.

Comment 1

[Frank Tang]

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.

Comment 2

[Frank Tang]

who is working on Java ? Reassign this to chofmann

Comment 3

[chris hofmann]

teruko,  you'll have to put the test case on mozilla or send to
George Drapeau <[e-mail]>

Comment 4

[Katsuhiko Momoi]

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?

Comment 5

[drapeau]

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.

Comment 6

[edburns]

Can you please make the applet available on the Internet.

Comment 7

[Katsuhiko Momoi]

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

[Katsuhiko Momoi]

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

Comment 9

[edburns]

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)

Comment 10

[edburns]

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.

Comment 11

[edburns]

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

Comment 12

[Katsuhiko Momoi]

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

[Katsuhiko Momoi]

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

Comment 14

[edburns]

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