JEE Class Loading Internals.pdf

JSE and JEE Class Loading
Internals
By –Mohit Kumar

13/11/2005 Class Loading-Mohit Kumar
Contents
Introduction
Class Loading Basics
Common Class loading Issues
Custom Class Loaders
Diagnosing and resolving class loading problems
JEE Class Loading
Comparison of application server class loading architecture

Introduction
What is a Class Loading ?
„ Mechanism to load a Class inside the JVM
„ Allow classes to be dynamically loaded as opposed to
static loading(done through imports)
„ Every Class loader must be a subclass of
java.lang.Classloader

Introduction
The phases of class loading
„ The loading of a class can essentially be broken down
into three phases: loading, linking, and initializing.
„ Most, if not all, problems relating to class loading can
be tracked down to a problem occurring in one of these
phases. Therefore, a thorough understanding of each
phase helps in the diagnosing of class loading
problems.

Introduction-Phases

Introduction-Phases
The loading phase consists of locating the required class
file (by searching though the respective classpaths) and
loading in the bytecode. Within the JVM, the loading
process gives a very basic memory structure to the class
object. Methods, fields, and other referenced classes are
not dealt with at this stage.

Introduction-Phases
Linking
„ Bytecode verification. The class loader does a number
of checks on the bytecodes of the class to ensure that it
is well formed and well behaved.
„ Class preparation. This stage prepares the necessary
data structures that represent fields, methods, and
implemented interfaces that are defined within each
class.
„ Resolving. In this stage, the class loader loads all the
other classes referenced by a particular class. The
classes can be referenced in a number of ways:
Š Superclasses,Interfaces,Fields,Method
signatures,Local variables used in methods.

Introduction-Phases
During the initializing phase, any static initializers
contained within a class are executed. At the end of this
phase, static fields are initialized to their default values.

Two Key Elements of class loading
„ Isolation
Š Isolation ensures that classes used by one
application are not seen by another.
Š Class must be loaded by a class loader instance only
once(otherwise JVM throws a linkage error) but
may be loaded n number of times by n class
loaders(this happens because of the Delegation
model).
Š The identity of a type is resolved by the fully
qualified class name and the class loader that loaded
the type.

„ Delegation
Š Delegation refers to the technique of delegating the
request for class loading by a class loader to parent
class loader recursively before trying to load the
class itself.

Class Loading Basics-Isolation

Class Loading Basics-
Delegation

Why is isolation and delegation important ?
„ In Java's sandbox, the class loader architecture is the first line of
defense. It is the class loader, after all, that brings code into the
Java virtual machine--code that could be hostile or buggy. The
class loader architecture contributes to Java's sandbox in three
ways:
1. it prevents malicious code from interfering with benevolent
code,
2. it guards the borders of the trusted class libraries, and
3. it places code into categories (called protection domains) that
will determine which actions the code will be allowed to take.

B o o t S t r a p C la s s L o a d e r
$ J A V A H O M E /jre /lib /rt.ja r
E x te n tio n C la s s L o a d e r
S y s te m C la s s L o a d e r
N e t w o r k C la s s L o a d e r
( U s e r D e f in e d )
A p p lic a t io n C la s s L o a d e r
( U s e r D e f in e d )
$ C L A S S P A T H
$ J A V A H O M E /jre /lib /e x t/* .ja r
C la s s ,O b je c t,
S tr in g
U s e r D e f in e d C la s s L o a d e r
A ll e x t c la s s e s .
J C E im p l c la s s e s e tc
C la s s p a th c la s s e s .
M ,N
A ,B ,C
C h ild -- - P a r e n t re la tio n s h ip
J a v a .la n g .C la s s L o a d e r
E x te n d s
C la s s e s n o t v is ib le
C la s s e s a r e v is ib le
T h e v is ib ilit y r u le s a r e n o t im p lic it ly im p o s e d b y
t h e J V M . T h e y a r e m a n if e s ta t io n s o f th e p a r e n t
c h ild r e la tio n s h ip t h a t c la s s lo a d e r s ’ s h a r e .

S tep 1 . C h eck if I(cu rren t cla ss lo a d er)
h a s lo a d ed th e cla ss. if y es retu rn it.
S tep 2 . B efo re I try to lo a d it m y self,
recu rsiv ely ca ll p a ren ts “ lo a d C la ss()”
m eth o d . T h is en su res sa fety o f co re
cla sses.
S tep 3 . fin a lly if a ll else fa iled let m e
lo a d th e cla ss m y self b y ca llin g
“ fin d C la ss()” . ” fin d C la ss()” h a s th e
resp o n sib ility o f fin d in g th e cla ss fro m
th e d esig n a ted p la ce a n d co n v ert th e
ra w d a ta o f a cla ss to a cla ss b y ca llin g
“ d efin eC la ss()” w h ich is a fin a l
m eth o d .
N o te1 : A s it is clea r th a t v ery m u ch lik e th e v isib ility ru les th e d eleg a tio n ru le is a
d efa u lt ru le w h ich m a y b e o v erw ritten if req u ired (ra rely ).
N o te2 : W h ile w ritin g a cu sto m lo a d er th e “ lo a d C la ss()” m a y n o t b e o v erw ritten if
d efa u lt d eleg a tio n b eh a v io r is req u ired . T h e “ fin d C la ss()” m eth o d n eed s to b e
o v erw ritten to im p lem en t th e lo g ic o f fin d in g th e cla ss. P rio r to ja v a to “ lo a d C la ss()”
w a s a n a b stra ct m eth o d .
T h e “ lo a d C la ss()” co n tra ct

It is p o ssib le to w rite u sefu l l o a d C l a s s ( ) m eth o d s th at d o n o t fo llo w th e stan d ard
d elegatio n m o d el; th ere are p ro b lem s th at can p o ten tially arise as a resu ltIt is p o ssib le to
w rite u sefu l l o a d C l a s s ( ) m eth o d s th at d o n o t fo llo w th e stan d ard d elegatio n m o d el;
th ere are p ro b lem s th at can p o ten tially arise as a resu lt
T h e “ lo a d C la ss()” co n tra ct
E x cep tio n in th rea d " m a in "
ja v a .la n g .N o C la ssD efF o u n d E rro r:
ja v a /la n g /O b ject
T h e m eth o d n o w d eleg a tes to its p a ren t
cla ss lo a d er b efo re a ttem p tin g to fin d
th e cla ss itself. E x cep tio n in th rea d
" m a in " ja v a .la n g .L in k a g eE rro r:
d u p lica te cla ss d efin itio n : A
T h is m eth o d w ill n o w w o rk fin e;
h o w ev er, it n o w fo llo w s th e sta n d a rd
cla ss lo a d in g d eleg a tio n (ca ch e, p a ren t,
d isk ). O f co u rse, if th e sta n d a rd
d eleg a tio n m o d el is req u ired , th en
th ere is n o n eed to o v errid e lo a d C la ss()
in th e first p la ce.
It is p o ssib le to w rite u sefu l lo a d C la ss() m eth o d s th a t d o n o t fo llo w th e sta n d a rd
d eleg a tio n m o d el; th ere a re p ro b lem s th a t ca n p o ten tia lly a rise a s a resu lt

It is possible to write useful loadClass() methods that do not follow the standard
delegation model; there are problems that can potentially arise as a resultIt is possible to
write useful loadClass() methods that do not follow the standard delegation model;
there are problems that can potentially arise as a result
Common Class Loading issues.
ClassLoader
X
Y
Z
Class Loaders maintain the references of the
loaded classes in a private vector. Classes natively
maintain the reference of their (defining )class
loader . From a garbage collection perspective it
means a class cannot get collected unless the class
loader gets collected and vice versa.
Note :
Initiating Class Loader-Class loader that initially received the request to load the
class.
Defining Class Loader-Class Loader that actually loaded the class. It basically
means the class loader that called the “defineClass()” method

It is possible to write useful loadClass() m ethods that do not follow the standard
delegation m odel; there are problem s that can potentially arise as a resultIt is possible to
write useful loadClass() m ethods that do not follow the standard delegation m odel;
there are problem s that can potentially arise as a result
Class”s Identity
Sam e Class Loaded By tw o different class loaders
are not com patible and m ay result in a host of
problem s from ClassCastException to Linkage
Error D epending on how the classes w ere loaded.
N ote :
C lasses belonging to the sam e package are allow ed package private access but only
if loaded by sam e class loader to protect the package boundaries. H ow ever if not
loaded by the sam e class loader throw s IllegalAccessException.

Peer Class Loading
W hile the simplest way to avoid class loader constraint
violations is to only have one copy of a class in the
system, it is sometimes necessary to have multiple
versions.
One possible way to avoid constraint violations, is to
use a peer class loading model. Peer class loading does
not follow the traditional hierarchical delegation
structure for class loaders. Instead, it has a set of class
loaders that are unrelated except that they have the
same parent (usually the system class loader). These
class loaders can delegate not only to their parent, but
also to their peers.
This kind of class loader structure allows discrete class spaces to exist within one JVM; thus, it's very
useful for running componentized products. A good example of this class loading structure is an OSGi
framework, such as the one Eclipse, JBOSS4.0.2 is built on.
Advantages include:
• Classes do not need to be replicated across deployment units in order to have access to them.
• Many future possibilities including novel partitioning of the repositories into domains,
dependency and conflict detection, etc.
Disadvantages:
• Since the delegation model has been overridden prevention of class duplication is
programmer’s responsibility. Can lead to class cast exceptions and linkage errors if not done
properly.
• Some times we need different versions of classes. Eg running two different versions of
application.

It is p o s s ib le to w rite u s e fu l l o a d C l a s s ( ) m e th o d s th a t d o n o t fo llo w th e s ta n d a rd
d e le g a tio n m o d e l; th e re a re p ro b le m s th a t c a n p o te n tia lly a ris e a s a re s u ltIt is p o s s ib le to
w rite u s e fu l l o a d C l a s s ( ) m e th o d s th a t d o n o t fo llo w th e s ta n d a rd d e le g a tio n m o d e l;
th e re a re p ro b le m s th a t c a n p o te n tia lly a ris e a s a re s u lt
P e e r C la s s L o a d in g

Diagnosing and resolving class loading
problems
Common Problems
„ UnsatisfiedLinkError
Š The class loader plays an important role in linking a
native call to its appropriate native definition. An
UnsatisfiedLinkError occurs during the resolving
stage of the linking phase when a program tries to
load an absent or misplaced native library.
„ ClassCircularityError (rare and only happens when
compilation is done in more than one physical location)
Š The JVM specification says a ClassCircularityError
is thrown if a class or interface could not be loaded
because it would be its own superclass or
superinterface.

problems
„ ClassFormatError
Š This exception is thrown during the verification
stage of the linking phase of class loading. The
binary data can be malformed if the bytecodes have
been changed -- if the major or minor number has
been changed, for instance. This could occur if the
bytecodes had been deliberately hacked, for
example, or if an error had occurred when
transferring the class file over a network.
Š The only way to fix this problem is to obtain a
corrected copy of the bytecodes, possibly by
recompiling

problems
ExceptionInInitializer
Note : According to the JVM specification, an ExceptionInInitializer is thrown:
If an initializer completes abruptly by throwing some exception E, and if the class
of E is not Error or one of its subclasses, then a new instance of the class
ExceptionInInitializerError, with E as the argument, is created and used in place
of E.
If the Java Virtual M achine attempts to create a new instance of the class
ExceptionInInitializerError but is unable to do so because an Out-Of-M emory-
Error occurs, then the OutOfM emoryError object is thrown instead.

problems
„ ClassNotFoundException
Š ClassNotFoundException is the most common type
of class loading exception. It occurs during the
loading phase. The Java specification describes
ClassNotFoundException as follows:
Š Thrown when an application tries to load in a class
through its string name using:
„ The forName() method in class Class.
„ The findSystemClass method() in class
ClassLoader.
„ The loadClass() method in class ClassLoader.
Š but no definition for the class with the
specified name could be found.

problems
„ NoClassDefFoundError
Š Thrown if the Java virtual machine or a ClassLoader
instance tries to load in the definition of a class (as
part of a normal method call or as part of creating a
new instance using the new expression) and no
definition of the class could be found.
The searched-for class definition existed when the
currently executing class was compiled, but the
definition can no longer be found.

problems
ClassCastException and LinkageError
„ Loading constraints validate type expectations in the
context of class loader scopes to ensure that a class X is
consistently the same class(at runtime this means
fully qualified name+defining class loader) when
multiple class loaders are involved. This is important
because Java allows for user defined class loaders.
Linkage errors are essentially an extension of the class
cast exception that is enforced by the VM when classes
are loaded and used.

JEE Class Loading
Java Enterprise Edition Class Loading
„ Built upon the class loading foundation provided by
Java 2 Class Loading
„ While the hierarchy of Java 2 Class Loading is very
well defined, vendors have considerable flexibility on
how they can structure their JEE class loading
architecture
„ JEE specifications do not provide significant guidance
regarding class loading

JEE Class Loading
Deploying JEE Modules and Class Loading
„ Can I live with a temporary outage while I reboot the
application server to allow new classes to be loaded?
Š Classes or JAR files that are loaded by the System
Class Loader or the top level directory of the
application server cannot be changed without
restarting the JVM
Š Classes loaded at the top level directory of the
application server are visible to ALL applications
„ Better use of memory since applications are not
required to bundle the JAR file

JEE Class Loading
Packaging Guidelines
„ Leverage Enterprise Archives (EARs)
Š Self contained
Š Should include all dependent JARs
„ Increased application size
„ Minimal dependency on the core environment
„ DO NOT include JDBC drivers
Š Package common JARs needed by WARs with the
EJB JARs
„ Leverage WEB-INF/lib preference in stand alone
WARs
Š Allows WARs to be self-contained
Š WARs contained in EARs should defer to EJB JARs

Comparison of application server class
loading architecture

Common Characteristics of JEE Class Loading
Architectures
„ JEE Applications are Isolated from each other Each
application has it's own root class loader
„ The parent of each EAR class loader is usually the
System class loader
„ Web applications contained within a single application
are isolated from each other
„ Manifest class path used to specify dependencies
between JARs

Shared Chain class loader: loads most of the
core Application Server
MBean class loader: loads the Mbean
Implementation classes
Common class loader: loads classes from
the “domain-dir/lib/classes/” directory,
followed by “domain-dir/lib directory.
Sun Java System Application Server

If you deploy a war and an ejb-jar
separately they are considered as different
application.
Applications are normally packaged as
Ears.
BEA Webloagic 9.1

JBOSS Class Loading
Jboss Allows both traditional and peer class loading
„ By default it is peer.
„ Traditional class loading can be enabled by META-
INF/jboss-app.xml descriptor.
“<jboss-app>
<loader-repository>
some.dot.com:loader=webtest.ear
</loader-repository>
</jboss-app> ”

JEE Class Loading Internals.pdf

More Related Content

Similar to JEE Class Loading Internals.pdf

Recently uploaded

JEE Class Loading Internals.pdf