John Morrison wrote:
>
> (3) We'd like to do everything possible in Java, and as little as possible in
> "native" code (think of native code as microcode). In a perfect world,
> classpath would not require any native code (we realize we do not live in even a
> reasonably nice world, let alone a perfect one -- however, our desire to
> minimize native code is not unreasonable given our low-memory constraints).
> Building a dynamic native-code/microcode linker to handle ELF format .o files is
> something I personally would like to avoid (I am more or less responsible for
> the low-level systems programming).
I had some thoughts about this a while back; I don't know whether
they're relevant, but I thought I'd share them in case they are... you
may already have a similar scheme in place, or have a better way of
doing it than the one that I imagined.
What I was thinking about was about the nature of "native" code. In my
experience, native code is used for 3, possibly 4, very distinct
reasons:
1) It requires direct access to hardware or memory, in a way that Java
bytecodes simply cannot express.
2) It requires some form of low-level interaction with the VM
(reflection, some of Runtime, some of System, some of Object and some of
Class fall into this category)
3) It is necessary to get around some java security restriction (I
believe this occurs one time in Classpath, where a class in java.util
needs to access package-private state in java.lang; there may be other
cases)
4) It requires access to OS library routines to get functionality that
the standard java class libraries do not provide for (or, it is the
*implementation* of the class library that provides that functionality).
Now, 1) is not applicable to Classpath and has presumably already been
solved by JOS. 2) applies only to a small proportion of the code, and
has again probably been solved to some extent (it's pretty inherent in
the design of the VM). 3) and 4) do not actually require *native* code
at all, just Java code that has access to APIs that are not part of the
standard class libraries. (both involve some security issues, but these
again will need to be solved for JOS anyway - you don't want app code
being able to access the hardware driver code directly, for example).
So, what I envision is a scheme for allowing delegation of methods
marked as "native" to code that is actually implemented in java itself.
For example, suppose the method java.lang.Socket.close() is declared
native. On most OS's, this would be delegated by JNI to a C-language
function which would call some libc socket function. On JOS, the same
call could in fact trigger some name-mangling of class names, and cause
a class (for example) org.jos.native.java.lang.Socket to be accessed to
implement the close() method. This would then access JOS's specific
low-level networking classes to get the required functionality, without
ever leaving java code.
The advantage I see with this method is that the same java code can be
loaded on both JOS and other platforms; the only difference is in the
*implementation* of the native parts. It's sort of like JNI for Java,
instead of for C.
Just a thought...
Stuart.
>
> I've been playing with classpath for the past few days, so I'd
> figure I'd check in with my understanding so far.
>
> (A) We'll need to add JNI if we want to use classpath's native code.
> (B) Some amount of that native code will have libc stuff in it. While
> this shouldn't be a terrible problem for the host build (anyone
> actually /know/?) it's a disaster for the i386 build. It looks
> like they put all the native code in classpath/native/*, which
> means we should be able to point the Makefiles at something like
> classpath/i386/* and everything will be happy.
> (C) It looks all the jvm-specific bits have been localized to
> java classes in classpath/vm/*, which can just implement in
> jjos/common/decaf[/vm].
> (D) The anonymous CVS server doesn't seem to have the 'configure' script
> in it, so get the snapshot if you're interested in working on it.
> (E) Likewise, the configure script seems to want japhar to be installed
> (looks for 'japhar-config'); someone should find out what the
> configure script needs to know from this. (Then implement a
> --with-jjos option on the config?)
> (F) Because of (E), I haven't been able to build a classes.zip out of
> classpath, and see how well it works with jjos/decaf.
>
> JM, you've been in contact with the classpath developers; if you
> could run my suspicions and questions by (one of) them, that would be
> great.
>
> -_Quinn
>
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
