FastPak for Java

FastPak for Java is an application loader for Java applications produced by Software and Computer Systems Company, LLC of Reston, Virginia. FastPak for Java uses a single Java virtual machine (JVM) to launch multiple applications, rather than using one JVM per application.
Significance A standard Java application is launched when a user starts, directly or indirectly, a JVM, which in turn reads the Java bytecodes comprising the application, and then executes them as instructions. Each time a user launches a Java application in this manner, a new JVM is started. If, for example, a user runs N applications on a system, the user will in turn have N corresponding JVMs running.
Each running instance of a JVM can essentially be seen as a sub-operating system executing within the hosting system. Each independently executing JVM is extremely resource intensive and redunandantly consumes system resources. As a result, as a user executes more and more Java applications, the load placed on the system becomes very high. This can often manifest itself as a significant and observable performance decrease on the end users system. Because of the heavy loading, many developers have shied away from adopting Java for anything other than server side web and enterprise level development efforts.
FastPak for Java allows users to run all applications under a single JVM, hence conserving a considerable amount of system resources. When FastPak starts, it instantiates a JVM which for all practical purposes is almost behaving like a daemon. As FastPak receives instructions to launch new applications, rather than starting a new JVM to be used with the application, FastPak creates a kernel level thread within the JVM context and the application is launched on that thread. Any applications launched within the FastPak environment will be launched in this manner and will effectively be isolated from one another. The only data shared by such applications will be the global settings that FastPak issues to the JVM at start up.
When FastPak is used as an application launcher, users will notice that the launch times are nearly instantaneous and that resource consumption and system loading is greatly reduced. This, however, does not come without a cost. FastPak requires that developers terminate threads and applications without using calls directly or indirectly to System.exit(), and all GUI based applications will end up timesliceing GUI processing on the same event dispatching thread (EDT).
Since the bug that required GUI based applications (Java bug ID 4030718) to terminate by shutting down the JVM itself has been fixed since Java 1.4, elimination of use of System.exit() calls will likely be seen as the correct way to terminate GUI applications in the near future. In the case of applications still using System.exit() calls to terminate the program and corresponding JVM, adapting to FastPak will require code modification. For most applications this is trivial, but applications making extensive use of exit handlers may require extensive work, and may be best left to execute outside a FastPak environment.
With respect to the EDT, developers need to be aware of the fact that if one of the applications simultaneously running under FastPak blocks the EDT, it can have the effect of suspending any other of the applications that likewise need access to that thread. Although blocking the EDT is considered bad programming practice, it is not uncommon to see it done by developers with novice, and perhaps even intermediate skill sets. The implication is that FastPak for Java may best be suited for use by developers and administrators with higher level skill sets.
Aside from these caveats, FastPak for Java represents a new and more efficient way of allowing users to execute Java applications. The implication of this is that FastPak, and FastPak like technologies that get developed in the near future may have the effect of opening Java development up to more generic and general purpose application development, rather than restricting it to web and enterprise level development efforts.
 
< Prev   Next >