Applet Demo smooth download and splash (Updated 2007-12-13) : New version

[Matzon]

@jojoh

Well, what do you suggest?

I suggested 4 things already…

@jojoh

Agree with Thijs response. This example pretty much could have fooled any browser gamer into not realizing that it is an applet starting and that means that the major issue actually is solved.

How do you fool someone when the applet you’re delivering is 2-3MB, try his stuff with that… You will be looking at a boring gif for a long time…

[DzzD]

Source code updated (I introduced a MSJVM bugs while trying to resolve a bug appening in safari browser), it is now resolved new version works with MSJVM

anyone able to test Safari browser ?

[quote]I suggested 4 things already…
[/quote]
Your suggestion sounds like saying everybody all over the world to “download & intall lastest JVM” ?

[quote]How do you fool someone when the applet you’re delivering is 2-3MB, try his stuff with that… You will be looking at a boring gif for a long time…
[/quote]
3DzzD Applets use ressource up to 10 meg… and it works… it just load them at runtime…(as JOGL>1meg, or textures or 3D files) what append if you try to insert a 4gb picture or HTML source code in your website ? it hang… same for applets, you should not start with a too big class, this is true in any program and any language.

How you can make applet with a 2MB size ? if so you are includiing ressource files in jar wich is for me a wrong way, you should load it at runtime than you are able to show whatever you want while loading. as said above main/base classes must be as little as possible, same for html same for everythings… an html is first loaded and once loaded image are loaded, Web software should not be made as CD software.

I will put a quake level applet sample able to use JOGL ( about 6meg for the whole stuff 5meg for 3d & 1meg for jogl) online showing that the system is able to not hang even with big downloads.

[thijs]

@Matzon

How do you fool someone when the applet you’re delivering is 2-3MB, try his stuff with that… You will be looking at a boring gif for a long time…

Well an applet that big has probably many resource files, which like Brackeen and I pointed out can be downloaded at runtime. Unfortunatly using the caching trick its not possible to display actual progress but at least you’ll be able to show something different and more interactive than an animated gif.

EDIT:
In Dzzd we can also stream certain resources, so the applet can start earlier while loading resources not needed right away in the background

[DzzD]

Source code updated, add message when unable to start applet also ask the user to install java if unable to detect any JVM

next step will be to make the whole stuff configurable (LOGO,message,…), please continue to feedback about bugs or other …

[DzzD]

Source code updated, now works with Safari 3.0.4 windows XP

anyone able to test:
Mac + IE ?
Linux ?

[Matzon]

you can easily have a big jar file without resources - and then this doesn’t really work. It mitigates it a bit, but it doesn’t really fix it.

[brackeen]

Works on Safari/Mac, too.

I agree, there is no way to get the ideal solution given the current restrictions. Best you can do within the limits of the sandbox is have the two-stage load:

Stage 1: show animated gif while the JVM and jar is loaded. (note, the Java plugin- “image” attribute splash isn’t shown until the JVM is loaded, and it can’t be animated)
Stage 2: show fancy shmancy loading splash while assets are downloaded.

This solution is best if your code isn’t too big, and you’ve got a sizable chunk of assets.

[CaptainJester]

@brackeen

So, you’re talking about making, say, a tiny Bootstrap.jar which would show a fancy shmancy splash, with a progress bar, while the main game jars are downloaded? Unfortunately that requires creating a custom classloader, or doing other classloader tricks that you can’t do with the default applet permissions.

You can, however, keep game assets (not classes) in an external jar and show a fancy shmancy splash while those are loading.

Do you really need a custom classloader? Can’t you just use the URLClassLoader? I made a post on GameDev about this. Can you read and tell me what you think?

http://www.gamedev.net/community/forums/topic.asp?topic_id=474026

[brackeen]

@CaptainJester

Do you really need a custom classloader? Can’t you just use the URLClassLoader? I made a post on GameDev about this.

Yeah, just to instantiate URLClassLoader requires the “createClassLoader” permission, not given to applets. If you did have the permission, though, a custom class loader would be better because you could track the progress of the download, for the sake of a progress bar.

[thijs]

@Matzon

you can easily have a big jar file without resources - and then this doesn’t really work. It mitigates it a bit, but it doesn’t really fix it.

Maybe an applet that big should really be an application. Like brackeen mentioned it’s not really possible given the sandbox restrictions. The only solution would be to have the applet signed and download / cache the files when / where needed.

@CaptainJester

Do you really need a custom classloader? Can’t you just use the URLClassLoader? I made a post on GameDev about this. Can you read and tell me what you think?

http://www.gamedev.net/community/forums/topic.asp?topic_id=474026

Anything that touches classloaders needs privileges outside of the sandbox. It is however possible to make an minimal bootstrap applet (unsigned) that loads up quickly using a JS loader like Bruno & brackeen presented, and have it load a signed class at runtime. The advantage would be you’d have a quick booting applet in which you can show progress and also tell the user about the security message it’s about to see (for example to tell them why its required). Then have the user click ok and start the signed class which will start the actual downloading of the (big) applet. Something similar as I posted here:
http://www.java-gaming.org/forums/index.php?topic=16911.msg135173#msg135173

[DzzD]

[quote]you can easily have a big jar file without resources - and then this doesn’t really work. It mitigates it a bit, but it doesn’t really fix it
[/quote]
so why not loading it at runtime ?

My thought it that this JavaScript doesn’t solve all problems but it make the first step of starting and applet looks a lot more better, if you want to use some big jar than simply load them at runtime!! and show a progress bar in java. that’s all nothing really hard to achieve. the goal was to enable anyapplet to use it without modifications.

[quote]Yeah, just to instantiate URLClassLoader requires the “createClassLoader” permission, not given to applets. If you did have the permission, though, a custom class loader would be better because you could track the progress of the download, for the sake of a progress bar.
[/quote]
from http://forum.java.sun.com/thread.jspa?forumID=4&threadID=435579 cant work ?

For anyone else that has also run into this problem and wants a simple solution I created this class:

/*
* Created on Aug 11, 2004
*/
import java.io.*;
import java.net.*;
import java.util.*;
import java.util.jar.*;

/**
* @author Matthew D. Hicks
*/
public class JARClassLoader extends URLClassLoader {
protected File file;
protected JarFile jar;

public JARClassLoader(File file) throws MalformedURLException, IOException {
super(new URL[] {file.toURL()});
this.file = file;
this.jar = new JarFile(file);
}

public Class[] getClasses() throws ClassNotFoundException {
ArrayList list = new ArrayList(500);
Enumeration e = jar.entries();
JarEntry entry;
while (e.hasMoreElements()) {
entry = (JarEntry)e.nextElement();
if ((!entry.isDirectory()) && (entry.getName().endsWith(".class"))) {
list.add(entry.getName().replaceAll("/", ".").substring(0, entry.getName().length() - 6));
}
}
Class[] classes = new Class[list.size()];
for (int i = 0; i < list.size(); i++) {
classes = this.loadClass((String)list.get(i));
}
return classes;
}

public static void main(String[] args) throws Exception {
File file = new File("myclasses.jar");
JARClassLoader loader = new JARClassLoader(file);
Class[] classes = loader.getClasses();
for (int i = 0; i < classes.length; i++) {
System.out.println("Class: " + classes.getName());
}
}
} 

[jojoh]

@Matzon

I suggested 4 things already…

Then I must not have understood it. The typical example where this example probably would be applied, would be an applet game, say ~250K large and a user with win XP, FF 2.0 or IE 6-7 and Java 1.4.

Could you put up an example using your suggestions, where this user would get as pleasant loading and startup experience as a typical flash game or as this shared code example? I would really like to see that, since it would be really useful to me.

@Matzon

How do you fool someone when the applet you’re delivering is 2-3MB, try his stuff with that… You will be looking at a boring gif for a long time…

Well, I am not quite sure how it works to be honest, but wouldn’t an animated gif be a hell of a lot better than a frozen browser for the same amount of time? He is just offering some code to people who might want to use it. He never said that it would end world hunger or even make applets load in a perfect way for any conceivable situation, just that it might provide a more pleasant loading experience for typical applet games I assume.

[Matzon]

@DzzD

so why not loading it at runtime ?

My thought it that this JavaScript doesn’t solve all problems but it make the first step of starting and applet looks a lot more better, if you want to use some big jar than simply load them at runtime!! and show a progress bar in java. that’s all nothing really hard to achieve. the goal was to enable anyapplet to use it without modifications.

you can’t load code at runtime, unless you’re signed. Signing is bad because of the “scary” dialog.

[Matzon]

@jojoh

Then I must not have understood it. The typical example where this example probably would be applied, would be an applet game, say ~250K large and a user with win XP, FF 2.0 or IE 6-7 and Java 1.4.

250k on a dial up modem is probably at least a minute of waiting where you dont see anything but the standard java loader. I want a fix where I can take over immediatly after bootstraping using a small 3-5k jar payload.

@jojoh

Could you put up an example using your suggestions, where this user would get as pleasant loading and startup experience as a typical flash game or as this shared code example? I would really like to see that, since it would be really useful to me.

it can’t be done without signing the applet, which defeats the whole purpose.
You need to look at it this way. A flash applet is launched as soon as its possible to play the first part of the movie. An applet is launched as soon as all of the code has been downloaded - regardless if its used from the instantiated applet class.

@jojoh

Well, I am not quite sure how it works to be honest, but wouldn’t an animated gif be a hell of a lot better than a frozen browser for the same amount of time? He is just offering some code to people who might want to use it. He never said that it would end world hunger or even make applets load in a perfect way for any conceivable situation, just that it might provide a more pleasant loading experience for typical applet games I assume.

The freezing issue is the least of my worries - it usually just takes a second or two. My main problem is the lack of a proper splash screen on large applets - like Flash has. This solution doesn’t fix it.
Furthermore I have continually said that this solution is a fine solution, but its still doesn’t fix anything, its just hiding the issues. The real issue can unfortunately only be fixed by Sun.

Hopefully when the GPL’ed version of the new Java plugin is released we can fix it ourselves.

[thijs]

@Matzon

250k on a dial up modem is probably at least a minute of waiting where you dont see anything but the standard java loader. I want a fix where I can take over immediatly after bootstraping using a small 3-5k jar payload.
it can’t be done without signing the applet, which defeats the whole purpose.

You need to look at it this way. A flash applet is launched as soon as its possible to play the first part of the movie. An applet is launched as soon as all of the code has been downloaded - regardless if its used from the instantiated applet class.

I understand your concerns and I struggled with this too when developing (applet) webgames. But a typical webgame is no more than 50K (for it’s classes), while my data files where typically 200K+. The datafiles can be easily downloaded & cached at runtime with the technique described earlier in this thread while displaying some (loading) screens in your applet. This is what I did for Arcazoid and I never heard a complaint from modem users.

If your classes are over 250K you’re maybe better off with a little bootstrap loader and a signed class which can be instanciated at runtime from this (sandboxed) loader class (also described somewhere in this thread). I shouldn’t worry too much about users being scared away of the security dialog. Some of the most popular webgames require users accepting security warnings about activex, shockwave/java certificates, they almost always click any message away with OK (without even bothering what the message is about). Also a bootstrap class that initiates the signed class, you’d be able to show some fancy animation explaining the action to the user.

Edit:
Offcourse an improved JVM could help a lot with these issues, fixing this problem at its roots and enabeling us to do more fancy stuff. But unfortunatly most of us need to be backward compatible as older JVM’s like 1.4 are probably here to stay for a little while longer. Using a combination of the techniques described in this post we could create an as good as possible user expirience even for the ones not fully up to date.

[DzzD]

[quote]The real issue can unfortunately only be fixed by Sun.
[/quote]
I undestand what you mean but!!! I have a good new , there is maybe a warkaound that could works with any applets and any JVM, I am working on such sample today if I have enought time I should be able to post it today.

[Matzon]

@thijs

I understand your concerns and I struggled with this too when developing (applet) webgames. But a typical webgame is no more than 50K (for it’s classes), while my data files where typically 200K+. The datafiles can be easily downloaded & cached at runtime with the technique described earlier in this thread while displaying some (loading) screens in your applet. This is what I did for Arcazoid and I never heard a complaint from modem users.

I dont do “typical” applets - but multiplayer applets that approach 500k in size, obfuscated.

@thijs

If your classes are over 250K you’re maybe better off with a little bootstrap loader and a signed class which can be instanciated at runtime from this (sandboxed) loader class (also described somewhere in this thread). I shouldn’t worry too much about users being scared away of the security dialog. Some of the most popular webgames require users accepting security warnings about activex, shockwave/java certificates, they almost always click any message away with OK (without even bothering what the message is about). Also a bootstrap class that initiates the signed class, you’d be able to show some fancy animation explaining the action to the user.

Signing isn’t an option. Not only do we support Java 1.1 but the distribution and signing of 1.1 and 1.3+ makes it less ideal. Furthermore a security dialog will make people less likely to play a game - this is a fact. We tried it.

@thijs

Edit:
Offcourse an improved JVM could help a lot with these issues, fixing this problem at its roots and enabeling us to do more fancy stuff. But unfortunatly most of us need to be backward compatible as older JVM’s like 1.4 are probably here to stay for a little while longer. Using a combination of the techniques described in this post we could create an as good as possible user expirience even for the ones not fully up to date.

Fortunately a lot of people are upgrading to 1.4 and once they get onto 1.4 they auto-update to newest version often. However we’re still seeing a lot of people using 1.1
1.2 and 1.3 users are somewhat rare.

[Matzon]

@DzzD

I undestand what you mean but!!! I have a good new , there is maybe a warkaound that could works with any applets and any JVM, I am working on such sample today if I have enought time I should be able to post it today.

oh, that sounds nice - looking forward to whatever you come up with

[JonathanC]

@Matzon

The real issue can unfortunately only be fixed by Sun.

Sun will fix it, no doubt, but my worry is whether users will all have this new plugin. It’s catch-22.

[DzzD]

I slept all the day yesterday, but today I have done some work and after investigating a lot of differents possibilities I finnaly found a workable workaround :-), works with all JVM including MSJVM to SUNJVM 1.6, I have to polish it enought now, It simply enable runtime loading of an applet without signing problem, will try to post as soon as possible.

Tested on Window XP : Internet explorer/Firefox 1.5/Safari3.0.4