Example of ones that work is BoxBot4k, and ones that don't work are Maze4k and FortressFall4k and GTA4k (but that worked from the devs page).

I am on linux (slackware) and is dose not matter if we are in a browser or using an appletviewer, it either works in both or neither (java 1.6u13 64bit). I first noticed the problem in fish4k and there is a post or 2 on the matter in that thread. Would be nice to resolve the issue.

Cheers

I have no special talents. I am only passionately curious.--Albert Einstein

As Appel noted, I had the same issue with OSX 10.4 with Java 1.5.0 with both Safari & Firefox. No problems with Windows + Java 1.6. I loaded a pack.gz on my own Tomcat server along with an empty jar (needed by the server code, but obviously the jar contains no code). This worked Ok on the Mac, so the problem most likely relates to headers or file names. I also wondered whether folks had created java 1.6 format pack200's by mistake, but if delt0r is having trouble even with java 1.6, that seems less likely.

Am currently on my hols in the UK (at a mates house) and none of the games on the java4k website work here (same exception as above).Running JRE 1.6. My 4K game works on my personal site (similar applet code), so maybe the reason is that I have the .jar version on my webserver too (aswell as the .jar.gz) and the java4k only has the.jar.gz version... Dunno just a guess.

Am currently on my hols in the UK (at a mates house) and none of the games on the java4k website work here (same exception as above).Running JRE 1.6. My 4K game works on my personal site (similar applet code), so maybe the reason is that I have the .jar version on my webserver too (aswell as the .jar.gz) and the java4k only has the.jar.gz version... Dunno just a guess.

Firefox (3.0.17), but wouldn't have thought this was the issue.. I dont know much about pack2000 but if the client cannot unpack the .jar.gz file does it not ask the server for the .jar file instead? In which case should'nt the java4k server have both the .jar.gz and the .jar file? When I submitted my game it only asked me to upload the .jar.gz file. Maybe if appel can extract one of the .jar files from a .gz file on the java4k server I can test whilst am still here (2 more days) to see if this is the issue.

Firefox (3.0.17), but wouldn't have thought this was the issue.. I dont know much about pack2000 but if the client cannot unpack the .jar.gz file does it not ask the server for the .jar file instead? In which case should'nt the java4k server have both the .jar.gz and the .jar file? When I submitted my game it only asked me to upload the .jar.gz file. Maybe if appel can extract one of the .jar files from a .gz file on the java4k server I can test whilst am still here (2 more days) to see if this is the issue.

I think the point is, no clients should be asking for the .jar file.Either the client is pre-1.5 and so cannot run the application anyway, or they are 1.5+ and so should be able to handle the pack200 gzip.

I've been looking at the java jnlp servlet code, which successfully downloads pack200 on my mac with Java 1.5. The codes a bit convoluted, but I think I've extracted the key bits and converted them into non-java pseudo-code. It does this:

No, the web server doesn't send back a normal JAR if pack200 isn't accepted by the client. I would have thought anyone with JRE 1.5 and up would be able to run pack200?

I was hoping pack200 would work seamlessly, but Sun never disappoints me in their failures on the end-user front.

Yep, this is spectacular fail on Sun's part.

Taking the example link (Kuest), it works fine with the Java plugin in Firefox, but appletviewer (same version of Java, same machine) doesn't work. Sniffing with wireshark, I see that appletviewer makes the following series of requests:

Ok, Still confused.. As mentioned am running JRE 1.6 at mates house, so why isnt the pack2000 stuff working, or does it only work if you have the JDK installed? Kuest, when run from my own website works here (See below) but not the java4k version. I seem to remember it not working if the Kuest.jar file was not on the server (unfortunately not got putty here so can't test for certain this is the case).

Ok, Still confused.. As mentioned am running JRE 1.6 at mates house, so why isnt the pack2000 stuff working, or does it only work if you have the JDK installed? Kuest, when run from my own website works here (See below) but not the java4k version. I seem to remember it not working if the Kuest.jar file was not on the server (unfortunately not got putty here so can't test for certain this is the case).

In the cache archive parameter you have to omit the extension part (.jar bit)

JNLP for applets only came in with plugin2 (which means Java 1.6u10+).The code on Java4k isn't friendly to the original plug in so Java 1.5 causes problems.

I know that pack200 does work on Java 1.5 on my Mac, because I tested it using Tomcat and the jnlpdownloadservlet. I would note that there are two valid mime types for java archives and Accept Encoding may arrive in upper or lowercase (or maybe even mixed case) - conclusion reached after reading servlet code. I also noted that the servlet code trims off any whitespace from the file name before appending .pack.gz. Could be the problems in the implementation detail on Java4k.

JNLP for applets only came in with plugin2 (which means Java 1.6u10+).The code on Java4k isn't friendly to the original plug in so Java 1.5 causes problems.

I know that pack200 does work on Java 1.5 on my Mac, because I tested it using Tomcat and the jnlpdownloadservlet. I would note that there are two valid mime types for java archives and Accept Encoding may arrive in upper or lowercase (or maybe even mixed case) - conclusion reached after reading servlet code. I also noted that the servlet code trims off any whitespace from the file name before appending .pack.gz. Could be the problems in the implementation detail on Java4k.

I'm pretty sure that the results I post above show that the problem is at least partly client-side and post-plugin2.

I'm pretty sure that the results I post above show that the problem is at least partly client-side and post-plugin2.

I did see you comments on AppletViewer, a somewhat flaky app in my opinion - It doesn't meet spec on when the init() and start() methods are called w.r.t. window creation - and so am not entirely surprised that it doesn't set Accept Encoding correctly. However I'm fairly certain the plugins do set it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org