Let me put it another way:
I want to work toward a cooperative distributed computing platform using
Java & Jini / River, continuing from where Sun left, using lessons learned.
1. I'd like to set up a class loader framework building on
classworlds, to segregate incompatible class versions with the
same name, while allowing compatible implementations to
interoperate, based on Class loader visibility.
2. I'd like to utilise the ASM bytecode library to perform static
analysis on bytecode to identify Package & Class API to determine
compatibility.
3. I'd like to solve the lost code base problem using codebase
services combined with the suggested Class loading framework.
4. I'd like to use codebase servcies to provide codebase proxy's for
often disconnected clients.
5. I'd like to allow bytecode to evolve organically by taking
advantage of the flexibility of binary compatibility.
6. I'd like some metadata to identify at the minimum ,Package
Versions, I could generate checksums based on Package API, however
this wouldn't identify which version is the latest, only which
Package implementations can substitute another's API where those
packages share the same name. Or identify packages with the same
name that are incompatible and segregate these in separate
Classloaders.
7. If possible due to concerns about the performance impact of many
Classloaders, group some packages together when the author doesn't
intend those packages to evolve separately. Eg libraries.
8. I'd like to make it possible to transfer class version and package
version information with serialized object instances for
compatible re-instantiation with the latest evolution of
compatible classes. All suggestions are welcome.
Does anyone have any suggestions for suitable existing formats for
Containers with Version Metadata that might be utilised? If so what issues
are there to be aware of? What are the arguments for and Against?
Note, I'm aware of the existing Java Version Spec that applies to
packages.
I believe I made the mistake of suggesting a solution without properly
formulating or posing the problem, my apologies for any confusion this might
have caused, I should have raised a new thread / topic, In the original
thread, Gregg is looking at classloader dependency issues implementing a
plugin for Netbeans to make River more accessible to IDE developers, please
feel free to make suggestions, we need your help.
I made a suggestion earlier to utilise the OSGi bundle metadata
specification, these are ordinary jar files with package version, exports
and dependency metadata. They are otherwise ordinary plain old jar
archives, quite useable as a jar file containing java class files that can
be utilised without the OSGi framework, which is what I was suggesting. I
attempted to imply that the exported packages could have their API
identified and shared in a compatible manner with other packages, using
Class loader isolation perhaps this is not a suitable solution due to the
confusion that it would cause with developers expecting an OSGi
implementation, utilising OSGi service interfaces. If this format was to be
utilised, it might have to be renamed, to River Codebase Bundles (for
uploading to codebases) whilst sharing the same format to avoid confusion.
It might be a subset of the OSGi bundle format, such that OSGi bundles, like
those on the Spring Source Repository could be utilised. It might also be a
component in an eventual Container spec, if we can sort that out. Gregg has
asked for container suggestions more than once, I'd like to see that
conversation continued.
If this solution was adopted, the dependency version metadata (Import
Package) in the bundle would be noted, considered a minimum version as per
the OSGi spec, but a later version would be utilized if it were found API
compatible. However additional protection by static analysis would
guarantee that a later version that wasn't API compatible would not be
utilised. The reason I'm considering this compromise is that a bundle
author cannot know in advance that later import packages will be compatible,
hence Static Analysis can verify API compatibility. It is still possible
for identical named classes to be loaded in the same jvm, in another
classloader, this might occur if an earlier package version already exists
but doesn't satisfy the Import Package version criteria; it wont be used as
it is earlier than the minimum required version. The Classloader
responsible for the bundle would keep a copy of the metadata available
while it remains loaded, it would not utilise the OSGi interfaces to access
the metadata. I envision Immutable Mirror Objects that can be transferred
with marshalled instances and utilised for API compatibility checking. The
Mirror objects would be created by a codebase service and stored in memory
by the Classloader that download the class bytecode (River Bundles) being
Mirrored, the mirror objects would contain the metadata from the bundle as
well as the API, the mirror objects would be used by the classloader to
determine which packages to export as well as check for import package
compatibility, and by other Classloader's for compatibility. If no
compatible packages are found loaded then the codebase services would be
consulted, the import package mirror object would be submitted to the
codebase services to locate a compatible package or bundle.
In principle, if this is still objectionable, I'm happy to create an
implementation utilising another container or bundle format that satisfies
the requirements, provided that one is recommended. This list does have a
history of heated debate regarding OSGi and Jini, I'd like to avoid any such
unproductive arguments if possible.
Regards,
Peter.
Niclas Hedhman wrote:
On Mon, Oct 19, 2009 at 7:40 AM, Peter Firmstone <[email protected]>
wrote:
Thanks Nic for your comments, pls see reply below.
I think we have diverged and discussing different things.
Some time ago, it was said that the classloader of a class could be
retrieved by calling a static method. I have tried to point out that
this is fairly "impossible" in OSGi without collaboration with the
OSGi framework implementation, as multiple (even fully compatible, or
even exact same versions) instance of the same classes can be present
in different class spaces within the OSGi framework, and which package
got resolved to which bundle (and hence the classloader) is an
implementation detail in OSGi. There is no theory around that fact. I
am speaking of "locating a classloader of an existing class already
present", and not how to locate one externally to the JVM and OSGi
framework.
See the difference?
So if ClassA wants to load an implementation of InterfaceB, then that
implementation must be chosen from the class space that ClassA and
InterfaceB belongs to, and not only that it implements
InterfaceB+constraints.
Cheers
