I've been thinking about a similar idea for a while I call it a signature compiler.
The purpose of a signature compiler is binding implementation to a method "signature"
at
runtime in a JVM dependent way. This is what the native key word really causes but
there's
no reason to restrict it to only native methods. The scenario I used was the case of
a low level
graphics library on some systems this may parts which could be implemented in
hardware
bytecode or in native code. The signature compiler allow the "OS" to bind the
implementation at runtime.
The current "native" code shared library approach is but one way to accomplish this
goal.
Thus these methods repsrent code which is best "compiled" by the OS.
Even in the case of native code we really dont need a full blown shared lib
capability.
I think java would like to acess native code in a manner similar to Objective-C.
The bindings should be transparent.
The jit should be able to load "native" code into the runtime the same way it runs
bytcode thats been converted. Theres no real reason to continue to use a C based
approach to native code.
The key point to a signature compiler is that the best implementation is left up to
the "OS" .
Stuart Ballard wrote:
> 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
