[MUD-Dev] Re: DevMUD considerations and the Halloween article

[Jon Leonard]

On Tue, Nov 03, 1998 at 10:44:38PM -0700, Chris Gray wrote:
> [Marc Hernandez:]
> 
>  >	There are 2 versions of 'free' JVMs around (Kaffe and Japhar).
>  >Just looking at Japhar (http://www.japhar.org) it is LGPL'd, which is
>  >quite attractive.
> 
> Nod. Kaffe is what I have here on Linux. One of my concerns with using
> the JVM is that it might be considerable work to change the machine in
> any significant way. E.g. the strong dependency on the constant table.
> Also the use of the Java object model - if we end up wanting a different
> one for DevMUD, how hard would that be?

There's a fair amount of wierdness in the Java virtual machine, enough
that I don't think we should we should use it as our primary DevMUD VM.

In particular I think a different security model may suit us better.
I'd recommend either a trusted compiler, or arranging so that nothing
the VM can do will subvert system security.  Getting the Java security
model right is obviously quite difficult.

> The source file for my bytecode interpreter is about 1500 lines, and
> I'm the world's expert on it :-) So, its fairly easy to change how it
> works. It also comes with *no* strings attached.

This sounds like an offer we can't refuse!  We can't refuse looking at it,
anyway.

What sort of environment does it need?  That's probably a good place to
start with for figuring out what the "standard" DevMUD VM interface is.

> There are lots of advantages to jumping onto the Java bandwagon in this
> respect (its not going to go away soon!), and I'm not against it for the
> main DevMUD stream. I'm just offering my stuff, since if I end up using
> the DevMUD framework to replace my own, I'll want my stuff since, by its
> nature, it is faster than equivalent Java stuff (unless you have JIT).
> No need for details - its mostly a personal thing.

Working code that's been written already is a huge advantage, as is a large
group supporting the code.  My concern is that Java is optimized for a
significantly different problem space than we're looking at.

Discussion for what we want in a VM is called for.  Discussion of how a
VM module should interact with the rest of DevMUD is even more important.

Jon Leonard