> I would be inclined to doubt it.  I know little about Java, only what
> I've seen when I spent a few hours browsing their web pages...
> Of course, this p-code would not be usable for things like the kernel
> and init; it would be useful only for distributing application-level
> software.  And we already have a good application-level language for
> the purpose; it's called C.

I know nothing at all about Java, but there's no technical reason why the
C compiler can't compile to p-code (other than the time to write a new
back-end... WHEE).  The kernel then needs to include a p-code interpreter,
which need not be very large if the p-code isn't very complicated.

This would, of course, be obscenely slow, but you wouldn't compile SPICE to
p-code (not unless you were very, very masochistic).  /sbin/init doesn't have
a lot of work to do, so it might be tolerable if it were compiled to pcode
(and then did the trick I suggested earlier of mounting genuine binaries in
the traditional places); if /sbin/init has more to do than I thought, then
the p-code /sbin/init could perhaps do nothing more than perform the
appropriate mount and exec() a genuine /sbin/init.  Given that, perhaps the
p-coded /sbin/init need not be coded in C, thus avoiding the work of rewriting
the C compiler.  (Fancy that, adding an "assembly language" module to *enhance*
portability; maybe this approach is worth taking just for that. ;-)

(The p-code /sbin/init described above does so little with so much kernel help
that kernel probably ought to just go find /sbin/init.ARCH itself anyway.)