classpath/vm/* suspicions are correct. Just implement the native methods
defined by vm/reference/* and you will be fine. Check
http://www.gnu.org/software/classpath/doc/vmintegration.html for a lot of
information on integrating a VM. Some dependencies from the VM to the class
library are built into the Java spec. That document talks about those and
about other stuff you may need to watch out for when implementing Classpath
on your VM. You will be the second VM we integrate with. If you need
changes specific to yours, this stuff is not set in stone--we just need to
make sure those changes do not affect portability adversely.
Native code, as you no doubt realize, is necessary. We have chosen JNI so
that we can keep as much of our code VM-independent. Dependence on libc is
likewise unavoidable; implementing time(), printing to files, and stuff like
that would be hardware- and OS-dependent otherwise. We don't have way too
many libc functions we require, and for the most part they are the normal
ones.
As to size of native methods, we are actually implementing everything
possible in Java, but we implement native methods where it is reasonable
and/or necessary.
Now, one major problem may come up with AWT, that I hadn't thought of
before. The set of peers we are currently developing use GTK+, which uses
glib, which is somewhat platform independent but is definitely
windowing-system dependent. They make calls either to X or to Win32 to do
the actual windowing stuff. JOS needs a windowing system, right? Well, it
looks like you'll have to find and borrow one (the Shark AWT that Michael
Emmel occasionally pops up and talks about sounds like a definite
candidate--from what I understand, it's mainly written in Java), or write
your own.
--John
