Loosely-separated
“Sister” Namespaces in Java
Yoshiki Sato (Tokyo Tech., Japan
Currently, Mitsubishi Research Institute, Inc., Japan)
Shigeru Chiba (Tokyo Tech., Japan)
July 25-29, 2005
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
1
About This Talk…
The strict separation of Java namespaces
Scenario : inter-J2EE component communication
Ordinary 4 agonizing techniques
Ironically called
the version
barrier
I will introduce
Sister namespace: A more sisterly namespace than ordinary
standoffish one
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
2
The namespace design in Java is useful
Each class loader creates a unique namespace
This design well fits with a component system
Each loader loads a component into its own namespace
A component-based application can be developed and then
deployed per component
Dynamically and individually
updated without restarting
by recreating a new loader
deploy
(install)
Naming conflicts between
components can be avoided
due to the separated namespace
namespace
Applets, Servlets, EJBs, Plug-ins
components
loader
component framework
undeploy
Copyright (C) 2005 [email protected].
JVM, OS,…
19th ECOOP 2005, Glasgow, UK
Tomcat,
JBoss,
Eclipse
July 25-29, 2005
3
Problem of the current design:
the version barrier
The difficulty to communicate across namespaces
Different versions are different types!!

Of course, they have no subtype relation
An object of one version can not be cast to the other version
e.g.) online shopping
WAR1
EstimateServlet
c = session.getCache();
Cart cart = new Cart(); Cart
cart.put(item);
c.put(session, cart);
cart
WAR2
OrderServlet
c = session.getCache();
Object o = cache.get(session); Cart
Cart cart = (Cart) o;
throws ClassCastException
J2EE platform
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
No cache!?
July 25-29, 2005
4
Why did the Java designers select this
design ?
It guards JVMs against type-spoofing without runtime type checks
Type-spoofing may crash JVMs by accessing a non-existing member
(Sun JDK1.1 had the similar security problem reported by Saraswat)
If the JVM does type checks with resolving members on every
instance access, the version barrier is not needed
It is unacceptable for Java
Because the Java design prefers high-performance
loader1
Cart, WAR1
put()
remove(int)
clear()
Copyright (C) 2005 [email protected]
loader2
Cart c = (Cart) obj;
obj
Cart, WAR2
put()
remove(int)
invoke m[resolve(“put”, “()V”)];
c.put();
invoke m[resolve(“remove”, “(I)V”)];
c.remove(1);
X clear()
c.clear() Segmentation
invoke m[resolve(“clear”,
“()V”)];
c.clear();
fault
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
5
I.
Ordinary techniques for inter-component
communications
Packaging into the same archive
II. Delegating to the common parent
Call-by-Reference using
The classes are visible among
the Local Interface requires it
all child loaders
WAR1
WAR1&2
Cart
namespace
delegating
EAR
WAR2
Cart
Tightly-coupled components decrease
the availability and the maintainability
III. Delegating to the receiver
IV. Inter-process communication
The JBoss UCL is based on it
Call-by-Value using the Serialization
WAR1
Cart
delegating
WAR2
WAR1
Cart
Cart
Uniquely separated namespaces are combined
Copyright (C) 2005 [email protected]
Remote
call
WAR2
Cart
Performance overheads caused
by a remote call
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
6
Our motivation and Goal
The namespace design
in Java is not so bad
But the version barrier
is so bad…hmm
Our goal is relaxing the version barrier
between compatible versions of a class
Our challenges:
Reducing runtime type checks
for type-safe instance accesses
Avoiding tightly-coupled namespaces
Keeping lazy class loading
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
7
Sister namespace
Sister namespaces can relax the version barrier
between sibling namespaces
explicitly specified against class loaders by the programmers
by using protected ClassLoader(ClassLoader parent, ClassLoader sister)
Version barriers between the version compatible
classes are automatically and silently relaxed
Incompatible classes can be also loaded into each own
namespace if they are harmless to the other namespace
sister1
parent
sister2 incompatible,
but loaded
compatible,
thus relaxed
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
We aren’t nagging,
loosely-separated
July 25-29, 2005
8
Sister namespace
A sister relation is established only among the namespaces that
have no parent-child relation
All classes in sister
namespaces satisfy bridge-safety
Our requirements are fulfilled
Runtime type checks are reduced
Lazy class loading are kept
Tightly-coupled namespaces are avoided
sister1
parent
sister2 incompatible,
but loaded
compatible,
thus relaxed
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
We aren’t nagging,
loosely-separated
July 25-29, 2005
9
Version compatibility
Version compatible changes
The differences that an instance can be securely accessed
through another version of that class


Any static members
(static methods, static fields,
constructors, initializers）
A body of instance members
(instance methods)
Cart,WAR1
Cart,WAR2
cart
cart
Derived from the study of Java binary compatibility
If the binary compatibility satisfied, a class can link
preexisting binaries without recompiling.
If the version compatibility satisfied, an instance rather
than a class can work with the binary of another version
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
10
Only few instructions do runtime checks
because of bridge-safety
The bridge-safety property is satisfied [Saraswat’97]
An instance from the sister namespace must be


upcast to their supertype loaded by their common parent loader
downcast to a variable of the corresponding class type
The version checker has only to work with the type checker

All instances cross the version barrier through checkcast
WAR2
WAR1
System class loader
Object
Cart
cache.put(cart)
Regular type-check algorithm
if LHS is a subtype of RHS
true
elseif LHS is not a subtype of RHS
false
end
Cart
(Cart)cache.get(…)
if LHS is a sister type of RHS &&
LHS is version compatible with RHS
Version check algorithm
The version checker implies no performance penalties
unless instances are passed across the version barrier
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
11
Sister loader constraints can delay
version checks
The version checker requires eager class loading
Untrusted instances may relay an incompatible instance


As a field, a method return, and a method argument value
All relayed classes must be eagerly loaded and then verified for
winning the trust of the relaying instance
The constraints for the non-loaded classes
The version checker recursively verifies version compatibility
While recording the constraints for the non-loaded classes
Loaded Non-loaded
class Cart {
cart
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
Copyright (C) 2005 [email protected]
class Cart {
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
19th ECOOP 2005, Glasgow, UK
Sister namespaces
July 25-29, 2005
12
Sister loader constraints can delay
version checks
The version checker verifies
<Cart, SN1> can trust <Cart, SN2>

<Cart, SN1> is version compatible with <Cart, SN2>



<ProductMap, SN1> can trust <ProductMap, SN2>
<ProductList, SN1> can trust <ProductList, SN2>
<Product, SN1> can trust <Product, SN2>
Casting <Cart, SN1> to <Cart, SN2> succeeds
If both loaded, the sister loaders verify


<ProductMap, SN1> can trust <ProductMap, SN2>
<ProductList, SN1> can trust <ProductList, SN2>
Sister loader
constraints
New
constraints
Loaded Non-loaded
class Cart {
cart
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
Copyright (C) 2005 [email protected]
class Cart {
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
19th ECOOP 2005, Glasgow, UK
Sister namespaces
July 25-29, 2005
13
Schema compatible loading
The instances may have schema inconsistencies
The layout of TIBs(type information block) may not be identical
The TIBs of both versions are updated to be compliant
with each other when both versions are loaded
The corresponding members share the same index into the TIB
All members can be correctly accessed without any checks
Cart, WAR1
put()
remove(int)
clear()
tib[0]
tib[1]
tib[2]
Cart, WAR2
remove(int)
clear()
put()
hold fields
put
put and function pointers remove
corresponding method
body
compatible
remove to aremove
clear
clear
clear
put
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
put
remove
clear
July 25-29, 2005
14
Implementation on the IBM Jikes RVM
The extensions to the JRVM
Java API

GNU Classpath libraries
Sister loader
[Java.lang.ClassLoader]
protected ClassLoader(ClassLoader parent,
ClassLoader sister)
1. Examines version compatibility
2. Performs schema compatible loading
3. Verifying sister loader constraints
Version checker
1. Version checks
2. Verifying sister loader constraints
Class and object(TIB) representations


An identifier of a sister relation
Sister’s superclasses and interfaces
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
TIB
Class
type
type ID
sister
super
interfaces static member
sister’s super
sister’s interface
vmethod
Object
field
TIB
status
July 25-29, 2005
15
Related work
Most of the previous researches regarded the version barrier
as a temporal boundary between old and new components
HotSwap Sun JDK1.4 JPDA (JDK1.5 java.lang.instrument)
Dynamic Java Classes [Malabarba00ECOOP]
Dyamic Classes [Hjalmtysson98USENIX]
Dynamic software
updates and evolution
The spatial version barrier among multiple components, where
an older version remains after a new version is loaded
Reclassifying object [Drossopoulou01ECOOP]
Wide classes [Serrano99ECOOP]
Explicit type
Type-based hotswap [Duggan01ICFP]
changing semantics
Dynamic typing language (CLOS, Self, Smalltalk)
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
16
Concluding remarks
The design and implementation of loosely-separated
“sister” namespaces in Java
Melts the Java’s strong types only at the joint of components
We are now formalizing and proving the type soundness
It could adopt to the dynamic AOP system, which is for not DI +
AOP but DI x AOP
Our experimental results show
The baseline overhead was negligible

-5~5% running the SpecJVM98 on the modified JRVM
The version check overheads are not so severe


1st : 1,000~4,000 %
2nd : 160% using the results of 1st
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
17
The End
Thank you for your attentions !!
If any questions,
please ask me “clearly” and “slowly”
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
18
Compatibility with JIT compilers
Canceling JIT compilations
Optimizing JITs transform a virtual method to a static one
Such a devirtualized and maybe inlined method call does not
correctly refer to a method declared in a sister version
Cart, WAR1
put()
remove(int)
clear()
Cart c = (Cart) obj;
obj
Inlined_put();
Inlined_remove(1);
Inlined_clear();
Cart, WAR2
put()
remove(int)
clear()
Devirtualized and maybe inlined
Recent JITs cancel devirtualization efficiently by rewriting
or replacing an inlined code when a new sister loaded
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
19
Eager notifications of version
incompatibility
The incompatibility errors are eagerly thrown
Version checking
Or, class loading
The linker is no use for the sister classes that have
already linked with a call site
Unlike the binary compatibility checks in Java
Like the loader constraint scheme
Sister namespaces
class Cart { Loaded
cart
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
Copyright (C) 2005 [email protected]
class Cart { Version Incompatible
ProductMap map = null;
ProductList getProducts() {…}
void putProduct(Product product) {…}
}
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
20
memo
Q) Why did you use “sister” as the name?
A) Using the notion of “sister”, we can imagine a more soft and friendly sibling relation than brother.
Q) How do you deal with the co-variant and contra-variant problems?
A) There is no sub-typing relation between sister versions of a class type, that is, one is neither the other’s
supertype nor subtype. So the co-variant and contra-variant problems are not need to be regarded.
Q) What is the difference from the loader constraint scheme?
A) The loader constraint scheme rather strenghthens the version barrier, while our work relax the version
barrier
Q) OODB?
A) In the object database community, several schema evolution techniques such as schema or class
versioning have been studied. Using the object databases is a workable alternative.
Q) Why not the performance overheads are severe?
A) We think the overheads are not so severe compared to the inter-component communication. Just for a
reference, we measured the costs of the inter-component communication. We transported 400KB files
over network and it spent 3 million times larger than checkcast
Q) Why not a sister relation is allowed between a parent-child? The bridge-safety property is not satisfied
for all the classes. What could be wrong?
A) Since all classes included in the parent are visible for the child class loaders, the instances can be
passed without the checkcast operation, by using just an assignment operation.
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
21
pronunciation
Separately
Violate
Inconsistencies
Incompatibility
Examine
Identification
Determine
Alternative
Simultaneously
Spatial
Cause
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
22
About This Talk…
The strict separation of Java namespaces
Scenario : inter-J2EE component communication
Our goal
Ironically called
Relaxing the version barrier
the version
 while still allowing type-safe instance accesses barrier

with negligible performance penalties in regular execution
Melting the strong types

only at the joint of namespaces (components)
I will introduce
Sister namespace: A more sisterly namespace than ordinary
standoffish one
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
23
Ordinary techniques for inter-component
communications
I.
II.
Packaging into the same archive
Using the Local Interface introduced
by EJB 2.0 requires it
It enables using Call-by-Reference
on the local communication
Delegating to the common parent
WAR1&2
WAR1
The classes loaded by a loader are
available for that all child loaders
The WAR components can share
delegating
the same version loaded for the EAR
Cart
EAR
WAR2
Cart
namespace
Tightly-coupled components decrease the availability and the
maintainability
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
24
Ordinary techniques for inter-component
communications
III. Delegating to the receiver (JBoss UCL )
A collection of UCLs acts as a single class loader, which places
into a single namespace all the classes to be loaded
All classes are loaded into the shared
WAR1
repository and managed by it
WAR2
Uniquely separated namespaces are combined
Cart
delegating
Cart
IV. Inter-process communication (Call-by-Value)
It uses the Serialization API to exchange objects between
different components through a byte stream
Typical J2EE platforms adopt this approach as the last resort
Performance overheads caused
by a remote call
Copyright (C) 2005 [email protected]
WAR1
Cart
19th ECOOP 2005, Glasgow, UK
Remote
call
WAR2
Cart
July 25-29, 2005
25
Sister namespace can relax
the version barrier
The design of sister namespaces
Namespaces except the parent and child can be sisters
The version barrier between the version compatible classes
are silently and automatically relaxed in the sister namespace
sister1
All classes in the sister
namespace satisfy bridge-safety
parent
sister2
incompatible,
but loadable
compatible, so exchangeable
Runtime type checks for type-safe instance
accesses are reduced
Each sister needn’t mind the other’s loading
of incompatible but harmless classes
We aren’t nagging,
loosely-separated
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
26
Sister namespace
Version barriers between the version compatible classes
in sister namespaces are automatically relaxed
Explicitly specified against class loaders
Established among namespaces that have no parent-child relation
sister1
All classes in sister
namespaces satisfy bridge-safety
sister2
incompatible,
parent but loaded
compatible,
thus relaxed
Our requirements are fulfilled
Runtime type checks are reduced
Lazy class loading are kept
Incompatible classes are loaded into each namespace
if harmless to the other namespace
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
We aren’t nagging,
loosely-separated
July 25-29, 2005
27
Sister namespace
Sister namespaces can relax the version barrier
between the sibling namespaces pairing in advance
Only secure instances can be assigned to the variable of the
sister version of that class type
The programmers explicitly specified sister relations:
protected ClassLoader(ClassLoader parent, ClassLoader sister)
1. Version compatibility
WARLoader(EAR)
WARLoader(EAR, WAR1)
EARLoader()
Cart,WAR2
Cart,WAR1
cart
2. Version checker
Copyright (C) 2005 [email protected].
3. Sister loader constraints
4. Schema compatible loading
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
28
Version checker
The version checker, an extension to the built-in type checker,
is what relaxes the version barrier
Checks the sister relation and the version compatibility
Only several instructions require dynamic type checking
(instanceof, checkcast, invokeinterface, athrow)
Other instructions are statically typed (invokevirtual, getfield, etc.)
if LHS is a subtype of RHS
true
elseif LHS is not a subtype of RHS
false
Regular
end
type check algorithm
if LHS is a sister type of RHS &&
LHS is version compatible with RHS
true
else
Version check
false
algorithm
end
This implies no performance penalties
as long as the version checks are not performed
Copyright (C) 2005 [email protected].
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
29
Is the version checker enough for
detecting an incompatible class?
YES, because of the design of sister namespaces
No parent-child relationship between any sister namespace
The common parent namespace always exists among sisters
(The top-level namespace is created by the bootstrap loader)
Bridge-safety property is satisfied [saraswat’97]
An instance from the sister namespace must be


upcast to their supertype loaded by their common parent loader
downcast to a variable of the corresponding class type
WAR1
cache.put(cart);
EAR
boot
strap
Cache
Cart
Copyright (C) 2005 [email protected]
WAR2
checkcast
(version check)
(Cart)cache.get(…);
Cart
19th ECOOP 2005, Glasgow, UK
July 25-29, 2005
30
Concluding remarks
Sister namespace
The design and implementation of loosely-separated Java namespaces
Melts the strong types only at the joint of components
It could adopt to the dynamic AOP system, which is for not DI + AOP
but DI x AOP
Our experimental results show
The baseline overhead was negligible

-5~5% running the SpecJVM98 on the modified JRVM
Loading costs depend on the number of declared members

13~67% overheads for loading 72～1,548 classes
The version check overheads are not so severe


1st : 1,000~4,000 %
2nd : 160% using the results of 1st
Copyright (C) 2005 [email protected]
19th ECOOP 2005, Glasgow, UK
JDOM, Crimson,
jaxen, dom4j, SAXON,
XT, XercesJ1, 2, XalanJ
July 25-29, 2005
31