Applicet FrameWork: Known Issues

  • Sound in applications and JDK1.1.x
  • Version 1.1.x based Java VM's have no documented way to play sound from applications; luckily all 1.1.x implementations that we know off are based on the same grounds and have undocumented Sun classes that play sound for us. Java 2 added audio support for applications, so we do not use it there. All this is handled by the Applicet Framework completely transparent to your Applicet application.

  • Sound and Windows 98
  • Playing many AudioClips under Windows 98 will not free all resources, and ultimately bring Windows 98 to a halt (on my machine after some thousands of AudioClips). This is a Java VM problem (Bug ID 4072950), not an Applicet problem, and is solved in JDK13beta and JDK13 RC1. Note that Microsoft's integration of Internet Explorer with the operating system will not even free these resources when Internet Explorer is closed; Netscape, IBM and Sun Java VM's behave more polite in this matter.

  • HFile includes
  • Though, according to the Java Language Specification, there is no reason to do so, since JDK13 compilation includes a reference to the HFile class into classfiles that refer to it's constants. Hence some Java runtimes running Applicets require the HFile class to be in the classpath for syntax checking.

  • Netscape, jar's and uppercase filename extensions
  • Older Netscape versions have random problems when using uppercase extensions for files stored in jar's; consider using lowercase extensions only.

  • ClassNotFoundException in Applicet applet for classes that need not be packaged with applets
  • In Packaging your Applicet classes and resources we describe the files that need to be included in an applet .jar file. But even if you do not use a certain class when running as applet, based on a test of isApplication(), the webbrowser's Java VM might want to load the .class file just for type checking during a method's bytecode verification. You should be aware that different Java VM's (different browsers) have different bytecode verification strategies.

    Here is what Netscape says about this:

    If you have any code in your frequently used class that has an assignment of a value whose type is one of the less frequently used classes, it will cause that class to be pulled down in the course of verifying the more frequently used class (violating the desire to pull it in on demand, or when it actually gets used). Here's an example:

    Let OnDemand be a class not in the archive file, and let the variable d be declared to be of type OnDemand. If in a method of a class contained in the archive file you say:

    where the type of x is not OnDemand, then the class OnDemand will have to get downloaded when this class is verified in order to check whether assignment of d to x is legal. However, if you introduce a method in the above assignment, the verifier will trust that the return type of the method is correct, and consequently not have to download the class of the result type: Here, x is of type X, and toX is a method defined on class OnDemand as: You'll have to watch out for uses of instanceof too, and wrap them in a method in the same manner.

    Although this technique is tedious and leads to slightly larger class files, it may be well worth the effort to speed your applet's initial start up time. A good way to see exactly what classes are being loaded is to type '2' in the Java console (in Navigator 3.02 or greater, or in Communicator) to turn on applet debugging. You'll see log messages saying what classes are being loaded, and whether they're coming from the downloaded archive, or the network: