JSR-121: Good Fences Make Good Neighbors
(Sears Tower Elevator Pitch for Techies)
Pete Soper
June 11, 2003
It takes a lot of time to grok all the value of JSR-121. So I'm going to take
a few minutes to touch on the one value that is most important to me.
Java's two fundamental abstractions:
Java Thread: light, fast comms, limited security
Java VM: heavy, slow comms, strong security
Java began with two major abstractions offering security levels: the Java
thread and the Java virtual machine. Java threads offered light weight and
fast communication between its instances but weak protection. The virtual
machine afforded stronger security, typically through hardware memory
protection, but slow communication and usually more weight.
Java class loader: medium weight, medium comms, medium security
As the use of Java expanded greatly designers were forced to provide
mechanisms for more security than threads but lighter weight than virtual
machines. Use of class loaders became the solution of choice for this
sweet spot and class loader tricks became more and more sophisticated in
attempts to create mappings of threads and virtual machines into secure but
agile containers.
Java class loaders: medium weight, medium comms, medium security
hard to get right!
hard to keep right!
The problem was that class loaders were not designed to stretch far enough.
Class loaders posing as relatively light weight but highly secure app
containers are now viewed by many middleware developers as the poster
child of frustrating attempts to create a third essential Java abstraction
out of the two original two.
If I had a time machine and could go back to help survey licensees to gather
requirements for Tiger in 2001, I'd have asked this question:
How would you like relief for the
Java Middleware Blues?
The middleware blues are what I think of as composite dissatisfaction
with class loader tricks and the constant tension between security,
communication and weight (memory, cpu, etc). The tricks have gone so
far that it's hard to maintain the view that Java is a strongly typed language:
it can be almost impossibly hard to disambiguate object references in some
cases!
Isolates: relief for the class loader blues
So I would have sought confirmation of the strong desire for a real solution in
the form of a third abstraction: Java processes. It's now pretty clear that it
will be easier to add this abstraction than to go on forever, stretching the
class loader charter and chasing security and performance characteristics that
become ever more expensive.
Isolate: the third fundamental Java abstraction
JSR-121 is about fitting a process abstraction called "Isolates" into Java.
Isolates provide a third building block that is designed in Java terms,
leveraging the type safety guarantees of the language into isolation that does
not mandate either the heavy weight or slow communication of a VM while
offering strong and obvious security guarantees. Isolates offer an alternative
to the next generation of class loading tricks and allow system designers to
achieve satisfaction with middleware and special applications where real
isolation is critical but resources are limited. Isolates also enable
infrastructure upgrades over the long haul in an orderly and well thought out
manner. Isolates are also a catalyst for turning Java into a single ABI.
That's all I have time for tonight. For more information visit the
"latest info" link near the top on the JSR-121 web page at jcp.org.
Now here's Doug with a very brief overview of the APIs.
(additional notes for back pocket)
Exciting real and considered implementations of isolates that can deliver
good performance along along with security are getting more and more attention.
The JSR-121 EG has worked very hard to avoid dictating implementation
and instead has stayed open to widely varying implementation styles while
also pointing to ones offering great promise like Sun's multitasking VM
research vehicle. But as the saying goes, implementations come and go, but
interfaces are forever. Not that VM multitasking isn't so cool you have to
wear shades to talk about it!
A simple reality is that JSR-121 is also far ahead of Java design patterns that
will take advantage of its features. Imagine adding Thread to Java late in the
game and being asked by somebody: "what good is that?"
Even if you knew a person's hot buttons you might be hard pressed to explain
the specific value in an elevator unless it was in the Sears tower. If a
person was obsessed by straight line execution speed and unfamiliar with the
very idea of parallelism being delivered by a programming language he'd be
skeptical in the short term and only gradually brought around to understanding
just how much performance might come from taking advantage of threading.
Likewise the and opportunities for something as basic as a process abstraction
defined in Java terms like isolate simply takes time to appreciate and put to
use.
Another set of problems stem from investments in the status quo. There are many
that would argue that class loaders are all we need to isolate app components,
thank you very much! They should talk to the guys I talk to who deal with
serious middleware systems that must stay secure in the presence of untrusted
byte codes.
Others only need to hear "process abstraction" to feel that the battle to
prevent Java from becoming an operating environment has been rejoined. But
it's hard to look at a J2EE server doing serious work without "operating
environment" coming to mind. It seems like this issue has been overtaken by
the reality of wide ranging requirements. Java IS AN OE ALREADY, but one badly
needing the missing third piece.
But at the end of the day folks want implementation, not architecture, because
it's concrete and what rewards them for using the APIs. So no matter how much
we try to communicate the architecture it's implementation that turns into the
sound bites, implementation that excites. But while we look for and enjoy the
wide range of implementations that the APIs can encompass let's try to keep
our eye on the original goals of the architecture.
-PostScript added 6/17/2003
A little sleep and a comment from Glen Skinner of Sun woke me to the fact
that this talk is a bit confused and a minor rewrite is in order. It would be
better to say that while JSR-121 provides a process abstraction to Java
isolates themselves are the "address space" component. Only in combination
with the machine and threads do we get a "Java process". Some isolate impls may
be capable of expressing an isolate separate from the other components, making
the address space nature of them more obvious. -Pete