> As u propose the code as below, some what like a JNI. If we need it,
> better to port decaf to JNI compatible one. :P
The problem with JNI in addition to defining a set of ways to
slurp dynamically-linked code, it specifies a very large and complete
interface that the JNI-compliant JVM must support. It may be that this
support won't be as hopelessly difficult to write with the new version of
common/decaf (I'm working on it, honest!) but it certainly is for the
current, because the internals of (the old) decaf don't map very closely
at all to the JNI interface.
As I mentioned before, JNI is not high on my list of things to
support right now for a few reasons: dynamic linking is not supported on
the i386 build; class library code, especially with BCNI and JOS as the
operating system, should probably not require native libraries -- though
that could be construed as a policy decision I'd be happy to punt on and
decide later; and finally, I'm not sure that application code should be
allowed to call native code in general in JOS either; certainly a general
facility on either build is a good distance away (scheduling, etc).
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
