That's the right question.
* Set up Apache River for Pervasive Computing, by laying foundations
that:
o Make it possible to lookup the correct latest compatible
bytecode for marshalled object instances using the publish,
find, bind pattern.
o Enable sharing of objects between different applications
based on common domain object libraries, enable those
libraries to evolve unconstrained by backward compatiblity
without loosing the object data when the bytecode drops
backward compatibility due to refactoring.
o Make node bytecode upgrades seamless for applications.
For some background see the following Papers:
The paper on Classloading issues by Michael Warres on River-316
Or at:
http://research.sun.com/techrep/2006/smli_tr-2006-149.pdf
The Paper on Project Neuromancer, highlighting problems with Jini and Java.
http://research.sun.com/techrep/2007/smli_tr-2007-162.pdf
My latest heading is inspired by Tim Blackman's research on classloader
trees. No paper was released for this, however we have some of the code
Tim used in com.sun.util.tools.classdepend
Regards,
Peter.
Michael McGrady wrote:
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.
