Java Sound Resources: FAQ: Applets and JWS

Applets using Java Sound require a Java Virtual Machine (VM) that has support for Java Sound. Java Sound was new in Java 2, version 1.3, so you can't use version 1.0, 1.1 or 1.2 VMs to run Java Sound Applets. Versions 4.X of Netscape and 4.X and 5.X of Internet Explorer have a 1.1 VM. So Java Sound Applets can't be run on them directely.

The way to go for these older browsers is to use the Java Plug-in 1.3 or higher. It provides a 1.3 VM as a plug-in. Note that you have to modify your .html files to utilize the Java Plug-in

Some newer browsers (Netscape 6.X, konqueror, Opera?) support using VMs installed in the operating system as the browser's VM that is used for applets. So for these browsers you just have to install a 1.3 VM in your system and set up your browser to use it. Unlike for the above-mentioned Java Plug-in, in this case the traditional APPLET tag is used in .html files.

Still another possibility is to use the Java Media Framework (JMF). Its "performance pack" versions include a version of Java Sound that can run on 1.1 VMs. However, I have no experience with this. (Matthias)

It is possible, BUT: Recording in an applet is considered a serious security threat. Imagine a hidden applet on a website captures everything spoken in your room and transmit it to somebody you don't know, perhaps a competitor. You definitely wouldn't want this. Therefore, recording in applets is restricted. To be able to record sound, an applet has to be signed, so that users can be sure of the identity of the person or organisation they are trusting. (Matthias)

This is possible, if every user of the applet manually changes the security policy file of his/her local JRE installation. In practice, this is only possible if the number of users is small and they have at least some technical understanding, or their JRE installations can be tweaked automatically (for instance, in a company intranet). For applets deployed to unknown users on the internet, this is hardly the case. (Matthias)

For a short description, see the JavaOne session slides (page 34) of the Answering Machine. For a more detailed description, see Signing Code and Granting It Permissions in the Java Tutorial. (Matthias)

To use a certificate that is recognized by Java installations out there in the internet, you need to get a certificate from a certification authority that have their root certificates shipped and installed with the JDK/JRE. You can list the installed root certificates with the following command: keytool -list -keystore /usr/local/j2sdk1.4.2/jre/lib/security/cacerts (adapt the path to your installation, press ENTER when asked for a password)

So for now, you can use certificates from the following companies:

(Matthias)

This is a bug in the JRE (or maybe a feature, since it is related to security management). See the slides at Java Sound Resources: Applications: Answering Machine, page 36/37, for a workaround. There is a small hope that this will be reenabled in the future, once the Service Provider management has been reworked. (Matthias)

The problem is that the currently available encoders use native libraries. These native libraries can't be loaded over the network from the server to the client machine. And even if the library is installed locally on the client, it is difficult to manage permissions for the execution. It is recommended to use Java Web Start instead of applets for such applications. (Matthias)

First of all, JDK 1.1 generally only provides μ-law, 8000Hz mono playback. It does not provide .wav file playback directly. And for playback of audio data of the application, there are only the "unofficial" sun.audio.* classes. So you'd need to write your own classes that read in the .wav files, convert the sound data to μ-law and then use the sun.audio.* classes to play them. For code that parses .wav files and does μ-law conversion look at Tritonus' source code: WaveAudioFileReader and TConversionTool. Tritonus classes are under the LGPL licence.

Regarding sun.audio.* classes: it is discouraged to use them. I heard that they don't work anymore as expected in JDK 1.3. My applets using them work well from JDK 1.0 to JDK 1.1 and in all browsers that I could put my hand on. (Florian)

There are programs called obfuscators that modify programs in a way that make it hard or impossible for decompilers to reconstruct useful source code. At least they make the decompiled source code harder to understand. A common technique of obfuscators is to replace the real method names with abbreviations. Typically, the un-obfuscated code will contain method names like doSomethingUseful() that tell something about the purpose of the method and the structure of the program. Obfuscators replace these method names by something like a() that does not expose such information. Somebody investing enough time and money will still be able to find out what the code is doing. However, someone just fishing for a bit of code will give up pretty quick.

See also Learn how to download applets and decompile Java class files (Matthias)

It is possible to set the minimum and maximum heap size as attributes to the <j2se> tag in the .jnlp file. See JNLP File Syntax (Matthias)