Can you clarify your question for me?
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.
Peter Firmstone wrote:
I'll get back to you on the weekend, but just to clarify, I think the
best time to collect Package API signatures is at build time, with the
build environment as it was intended by the developer. Utilising the
freshly compiled class files and third party jar files, to create dist
jar files containing the Package API signature information. I've been
referring to Package API signatures as class metadata, it doesn't have
to be shoehorned into the manifest though.
Dennis Reedy wrote:
On Nov 18, 2009, at 1105PM, Mike McGrady wrote:
There are of course limits and they come very quick to what you can
do to modify a jar file.
Very true, this goes for manifest modifications as well. Since all
the 'proposed' analysis is done at build time jars can be modified
with either approach. I suppose to a certain extent, its convention
over configuration.
If the goal is binary compatibility, then does the existing type
based lookup and discovery mechanism that Jini provides allow
evolvability of systems? If not, where and why does it not?
Perhaps I missed this analysis on this thread, but can we break this
down first prior to jumping into implementation details?
Dennis
