Slashdot

JamVM simpliciter is probably a 50k download.
The class libraries will be the bulk of the
download for the first application. Subsequent
applications will amortize the download of the
most commonly used classes. Applications themselves
will be quite small.

What I'd really like is an OCAML generating jcode.

The only alternative to JamVM under serious consideration
is mono. What are the size issues with mono?
For winxp+ platforms, .net 1.1 is already there,
so it's a null download, but for all other platforms
it is a massive download. Mono probably is out.

The dev env for jcode is Eclipse. For mono it's
probably C#Devel.

Making the class loader in the vm do everything
on-demand over the wire means getting a supportable
library-server architecture running.

In order to make a VM usable for the broadest audience,
it must be available as the smallest possible download
in the correct binary format for the user's platform.

JamVM appears to provide the smallest useful Java
environment. It is written against a Posix API,
and uses pthreads as well as libdl. The major
platforms of interest to me are i386-win32, i386-linux,
and ppc-osx. The missing piece for making JamVM
work (byte-code interpretation only) is win32
support for the libdl API.

GNU Classpath now contains enough of Swing and AWT
to be useful. Here are some reasonable approaches
to providing portable graphics over the platforms
of interest for legacy Swing and AWT applications:

1 - SwingWT, which uses the pre-existing
    Eclipse SWT implementation to provide Swing and
    AWT APIs;

2 - PJA+Odonata+(viewer) which writes its
    graphics to a soft framebuffer and puts them out
    using VNC protocol -- the missing piece is the
    local viewer wrapper which provides the actual
    display.

Any others?

I have chanced upon this space between what is above it and what is below it, which I now ornament with this utterance.