Para aprender de que va el classpath y como configurarlo:
http://java.sun.com/j2se/1.4.2/docs/...classpath.html http://www-128.ibm.com/developerwork...lasspath-unix/
De este ultimo, cito:
Cita: jre/lib/ext
JAR archives placed in your jre/lib/ext directory are added to the classpath of all applications run with that virtual machine. While this seems convenient, it is also a long-term mistake akin to adding directories to the CLASSPATH environment variable. Sooner or later (probably sooner), you'll load the wrong version of a class from a place you aren't even thinking about and waste hours debugging.
This problem is especially serious when deploying server-side applications. Be very careful that the server you're deploying to doesn't have any extra JARs in its jre/lib/ext directory. Problems caused by the wrong version of a JAR archive in the classpath can be extremely hard to debug if you don't recognize the symptoms or know just what to look for. To avoid these problems, some frameworks have even gone so far as to write their own class loaders that bypass Java code's usual class loading mechanisms.
O sea, mala idea. Es mejor aprender como poner el classpath. De igual forma, no es muy viable que les digas a los que quieren usar tu applet que se copien unos archivos en un directorio del disco duro para poder usarlo.
Busca el parametro "archive" del tag APPLET:
http://mindprod.com/jgloss/applet.html