[armedbear-devel] Isolating ABCL in OSGi

[Mark Evenson]

On 5/19/10 9:42 AM, Alessio Stalla wrote:

[…]

> I'm afraid that disposing the Interpreter and starting a new one is
> not the same as rebooting ABCL. Most of the state is reachable from
> static fields; the list of packages is static, for example.
> That said, System.exit() should really be removed in favor of an
> Interpreter.quit() or something like that, which will call
> System.exit() in the default case, but may be overridden in order to
> do other things in certain environments.
> If you want to have multiple instances of ABCL running in parallel, or
> even simply to restart it without restarting the JVM, you have to run
> each instance in a dedicated classloader. If, as I have understood,
> you intend to use ABCL as a service provider accessed through some
> kind of "remoting" layer (even when on the same machine as the other
> modules), then it's perfectly fine to have ABCL locked in its own
> private world, since all communication with it will be through message
> passing - *if* the type of those messages is a class which is shared
> among all the ABCL instances, i.e. loaded by a shared parent
> classloader, i.e. not LispObject. I'm talking of the actual Class of
> the message here - a byte[] containing a serialized LispObject would
> be fine.

How does one (de)serialize a LispObject to byte[]?  We don't implement 
the java.io.Serializable contract so as far as I can tell, we need a 
fair amount of implementation work here.  Or have I missed something simple?

--

"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."