Alexey, This is a very interesting thread. Let me give more examples of JNI pro and contra.
* JNI is good for implementation of class library native functions, because their arguments are supplied in JNI form. * JNI is a good type system for java-based tools, plug-ins, etc. * JNI is desired to code java specific things like work with local/global references, class loading, finalization, jvmti. We usually put such staff in vmcore. (Class parsing may be an exception because even specification operates in a different notation. From the other side I believe we should build our class parser on the top of something like ASN.1 and get rid of this problem.) As for a current state of our code, I don't think JNI types are good for JIT, Encoder, GC, and an execution manager. They consistently use a different type system and I dream they become usable for other projects, so no need to force them being java specific. As for a porting layer, it consists of two types of functions: * OS and library calls: I believe we should just use *nix APIs and types instead of wrappers and re-implement them for Windows like Cygwin does. First, this is now possible, and second, this just gives us less wrappers. * Assembler wrappers (fences, atomics, monitor instructions, etc): they are too far from java to use JNI. From the other side java.util.concurent mandates JNI atomics, so sometimes JNI is good even here. What do you think? On Tue, Mar 11, 2008 at 6:06 PM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov > > <[EMAIL PROTECTED]> wrote: > > > > > Consistent type definition is definitely good. Btw, what's the > > > POINTER_SIZE_INT counterpart in port library? > > > > AFAIU > > POINTER_SIZE_INT == UDATA > > POINTER_SIZE_SINT == IDATA > > > > I see. Thanks. > > -xiaofeng > > > > -- > http://xiao-feng.blogspot.com > -- With best regards, Alexei
