Basically, there are two types of portability problems. One is that Java is still evolving fairly rapidly and its support and implementation on different platforms are not uniform. For example, at the time we wrote this document, the latest release of Java is Java 1.1.2, but most platforms that support Java still only support Java 1.0.2. The migration to later releases is in different paces on different platforms. The second is that regardless of platforms, the hardware resources on different machines are not the same. For example, the CPU speed, the screen resolution, color depth, memory size, peripherals, etc. are all machine dependent and may not all meet the requirements of a Java program. So the performance of a Java program is highly dependent on your computer's configuration.
Usually you can not run programs writen in Java in a way you run most of other programs. You actually start a so called Java Virtual Machine (JVM) and let the JVM run the Java programs. In other words, Java programs are interpreted instead being executed as other native binary code programs. In general, interpreted programs run much slower. So Java programs are relatively slow (this may not matter much in most cases).
Because Java programs are interpreted by the JVM, and, therefore, are under the control of the JVM, Java programs are generally considered securer. In theory, as long as the JVM does not leave any security holes, it will be safe to run any Java programs under that JVM. The codes of a Java program can be considered as instructions to the JVM. It is entirely upto the JVM whether or not to carry out a specific instruction based on its security modes. For example, the instruction in a Java program to remove a disk file may not be carried out by the JVM if the program does not pass the security checks of the JVM's security manager.
Because an applet downloaded through the WWW may come from anywhere, it is considered "untrusted" by the JVM, or your browser, and therefore, many restrictions related to security are imposed by default (assuming your browser has implemented the security manager properly).
Please note that "trusted" and "untrusted" here are pure technical words. They have something to do with the origin, not the function, of the applet. "Untrusted" basically means that there are some uncertainties about the origin of the applet. It is not to say that an "untrusted" applet will surely cause damages. The major concern of the JVM security manager is to be sure about where the applet comes from, not what the applet will do. There is nothing to prevent an "trusted" applet from actually causing damages, for examples, due to bugs in the program. The browser trusts that the user knows what he or she is doing. But it simply can not be sure what the user gets is really what he or she wants to get. The restrictions come from the fact that the browser can not be sure what downloaded from the WWW is really what is supposed to be downloaded. You may say to your browser, for example, that anything from www.webgenetics.com is OK, but your browser, while not questioning your judgement, simply can not be sure what is supposed to be from www.webgenetics.com is really from www.webgenetics.com. Before the origin of an applet is verified, it is considered "untrusted" and restrictions will be imposed.
Systems have been developed to authenticate applets. But they have not been proven 100 percent secure and the procedures are fairly complecated. So for the time being, we prefer our applets being run as "untrusted".
Restrictions imposed on "untrusted" applets are the following:
Please note that applets does not have to be loaded through WWW. You can download applets directly from your local disks. Usually there are no above restrictions on applets downloaded directly from your local disk. Here we are not talking about the cache system which is simply storage area for recently downloaded objects (text, images, applets, etc) over WWW so repeated or later accesses will not have to download the same objects again and again over the Internet. Applets downloaded from the cache area for the purpose of speed up are still considered being downloaded over the WWW and imposed the above restrictions because they originate from the WWW. (But there is nothing to prevent you, the browser user, to have your browser download those applets directly from the cache area and circumvent most or all the restrictions. Certainly not a wise thing to do though.)
An applet, like other computer programs, may contain bugs. But the bugs usually should only affect the fuction or performance of the applet itself. Not the browser. For example, a mouse click may get no response, a scroll bar may not scroll at all, the widnow can not be resized, etc. But a normal operation, like close a menu window, should not cause the browser abruptly quit. If your browser bombs out abruptly during the execution of an applet, more likely your browser itself contains bugs in addition to possible bugs in the applet.
Currently, there are sevearl releases of Java, 1.0.2, 1.1.1, 1.1.2 (there will be surely more releases later). There are some compatibility problems among the different releases. Most browsers only have Java 1.0 capability. Some have some (not all) features of 1.1. Therefore, our applets released right now are Java 1.0.2 compatible. If your browser implements a higher release and has problems with our applets, please let us know. We certainly can make upgraded versions available if necessary.
While applets give you a great deal of control over the programs through the GUI, they also demand a great deal of your computer resources. The burden on the computer resources is shifted onto your local computer. As mentioned earlier, Java solves the portability problem only to certain extent, our applets may perform well in most cases, but may not run well or even not run at all in some cases. Please be aware that, currently, Java capable browsers on Mac usually don't run applets properly. The tasks our applets are designed to deal with are usually time comsuming on the user's part. Before you begin running our applets seriously for real work, you should run series tests on the functionalities of not only our applets, but also your browser and your computer's resources. So you can have a fairly good idea whether or not your system environment suits the applet you would like to run.
For info about Java, please visit java.sun.com.