river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River & OSGi
Date Fri, 20 Nov 2009 00:09:19 GMT
That's the right question.

    * Set up Apache River for Pervasive Computing, by laying foundations
          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:


The Paper on Project Neuromancer, highlighting problems with Jini and Java.

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



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.

View raw message