A very cheap way to do what I want is to let the VM just throw some runtime
exception on any object that is from a stale class loader.
I think the java semantics is a red-herring, OSGi is a framework running on
Java, we can add our own semantics when you run as a bundle. The choice is
between two evils: or you have people using stale objects, which they were
notified about or the bad guys get an exception ... And any code can get an
exception at any time, that is part of the Java semantics.
It is all about putting the burden on the culprit and in this case the culprit
is the user of the stale object.
Kind regards.
Peter Kriens
On 20 feb 2011, at 09:34, [email protected] wrote:
>
> NJB> Given that there is no way to take an object away from someone who has a
>> reference to the object, the service contract should state the behavior of
>> the object outside of its defined life time.
>
> I remember a conversation with Peter a few years ago where Peter was
> wondering whether it would be possible to tell a Java runtime to forcibly
> clean up a class loader, which would imply nulling out all references to
> instances of classes which it had loaded. I think that at the time I said
> it was simply impossible; nowadays I would say it is technically possible
> but violates Java semantics in a way which is probably unacceptable (and
> the runtime overhead could be significant).
>
> A service could send a very strong signal to its users by only returning
> WeakReference's to the objects it creates instead of direct references to
> the object itself. Of course the service user can sabotage this by
> cacheing a strong reference to the object.
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
