HOWTO: Compile applications with implicit import dependencies
Article ID: 000004 PDF Version: 000004.pdf The information in this article applies to:
This article applies to Excelsior JET versions 4.1 and earlier only. Since version 4.5, all classes located in application CLASSPATH are always available to the Excelsior JET JVM either in natively compiled form or in bytecode form. It was not true for earlier JET versions and this article was written to suggest workarounds to problems that might occur because of that. In the presence of implicit class import (Class.forName(), etc.) the JET compiler may be unable to automatically determine all classes required by the application and include them into compilation set. This document describes the problem and shows how to diagnose and repair it. Download sample code for this article. Consider the following code snippet: Object foo(String className)
{
Class c = Class.forName(className);
return c.newInstance();
}
The compiler has no way to determine which class will be created in this function. When a conventional JVM executes code like the above it can find the required class at run-time (e.g. using CLASSPATH). However, a JET-compiled executable cannot do that unless distributed with class files that may be loaded at run time and the JIT compiler. There are two ways to resolve this problem:
Example file ImplicitImp.jar contains two classes - hello and hello2. The main class imports hello2 implicitly and creates its instance: Class c = Class.forName("hello2");
Object o = c.newInstance();
so there is no direct references to hello2 class. If JET Control Panel is used to compile this application, it shows the user that there are some classes in classpath that are not directly imported by the application and lets the user add such classes to the compilation set or leave them alone. As shown on Figure 1. hello2 class is not included., classes not included into compilation set have yellow tags. Figure 1. hello2 class is not included.
At this point the user can force required classes into compilation set (using right mouse button or doubleclicking on class or package names). Figure 2. All classes are included into compilation set. illustrates how it looks if all classes are included. Figure 2. All classes are included into compilation set.
Now compilation may be performed and all the classes will be included into the resulting executable. When the user is sure that ommited classes are not required for application or s/he is going to use JIT compiler to load them at run-time s/he can leave them alone. In such case JET Control Panel will issue a warning about these classes before compilation (Figure 3. Unused class reminder. ). At this point the user can return back and enlarge compilation set or skip the warning. Figure 3. Unused class reminder.
Figures 4. Java Communications API - not all classes are imported explicitly. , 5. Java Communications API - all classes are forced into compilation set. below illustrate a “real world” situation: SimpleWrite class imports comm.jar with Java Communications API [REFERENCES]. Not all classes are directly imported (Figure 4. Java Communications API - not all classes are imported explicitly. ) and the user should force them into compilation set manually (Figure 5. Java Communications API - all classes are forced into compilation set. ), using right mouse button or doubleclicking on class or package names. Figure 4. Java Communications API - not all classes are imported explicitly.
Figure 5. Java Communications API - all classes are forced into compilation set.
Copyright © 2003-2006 Excelsior LLC. All rights reserved.
|
|
Home | Company | Products | Services | Resources | Blog | Contact | Request a Call Site: Search | Forum | Credits © 1999-2006 Excelsior LLC. All Rights Reserved. |