Re: Linux for JavaVM

Keith Rohrer (kwrohrer@uiuc.edu)
Fri, 17 Jan 1997 14:53:26 -0600 (CST)


> > Yes: you are wrong. The bytecode does NOT support such C features as
> > "dereference an arbitrary pointer".
I don't know about the bytecode, but I do know that Java is paranoid about
pointers to the extent that, short of a few classes in java.lang.io (or
somewhere like that) grab a contiguous block of memory; afaik, the
code "byte foo[50];" declares foo to be 50 _references_ to ints...
Plus, absolutely everything is signed.

> > The Java VM is supposed to afford a
> > safe, "boxed", environment for arbitrary Java code snippets. You can't do
> > that if you would ever allow the bytecode equivalent of perfectly-legal C
> > code such as "*(char *)0x123456 = 0x78" to run.
> Sure you can. You just have to either make sure 0x123456 is a memory
> location the applet is allowed to access, or fault. This is a
> function of the byte code interpreter.
And the last thing I expect to see in Java is an option for "inline
bytecode"...

> The Linux kernel allows C
> programs to do *(char *)0x123456 = 0x78; for example, but that doesn't
> give them access to arbitrary memory locations. This is a feature of
> the CPUs used. When you write a byte code interpreter (or compiler)
> you are doing a "virtual CPU", in effect, so you can define it to have
> whatever security features you choose.
However, needing a special java vm which is lax enough to run linuj is
likely to defeat whatever point there was to using java in the first place.

> Note that that doesn't mean the Java spec supports this kinds of
> operations (AFAIK it doesn't) but it doesn't mean it isn't possible.
Sorry I didn't get in on this thread early enough to know just what
reason someone had for suggesting "linuj", but I can't think of any of
the usual reasons besides "portability"...

Keith