Originally posted by Mark Savory:
Contrary to Jim's statement, the JVM does load all classes in the classpath at start-up. To verify this, run java with the '-verbose' parameter. This is why you must use something like ClassLoader to load classes that were not in the classpath at start-up. Adding classes to the classpath directories after the JVM is started does not make them available to your program. You must programatically load them.
Originally posted by Mark Savory:
I believe that the class java.net.URLClassLoader is what you can use. In spite of its name, it apparently can also be used to load classes from the local file system.
2.16.1 Virtual Machine Start-up
A Java Virtual Machine starts execution by invoking the method main of some specified class, passing it a single argument, which is an array of strings. This causes
the specified class to be loaded (�2.16.2), linked (�2.16.3) to other types that it uses, and initialized (�2.16.4). The method main must be declared public,
static, and void.
The manner in which the initial class is specified to the Java Virtual Machine is beyond the scope of this specification, but it is typical, in host environments that use
command lines, for the fully qualified name of the class to be specified as a command-line argument and for subsequent command-line arguments to be used as strings
to be provided as the argument to the method main. For example, in Sun's JDK implementation on UNIX, the command line
java Terminator Hasta la vista Baby!
will start a Java Virtual Machine by invoking the method main of class Terminator (a class in an unnamed package), passing it an array containing the four strings
"Hasta", "la", "vista", and "Baby!".
We now outline the steps the virtual machine may take to execute Terminator, as an example of the loading, linking, and initialization processes that are described
further in later sections.
The initial attempt to execute the method main of class Terminator discovers that the class Terminator is not loaded-that is, the virtual machine does not currently
contain a binary representation for this class. The virtual machine then uses a ClassLoader (�2.16.2) to attempt to find such a binary representation. If this process
fails, an error is thrown. This loading process is described further in (�2.16.2).
After Terminator is loaded, it must be initialized before main can be invoked, and a type (class or interface) must always be linked before it is initialized. Linking
involves verification, preparation, and (optionally) resolution. Linking is described further in �2.16.3.
Verification checks that the loaded representation of Terminator is well formed, with a proper symbol table. Verification also checks that the code that implements
Terminator obeys the semantic requirements of the Java Virtual Machine. If a problem is detected during verification, an error is thrown. Verification is described
further in �2.16.3.
Preparation involves allocation of static storage and any data structures that are used internally by the virtual machine, such as method tables. If a problem is detected
during preparation, an error is thrown. Preparation is described further in �2.16.3.
Resolution is the process of checking symbolic references from Terminator to other classes and interfaces, by loading the other classes and interfaces that are
mentioned and checking that the references are correct.
The resolution step is optional at the time of initial linkage. An implementation may resolve a symbolic reference from a class or interface that is being linked very
early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors
from further loading and linking steps.) This implementation choice represents one extreme and is similar to the kind of static linkage that has been done for many
years in simple implementations of the C language.
An implementation may instead choose to resolve a symbolic reference only when it is actively used; consistent use of this strategy for all symbolic references would
represent the "laziest" form of resolution. In this case, if Terminator had several symbolic references to another class, the references might be resolved one at a
time-perhaps not at all, if these references were never used during execution of the program.
The only requirement on when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is
taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. In the "static" example implementation choice
described earlier, loading and linking errors could occur before the program is executed if they involved a class or interface mentioned in the class Terminator or
any of the further, recursively referenced classes and interfaces. In a system that implemented the "laziest" resolution, these errors would be thrown only when a
symbolic reference is actively used.
The resolution process is described further in �2.16.3.
In our running example, the virtual machine is still trying to execute the method main of class Terminator. This is an attempted active use (�2.16.4) of the class,
which is permitted only if the class has been initialized.
Initialization consists of execution of any class variable initializers and static initializers of the class Terminator, in textual order. But before Terminator can be
initialized, its direct superclass must be initialized, as well as the direct superclass of its direct superclass, and so on, recursively. In the simplest case, Terminator
has Object as its implicit direct superclass; if class Object has not yet been initialized, then it must be initialized before Terminator is initialized.
If class Terminator has another class Super as its superclass, then Super must be initialized before Terminator. This requires loading, verifying, and preparing
Super, if this has not already been done, and, depending on the implementation, may also involve resolving the symbolic references from Super and so on,
Initialization may thus cause loading, linking, and initialization errors, including such errors involving other types.
The initialization process is described further in �2.16.4.
Finally, after completion of the initialization for class Terminator (during which other consequential loading, linking, and initializing may have occurred), the method
main of Terminator is invoked.
Originally posted by Mark Savory:
Contrary to Jim's statement, the JVM does load all classes in the classpath at start-up. To verify this, run java with the '-verbose' parameter.
Originally posted by Roseanne Zhang:
What you did will work until there is something called static You will be totally surprised by the behaviour of it. I'm not not kidding at all!!!
You can use them as long as you're aware of the problems. However, you are better off if you don't.
Be very very careful for this practice. Please read Ted Newman's excellent article on this topic:
When is a static not a static?
Join our SCJD Study Group when certified
[This message has been edited by Roseanne Zhang (edited March 12, 2001).][/B]
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton