NineChime forum

I was wondering if this is happening to Java 1.5 update 12 people, too.  I read sometime recently that the security stuff for 5 was changed the same way, though 5 is an older version with things working differently.

Good luck finding out how to fix that issue!  It'll be a hell of a headache taken off my shoulders knowing the apps will work just fine once more.

I AM SO MAD.

Well, after weeks of tearing my hair out trying to fix this issue, it's suspected that this problem is due to a bug in the Firefox Java plugin, version 1.6_03 (or possibly a problem with Firefox):

Java Bug ID: 6622150

The solution for now is to use a web browser other than Firefox.

The trouble is that I've been using Firefox for testing exclusively.  It never occurred to me to try another browser.  I just tried both Internet Explorer and Opera, and both browsers work fine.  I'll have to test Firefox and Safari on the Mac to see if the situation is different on that platform.

On the bright side, now that I know this is a Java issue and not an applet issue, work on Wacintaki 1.4 will now continue. 

With Java 5, is this with Firefox only, or all the browsers?  I have a feeling Sun is doing something funky with their security system in 6.0, because I've heard that 1.5.0_14 also has this issue, but 1.6.0.0 and 1.6.0_02 do not.  It's also possible that there is some kind of weirdness with Firefox that Sun hasn't taken into consideration, and the upcoming Firefox 3 browser might resolve the issue.  I sure hope so.

There are two problems with the applets (and by "the applets", I mean ALL of them, not just the ones by Shi-chan):

1) SocketPermission() errors.  This one is pretty much a Java/browser/handshaking issue, unfortunately.  The way it works in Java is that you specify the DNS/IP and port of the server to which you want to connect, and tell Java to make the connection.  There is nothing to initialize other than including the socket API, and Java either reports success or failure.  If it doesn't work, there's no way I can tell to get around the issue.  According to the Java documentation, it should always work, but on some servers it does not.  I cannot reproduce the problem on my own computer, so as far as testing is concerned, it's pretty much impossible for me.  I don't know that much about exception handling in Java, so I don't really know if it's possible to tell why a socket was refused.  To make matters worse, all the problems I've read on Google involve people trying to connect to "localhost" or some other local IP on their own network.  There's a lot more things that can go wrong at the local level than when connecting to a WAN, so the resolutions usually have to do with firewall settings and trial-and-error, rather than asking Java what went wrong.  Network security issues can be a real nightmare to debug.  If it's possible to fix this, it's likely over my head.  I'm a GUI guy, not a network specialist. 

2) RAW POST.  This is something I would really like to fix to improve compatibility with different servers, as RAW POST is bad, and should be replaced by multipart encoding.  Just updating the POST forms is pretty easy.  However, since most of these applets are Japanese, and they are designed to work with JIS or UTF-8, there's usually a lot of bit shifting and masking going on, and it's all smack in the middle of the bytestream code instead of in dedicated objects.  Refactoring the encoding basically involves cutting out huge sections of the program.  Which leads me to...

I say you should go ahead, and just keep her as the creator and make sure she is listed as such when it runs and stuff, and just say it's been updated by you.

It's just not that simple.

I'm decompiling the applets, and thus have no documentation, code comments, or proper variable names.  Even small changes can drastically change the behavior of the applets.  If things seem to work, I leave them alone.  I really shouldn't be messing around with other peoples' works.  I really do feel that I hijacked OekakiPoteto, and feel very fortunate that Mr. Chakkapark gave me official permission to release it after I put all that work into it.  I don't want this kind of development to turn into a habit.

I wish there were more people working on oekakis these days.  It's sad to see that the whole oekaki scene has taken a huge nosedive within the last two years.

Good to know...if it's a Firefox bug, then hopefully it'll be fixed eventually. I just had this problem today.
Anyway, thank you as always, Wac. I love this program. Shame I can't seem to convince my site visitors quite as much, though!

Changing paths didn't work for me either 

The problem only affects some servers.  Most servers will work fine, but a handful will not.  I have the latest version of Java (1.6.0_06), and there are still some boards out there that will not allow me to submit pictures with Firefox.

Has solution been found yet?

Well, Sun claims to have fixed this problem multiple times, but the error persists, so I guess not.

The problem is that Java is typically used for servers these days, and applets are no longer important to the developer's bottom line.  Also, most uses for Java (such as for VPN tunnels) require an applet to be "signed" so it will only work with just one web site, such as an individual corporate site.  That makes things very difficult for applets that are redistributable so they can be used on any number of sites.  By design, an applet isn't supposed to be able to send streams of data to any server unless the applet was also downloaded from that server.  It's essentially an anti-spamming measure -- a very frustrating one.

The good news is that this problem only affects a relatively small number of servers, so you'll only have to use IE on some oekaki boards, and not all of them.  I'm still looking for workarounds, but according to Sun's developer site, there simply isn't one, other than signing the applet.

Drawing animations also don't load

This could be related to advertisements interfering with the animation data, which is a common problem.  To fix this, the ".htaccess" file in the Wacintaki documentation folder must be copied to the server and the server must have ".htaccess" files enabled.  This tells the server not to interfere with downloads with the "PCH" and "OEB" file extensions.  This can only be done by the owner of the oekaki.

More detailed instructions are in the Wacintaki manual.

It's not a firewall issue, it's Java itself.  Java has a security policy file somewhere that is blocking the site.

Every browser requires a Java different plug-in with its own security policy, and it's the differences between the plug-ins that result in different behavior between the browsers.

The IE version works and always has, the Opera version was working for a while and apparently isn't working anymore, and the Firefox version has been broken for quite a while.