What is the overall goal? What does success look like?
Mike
On Nov 19, 2009, at 12:36 PM, Peter Firmstone wrote:
I'm having a discussion about Classloader separation, modularity
(OSGi), and binary compatibility within the local JVM, sharing of
bytecode when it should be, eg shared domain objects, marshalled,
unmarshalled or otherwise. I'm trying to find a solution to this
problem of ensuring compatible packages are loaded within each jvm
on separate nodes participating in a djinn, I can see that static
analysis can help resolve dependencies and record Package API
signatures for fast runtime comparison before loading classes.
So yes the goal is binary compatibility, currently in Jini,
unmarshalled objects, if utilising downloaded code and not locally
preferred classes, will be loaded in separate Classloaders, so they
may not be visible to each other at runtime, yes they can
participate if they share a common supertype or a common interface,
however creating an interface for every domain object that should be
shared is a lot of work. Not only that, an interface, once created,
doesn't evolve in a friendly manner, your domain objects become
snared, not able to be refactored easily.
So yes, the Jini discovery mechanism allows evolvability of systems
by allowing new services to be made available, but they don't share
objects nicely with the older existing services (unless you have
locally installed preferred classes, which defeats the purpose of
discovery) and they don't help with local Classloader isolation
issues, nor will they assist with unmarshalling an object that has
been persisted for which the URL from which the bytecode originated
no longer exists.
But I'm wondering, I think you know the River codebase far better
than I do, you are far more qualified than I, so I think that you'd
be surprised if I uncovered something you didn't already know, so I
was hoping that you might rephrase that question again so I can
better answer it?
Regards,
Peter.
