JMSL as a Java Extension

Java Music Specification Language, release 1.03
JMSL as a Java Extension

It is tempting to drag jmsl.jar and jscore.jar into ~/Library/Java/Extensions under OSX or (jre-home)/lib/ext in Windows. The advantage is that you do not have to specify the location of these jars in your classpath, since the JVM loads all classes from here first. It also saves downloading these jars when loading an applet into a web browser.

Disadvantages include:

The version stored in your local extensions will be loaded before a newer version of jmsl served from the codebase of an applet.

Security issues. An applet that evokes extension classes does not have full control over these classes. For example, you might get a security exception when a Thread is interrupted. If jmsl.jar is loaded from the codebase of the applet, no such security issues come up.

Class loader errors. You may get a "Class Not Found Exception" when JMSL tries to instantiate a class in your codebase. For example, SynthNoteAllPortsInstrument may break trying to load a SynthNote deployed to your website, because the extensions classloader (which loads SynthNoteAllPortsInstrument) is different from the Applet's classloader (which loads the SynthNote).

If you must use jmsl.jar and jscore.jar as Java Extensions, know that some JMSL applets will break, notably those that use the Event Scheduler, where Thread.interrupt() is called. You can create a .java.policy file to give applets certain rights, such as modifying threads (see JMSL_FAQ.html), or you can sign your applets and ask for permission to do security sensitive operations.
You can learn more about Java, Applet security, and Java Extensions at Java Tutorial and Applet Security FAQ, and Java Extensions

BACK

Nick Didkovsky, http://www.punosmusic.com, http://www.doctornerve.org
didkovn@mail.rockefeller.edu

Phil Burk, http://www.softsynth.com
Use online form to contact Phil at www.softsynth.com