> On Jan 22, 2017, at 6:00 PM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > Hi, > > comments below. > > Niclas Hedhman wrote: >> On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" < >> michal.klec...@xpro.biz <mailto:michal.klec...@xpro.biz>> wrote: >>> The use case and the ultimate test to implement is simple - have a >> listener that publishes remote events to a JavaSpace acquired dynamically >> from a lookup service: >>> class SpacePublisher implements RemoteEventListener, Serializable { >>> private final JavaSpace space; >>> public void notify(RemoteEvent evt) { >>> space.write(createEntry(evt), ...); >>> } >>> } >>> >>> It is NOT possible to do currently. It requires non-hierarchical class >> loading. It is not easy to solve. It would open a whole lot of >> possibilities. >> >> I am probably too ignorant to see it; What exactly is "NOT possible" with >> the above use-case snippet? > With currently implemented PreferredClassProvider it is not possible to > deserialize such an object graph.
This can happen, but what’s necessary is that the codebase of the SpacePublisher needs to include all the possible RemoteEvent classes, or the javaspace’s classpath has to include them. Jini doesn’t, dynamically, create codebase references which might flow back to the VM which sent the object, to let that VM send the correct class definition. This has (and does still I believe) happen in other platforms. I first saw this in ObjectSpace Voyager which appeared on the scene prior to Jini being open sourced. The idea of there being a free flowing graph of class definitions can create some conflicts that various timelines might cause different results to occur because of different versions of the class coming from different places. Gregg
