Java Limitations

The µ-law 8 kHz 8-bit mono sound format until recently formed the upper limit for the Java language (JDK 1.0.2 and JDK 1.1). It allowed for tones up to only half the sample rate: 4 kHz, and then we still had just two samples to crudely approximate one period of a sine wave.

soundscapes from The vOICe Sonification Applet

Therefore, you should not yet judge your ability or inability to hear certain visual objects or patterns in complicated soundscapes from experiments with the Java applet unless you are using JDK 1.2 or later! Through exploitation of leading edge software technology, The vOICe Java applet/application has now been upgraded for full binaural stereo scanning with Sun's JDK 1.2 or later, using 16-bit stereo and higher-than-8kHz sample rates in the new Java Sound engine!

Java applets running in a browser throw a ``Security Exception: socket.connect'' when trying to import files via URL-variables that point to files that are not on the server site. This means that you will experience problems using the image import and spectrogram generation facilities for your own images and sounds. You can import and sonify any of the images on this site, but not on any other sites, including yours. The same applies to the creation of spectrograms of your sound files. Of course the whole intent of the import facility was to let you process your own files, not just your selection of images and sounds on my site! The problem is essentially a most inconvenient result of the strict security checks by Java to forbid access to files at http: addresses that are already public anyway, while one would wish to avoid using a proxy server at my provider (many providers do not support this) or a clumsy code-signing procedure that is unsuitable for applets that are regularly updated. The problem for Java and the browser is to simultaneously ensure that an applet at the client-side cannot ``look around'' within an intranet behind a firewall and secretly communicate its findings via specially concocted URL addresses that could encode some confidential information, even while it pretends to do only a read operation!

It would be best if Java allowed access to any full URL entered directly via a user dialog (instead of via applet-generated string or URL variables), because it is safe in the sense that it requires the client to explicitly and knowingly enter a URL - thus preventing that an applet sees more than the user is aware of. Similarly, Java applets should be allowed full file read/write access to a browser subdirectory with the path derived from the site URL where the applet resides. Thus, no applet will be able to read anything stored on your local system from other sites, and only some maximum file size constraints need to be imposed on the storage at a directory like file:C:/.../mybrowser/www_gotitfromthissite_com/ . Because your native applications are allowed to work within any directory, they will if necessary communicate with the applet via this link, feed data to it, and decide what to do with the applet's output, based on what you tell them to do, rather than the applet controlling your entire machine. It's like running a program remotely across a network, only now the remote program happens to live on your local system, but with the same kinds of protections that forbid a remote program to control your system: you simulate a remote system in a directory derived from the origin of the applet.

For the time being, using the appletviewer from Sun, the Java security restrictions can be made less stringent:

First, save (via File | Save As... menu options) the following two files to disk:

    
    

and check that the downloaded javoice.htm file still contains the Javascript source code (or else remove any BASE=... and CODEBASE=... assignments from javoice.htm).

Next, apply a long-file-name unzip to the javoice.zip to obtain the .class files. Start Sun's appletviewer on-line on the local (downloaded) javoice.htm, with the appletviewer security checks disabled via its menu options (network and class access set to unrestricted in Appletviewer Properties). Now you should be able to access any http: image or sound address. When off-line, you can still access any local file: address. However, don't apply this procedure to untrusted applets: malicious applets could do very nasty things if you lower the security barriers that much. Furthermore, it doesn't offer you the additional functionality offered by The vOICe application (and note that Java applications should also be downloaded only from trusted sites).

In case you still get security exceptions from appletviewer specifically when trying to read .wav or .au files for making spectrograms, the likely reason is that you need to adapt the access control list, acl, to allow the applet to read from specific directories (plus subdirectories) or files. On UNIX systems, you should add a line like acl.read=/mypath/ or acl.read=/mypath/mysound.wav (multiple file entries separated by colons, ':') to your ~/.hotjava/properties file, while on PC's it should be something like acl.read=C:\mypath\ or acl.read=C:\mypath\mysound.wav in your C:\java\.hotjava\properties file (multiple file entries separated by semicolons, ';'). Note that the ".hotjava" file path here applies to appletviewer, although HotJava is also the name of a browser from Sun.

If you are now able to load a local file but still unable to load from a http: image or sound address while on-line, then you are probably behind a firewall for which additional security restrictions have been implemented, and you may need to contact your system administrator for advice about your local proxy server. Often, however, one of just two possibilities apply: your site has a so-called HTTP proxy, or it uses a SOCKS host. For the HTTP proxy case, you should have lines of the following form

proxySet=true
proxyHost=myproxyhost
proxyPort=1080

in your ~/.hotjava/properties or .hotjava\properties file, while in the SOCKS host case, it should typically be

proxySet=false
socksProxyHost=mysocksproxyhost
socksProxyPort=1080

If Netscape 3.0 runs on your site, you can check the settings in the menu Network Preferences|Proxies to find out which actual settings you should apply in the assignments to make it all work. Also note that these settings form the appletviewer equivalent of The vOICe application settings

     java  -DProxyHost=myproxyhost  -DProxyPort=1080  The_vOICe

and

     java  -DsocksProxyHost=mysocksproxyhost  -DsocksProxyPort=1080  The_vOICe

respectively, as discussed in the The vOICe Sonification Applet page.

As you can see, the security issues can be rather daunting even to experienced computer users, and it is hoped that better and more consistent ways of dealing with security will be implemented in a future Java JDK.