Treffer: A JavaGeeks.com White Paper Using the BootClasspath Tweaking the Java Runtime API

Title:
A JavaGeeks.com White Paper Using the BootClasspath Tweaking the Java Runtime API
Authors:
Contributors:
The Pennsylvania State University CiteSeerX Archives
Collection:
CiteSeerX
Document Type:
Fachzeitschrift text
File Description:
application/pdf
Language:
English
Rights:
Metadata may be used without restrictions as long as the oai identifier remains attached to it.
Accession Number:
edsbas.75460B02
Database:
BASE

Weitere Informationen

Many Java programmers don't realize it, but the Java Runtime Environment [] is an amazingly configurable environment-so much about the Java execution environment can be controlled via options either on the command-line or through the JNI Invocation interface. One such option is the ability to define the location of the Java "bootstrap " classes-java.lang.Object, java.lang.Exception, and so forth-to come from someplace other than the ubiquitous "rt.jar " file in the "jre/lib " directory. In fact, we can use this non-standard JVM option to subvert the Java environment in many powerful ways, giving Java programmers a tremendous amount of power over their environment. But with power comes complexity, and this is no exception: it's powerful, but only if you're willing to accept the risks that go along with it. Problem Discussion, Part I (Statics) Under many circumstances, what the Java environment does by default may not be exactly what you want. For example, by default, the Sun JDK VM starts with 1 MB of heap space allocated, and will continue to grow until it consumes a maximum of 64 MB. Or, as an alternate example, the VM will create a ClassLoader delegation chain as described in [sbpj] [classForName] [insideVM] , where classes to be loaded are first loaded from the Runtime API jar file (rt.jar), then the Extensions directory, then the