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(AppletClassLoader.java:369)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.AppletClassLoader.loadClass(AppletClassLoader.java:433)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.AppletPanel.runLoaderThread(AppletPanel.java:410)
at com.opera.AppletPanel.run(AppletPanel.java:384)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: HTTP Connection failed.
at com.opera.AppletClassLoader.readClassFile(AppletClassLoader.java:378)
at com.opera.AppletClassLoader.access$100(AppletClassLoader.java:34)
at com.opera.AppletClassLoader$4.run(AppletClassLoader.java:360)
at java.security.AccessController.doPrivileged(Native Method)
at com.opera.AppletClassLoader.findClass(AppletClassLoader.java:358)
... 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?
[/quote]
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")
EndIf
// Check for Gzip
if Encoding.toLowerCase().contains("gzip") then
if exists(path+".gz")
return getResource(path+".gz")
EndIf
// 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 :
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
Host: java4k.com
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).
[quote]
[/quote]
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" />
</applet>
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 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.
Edit: Note Accept and Accept-Encoding header fields are different!
GET /applets/applet-5.7.0.2.jar HTTP/1.1
content-type: application/x-java-archive
accept-encoding: pack200-gzip,gzip
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_03
Accept: text/html, image/gif, image/jpeg, ; q=.2, /; q=.2
Also need to check substring in Accept-Encoding as different browsers will send different things in the comma separated list. servelet does:
encoding.toLowerCase().indexOf(PACK200_GZIP_ENCODING) > -1){
Silly Question: Does Appletviewer support pack200? [After testing - coming to conclusion it does not]