What I think Jini designers did not realize is that class loading can be
treated exactly as any other capability provided by a (possibly remote)
service.
Once you realize that - it is possible to provide a kind of a "universal
container infrastructure" where different class loading implementations
may co-exist in a single JVM.
What's more - these class loading implementations may be dynamic
themselves - ie. it is a service that provides the client with a way to
load its own (proxy) classes.
In other words: "there not enough Jini in Jini itself".
We have _all_ the required pieces in place:
- dynamic code loading and execution (ClassLoaders),
- security model and implementation that allows restricting rights of
the downloaded code,
- and a serialization/deserialization which allows sending arbitrary
data (and yes - code too) over the wire.
It is just the matter of glueing the pieces together.
Thanks,
Michal
Gregg Wonderly wrote:
<snip>
I am not an OSGi user. I am not trying to be an OSGi opponent. What I am
trying to say is that I consider all the commentary in those articles about
TCCL not working to be just inexperience and argument to try and justify a
different position or interpretation of what the real problem is.
The real problem is that there is not one “module” concept in Java (another one
is almost here in JDK 9/Jigsaw). No one is working together on this, and OSGi
is solving problems in a small part of the world of software. It works well
for embedded, static systems. I think OSGi misses the mark on dynamic systems
because of the piecemeal loading and resolving of classes. I am not sure that
OSGi developers really understand everything that Jini can do because of the
choices made (and not made) in the design. The people who put Jini together
had a great deal of years of experience piecing together systems which needed
to work well with a faster degree of variability and adaptation to the
environment then what most people seem to experience in their classes and work
environments which are locked down by extremely controlled distribution
strategies which end up slowing development in an attempt to control everything
that doesn’t actually cause quality to suffer.
Gregg
