Many 4k applets not working

Quite a few… ok most of the current 4k entrys on the 4k page do not work for me. They all fail with a class not found exception:

./jdk1.6.0_13/bin/appletviewer ""
load: class k.class not found.
java.lang.ClassNotFoundException: k.class
        at sun.applet.AppletClassLoader.findClass(
        at java.lang.ClassLoader.loadClass(
        at sun.applet.AppletClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
        at sun.applet.AppletClassLoader.loadCode(
        at sun.applet.AppletPanel.createApplet(
        at sun.applet.AppletPanel.runLoader(

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.


Strange!! They all work fine on my laptop (Windows, jdk1.6)…

sounds like a client side pack200 issue to me…

I wonder if Appel has set up his web server to send back “normal” JAR versions if the pack200 versions are not accepted by the client… this may sove delt0r’s problems.

AlanW notified me of this earlier.

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.

Ok, won’t be able to look at this until tomorrow… new years eve and all.

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.

I’ve had problems with the Pack200 applets, but it’s specific to Opera. They all work fine in IE and Firefox.

-- Opera - Java Console --

Java vendor: Sun Microsystems Inc.
Java version: 1.6.0_17

type 'h' for help

java.lang.ClassNotFoundException: a
	at com.opera.AppletClassLoader.findClass(
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at com.opera.AppletClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at com.opera.AppletPanel.runLoaderThread(
	at Source)
Caused by: HTTP Connection failed.
	at com.opera.AppletClassLoader.readClassFile(
	at com.opera.AppletClassLoader.access$100(
	at com.opera.AppletClassLoader$
	at Method)
	at com.opera.AppletClassLoader.findClass(
	... 6 more

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.

Which browser?

Same here, most 4k applets gives java.lang.ClassNotFoundException:

MacOSx 10.5.8, Safari 4.04
Tried with both Java 1.6.0_17, 64 bit and Java 1.5.0_22, 32bit

[quote]Which browser?
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.

Actually, it’s the other way around:

The client MUST request a *.jar WITH Accept-Encoding: pack200-gzip
The server will responds with a *.jar.pack.gz file, passing Content-Encoding: 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:

// On receiving a request work out what to send
File FindResource(Path, MimeType, Encoding) {

  // Check for Pack200

  if (MimeType == "application/x-java-archive" OR
      MimeType == "application/java-archive") AND
      Encoding.toLowerCase().contains( "pack200-gzip") then
    if exists(path+".pack.gz") // Actually datestamp check
      return getResource(path+".pack.gz")

  // Check for Gzip
  if Encoding.toLowerCase().contains("gzip") then
    if exists(path+".gz")
      return getResource(path+".gz")

  // No compression
  if exists(path)
    return getResource(path)

  // Not Found
  return null

// Select Content encoding for transmission with the file we are sending
Content-Encoding GetEncoding(file) {

  // Pack200
  if file.getName.endsWith(".pack.gz") then
    return "pack200-gzip"

  // Gzip
  if file.getName.endsWith(".gz") then
    return "gzip"

  return null

Edit: updated with “contains()” to make it clear we are checking for a substring

Sorry, poorly phrased on my part ::slight_smile:
I take it the premise of what should happen is still correct though?

<1.5 “I’ll have this jar please.”

=1.5 “I’ll have this jar please, though a pack200-gzip would be super-smashing-great too!”

To make the user experience better… perhaps java4k should only send the JAR and not the pack.gz version no matter what the client says…

The pack.gz is there to qualify as meeting the 4k limit… only the judges care, the general user does not really care…

We could also just send a .zip file that is below 4k with a .jar that might be over 4k… But we lost all the fun of the compression trick.

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:

/applet.php?gid=282 (server replies with pack200-gzip'd file)
/k.class (server replies with 404)
/k/class.class (server replies with 404)

and then gives up.

But get this: on all three requests, appletviewer sends the following header:

User-Agent: Java(tm) 2 SDK, Standard Edition v1.6.0_0 Java/1.6.0_0


Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive

It’s trying to download a class or jar, and it claims to prefer the server to reply with HTML pages and images.

The critical point is that there’s no Accept-Encoding header at all.

BTW, despite the User-Agent this is 1.6.0_15.

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)

<applet archive="Kuest.jar.gz" code="k.class"   width="800" height="550">
        <PARAM NAME="java_arguments" VALUE="-Djnlp.packEnabled=true" />
                  <PARAM NAME="cache_archive" VALUE="Kuest" />

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.