There are three types of class in a JVM:
- The
z/OS JVM code, which provides the base services in the JVM. These classes
are system classes and standard extension classes, which are
known collectively as primordial classes. They have a special status
that allows the objects created from them to be associated with middleware
or the application, depending on the kind of class that invokes their construction.
- The
middleware, which provides services that access resources. This includes the
JCICS interfaces classes, JDBC, JNDI, and so on. These classes are known as middleware
classes. Middleware is trusted by the JVM to manage its own state between
one use of a JVM and the next, and it can therefore operate without restrictions,
and is trusted to make changes to the JVM environment, even if the JVM is
resettable. This enables optimizations through the caching of state (classes
and native libraries, for example) to be used by multiple applications. However,
middleware is responsible for resetting itself correctly at the end of a transaction
and, if necessary, for reinitializing at the beginning of a new transaction,
in order to isolate different applications from each other. Persistent
Reusable Java Virtual Machine User's Guide, SC34-6201
explains how middleware should be written.
- The
classes for the user application. These classes are known as application
classes.
- Application classes can be shareable, meaning that when they have been
loaded, they are kept across JVM reuses and resets, so that they can be used
by other transactions. If the JVM is reset, they are re-initialized.
- Alternatively, application classes can be nonshareable, if they are placed
on the standard class path. In a resettable JVM, nonshareable application
classes are discarded when the JVM is reset, and must be reloaded each time
they are required. In a continuous JVM, however, they are not discarded, and
are kept intact for subsequent reuses of the JVM.
- When a JVM is defined as resettable, if application classes perform actions
that change the JVM environment, these actions are noted and the JVM is destroyed
after the application has finished using it. In a continuous JVM, this restriction
does not apply, and application classes are permitted to make changes to the
JVM environment. (How JVMs are reused explains more
about resettable and continuous JVMs.)
The classes in a JVM, and the objects that they create, are placed in
different storage heaps in the JVM according to their expected lifetime. For
example, nonshareable application classes (on the standard class path) are
placed in the transient heap in a resettable JVM, because this heap is deleted
if the JVM is reset between uses.
Storage heaps in a JVM explains
how the classes and objects are arranged in storage heaps.
The JVM can identify the correct type for each class
because of the class path on which the class is included. The class
path determines how the class is loaded by the JVM, where it is stored, and
how it is treated. So, for example, any class that is included on the shareable
application class path is loaded by the shareable application class loader,
stored in the application-class system heap, kept across JVM reuses and resets,
and re-initialized if the JVM is reset. Persistent Reusable Java Virtual
Machine User's Guide, SC34-6201 explains more about the process
of loading classes.
The class paths for a JVM are defined by options in the JVM profile, and
in the JVM properties file that the JVM profile references. (How CICS creates JVMs explains
JVM profiles and JVM properties files.) Generally speaking, when you are preparing
Java applications that will run in a JVM, you need to ensure that all the
middleware and application classes required by the application are included
on the class paths defined by the JVM profile and JVM properties file that
are requested by the application. You also need to ensure that any native
C dynamic link library (DLL) files that are required for the application (which
have the extension .so in z/OS UNIX) are included on the library path in the
JVM profile. You do not need to include the system classes and standard extension
classes (the primordial classes) on a class path, because they are already
included on the boot class path in the JVM.
Note that although for convenience we refer to “including a class on a
class path”, the name of the class itself (including the name of the package,
if the program has been built as a package) is not actually specified in the
JVM profile or JVM properties file. The options in the JVM profile or JVM
properties file specify the path to the class—that is, the full path
of the HFS directory in which a class loader will be able to find the class
or the package containing the class. Where classes or packages have been placed
in JAR files (with the extension .jar), the name of the JAR file is included
on the class path as if it were the name of a directory. Adding application classes to the class paths for a JVM explains
more about this.
In the JVM provided by the
IBM® Software Developer Kit for z/OS®, Java™ 2 Technology Edition, Version 1.4.2,
which features the persistent reusable JVM technology, the four class paths
on which classes or native libraries can be included are as follows:
- The library
path is for native C dynamic link library (DLL) files that are used by
the JVM (which have the extension .so in z/OS UNIX), including those required
to run the JVM and additional native libraries loaded by trusted code. This
might include the DLL files needed to use the DB2 JDBC drivers, or any native
code associated with a class that you are using to redirect JVM output (named
on the USEROUTPUTCLASS option in the JVM profile).
The library path is
defined by the LIBPATH option in the JVM profile. Adding application classes to the class paths for a JVM tells
you how to include items on the library path. Note that if the JVM is to use
the shared class cache (see The shared class cache), you
will need to include the DLL files in the JVM profile for the master JVM that
initializes the shared class cache, rather than in the JVM profile for the
JVM where the application will run. The master and worker JVMs use the same
library path to ensure that they are using the same versions of these files.
However, note that the files are not loaded into the shared class cache. Unless
they are shared through another z/OS facility (such as the shared library
region), a copy is loaded into each worker JVM.
- The trusted middleware
class path is for middleware classes, that is, classes that are trusted
by the JVM to manage their own state across a JVM-reset. Trusted middleware
classes are permitted to change the JVM environment even if the JVM is resettable,
so for this reason you should not normally place your own application classes
on the trusted middleware class path. However, you might need to add classes
for middleware supplied by IBM or by another vendor, which are not included
in the standard JVM setup for CICS. For example, to use the DB2®-supplied JDBC
drivers with Java programs and enterprise beans, you need to add a DB2-supplied
zip file to the trusted middleware class path.
In CICS, the trusted middleware
class path is built automatically from the paths that you specify using the
CICS_DIRECTORY, TMPREFIX, and TMSUFFIX options in the JVM profile. “Options
in JVM profiles” in the CICS® System Definition Guide has more details
about these options. There is a corresponding system property, ibm.jvm.trusted.middleware.class.path,
in the JVM properties file, but you cannot use this system property for CICS. Adding application classes to the class paths for a JVM tells you how to include classes on the
trusted middleware class path. Note that if the JVM is to use the shared class
cache (see The shared class cache), you will need to include
the middleware classes in the JVM profile for the master JVM that initializes
the shared class cache, rather than in the JVM profile for the JVM where the
application will run.
- The shareable
application class path is for shareable application classes, that is,
application classes that you want to be cached, either in the JVM or in the
shared class cache. Defining the JVM as a resettable JVM subjects these classes
to restrictions which mean that they cannot affect or pass state to subsequent
transactions that use the JVM. When you add a class to this class path:
- If the JVM uses the shared class cache (see The shared class cache),
the classes are obtained from the shared class cache, rather than being loaded
by each individual JVM.
- If the JVM does not use the shared class cache but is resettable, the
classes are cached in the JVM, and are reinitialized when the JVM is reset.
- If the JVM does not use the shared class cache and is a continuous JVM,
the classes are cached in the JVM, and are kept across reuses, but are not
reinitialized.
Adding application classes to this class path, rather than to the standard
class path, produces the best performance, and it should be your normal choice
for loading application classes in a production environment. The shareable
application class path is defined by a system property, ibm.jvm.shareable.application.class.path,
in the JVM properties file.Adding application classes to the class paths for a JVM tells
you how to include classes on the shareable application class path. Note that
if the JVM is to use the shared class cache, you will need to include the
shareable application classes in the JVM properties file for the master JVM
that initializes the shared class cache, rather than in the JVM properties
file for the JVM where the application will run.
- The standard
class path is for nonshareable application classes, that is, application
classes that you do not want to be shared by other JVMs or across JVM resets.
Like shareable application classes, defining the JVM as a resettable JVM
subjects these classes to restrictions which mean that they cannot affect
or pass state to subsequent transactions that use the JVM. When you add a
class to this class path:
- If the JVM uses the shared class cache (see The shared class cache),
the standard class path is the only class path that is taken from the JVM
profile for the JVM itself, rather than from the JVM profile for the master
JVM that initialises the shared class cache. The classes are loaded by the
individual JVM, and are not stored in the shared class cache.
- If the JVM is resettable, classes on this class path are discarded when
the JVM is reset, and reloaded from HFS files each time the JVM is reused.
- If the JVM is a continuous JVM, nonshareable application classes are kept
intact from one JVM reuse to the next.
You should not normally place application classes on the standard
class path without a good reason for doing so, as it causes a degradation
in performance in a resettable JVM, and for worker JVMs (both resettable and
continuous) it uses more storage than having a single copy of the classes
in the master JVM. Some possible reasons for choosing this class path, instead
of the shareable application class path, are:
- In a non-production environment, you might use this class path during
application development if your JVMs are resettable, because it means you
do not have to phase out the JVM pool in order to update class definitions.
(If your JVMs are continuous, you still need to phase out the JVM pool.)
- If a particular class is used infrequently, you might use this class path
if you prefer to incur the performance cost of reloading the class each time
it is required, rather than the storage cost of keeping the class in the JVM
or in the shared class cache.
The standard class path is defined by the CLASSPATH option in
the JVM profile. There is a corresponding system property, java.class.path,
in the JVM properties file, but you cannot use this system property for CICS. Adding application classes to the class paths for a JVM tells you how to include classes on the
standard class path.
Enterprise beans are a special
case. You do not need to add the deployed JAR files (DJARs) for your enterprise
beans to the class path. CICS manages the loading of the classes included
in these files by means of the DJAR definitions. However, if your enterprise
beans use any classes, such as classes for utilities, that are not included
in the deployed JAR file, you do need to include these classes on the
shareable application class path that will be used by the JVM for the request
processor program. Adding application classes to the class paths for a JVM tells you how
to do this.