CNI invocation API proposal

Fri Apr 13 05:02:00 GMT 2001

Hi,
this is how far I got at this time for a
CNI invocation API proposal
* Where do we come from
 GCJ supports two interfaces to native code. It's own
 easy to use CNI and for compatibility reasons JNI. 
 Programs written in other languages than gcj java want 
 to call gcj compiled programs.
 The JNI Invocation API allows non-Java code to create a 
 JVM and load and use Java classes. The classes can be
 created by a multithreaded native program. The thread
 which creates the JVM is considered to be the main thread.
 Only one single JVM can be created by a native multithreaded
 program, but this single JVM can run multiple threads.
* Where are we now
 Currently the JNI invocation API is implemented but
 not deeply tested.
 Five clients want entry points into libgcj:
 - jvgenmain
 - gij
 - JNI 
 - CNI 
 - the set of all other applications written in other languages
 jvgenmain and gij use the JvRunMain function. The other three 
 don't have an entry point yet. jvgenmain and gij implement
 their own argument handling.
* Where do we want to go
 No support for the JDK 1.1.x JNI.
 For an implementation this layered approach can be used:
 |----------------------------------------------------------------|
 | JNI based invocation API | gij | jvgenmain | non-java programs |
 |----------------------------------------------------------------|
 | CNI based invocation API |
 |----------------------------------------------------------------|
 | GCJ object engine |
 |----------------------------------------------------------------|
 A first API prototype can look like this noted in pseude Java.
 class JavaVMAttachArgs {
 int version; 
 String threadName;
 Object threadGroup; 
 } JavaVMAttachArgs;
 class JavaVMOption {
 String optionString;
 Object extraInfo;
 }
 class JavaVMArgs {
 final static public int JNI_VERSION_1_2; 
 JavaVMAttachArgs attachArgs;
 JavaVMOption [] options;
 int nOptions;
 String threadName;
 int version;
 boolean ignoreUnrecognized; 
 }
 /**
 The class EmbeddableGCJJavaVM represents
 the entry point for non-java code.
 Notes:
 o The JNI function getCreatedJavaVMs() isn't
 listed because only one JavaVM is
 supported in GCJ. That means the
 createJavaVM can be used to obtain a 
 reference to the singleton GCJ JVM.
 o The concept of JNIEnv for calling methods
 isn't necessary when using the CNI based approach
 */
 class EmbeddableGCJJavaVM {
 /**
 The name to be used for the first thread
 which create the GCJ JVM.
 */
 static public final String mainThreadName = "main";
 /**
 Allows to create a GCJ JVM and subsequently use it in 
 an application. 
 vmArgs is a reference to initialization parameters. 

 Note: The JNI env pointer which points to a table of JNI functions 
 isn't used here.
 */
 static public synchronized 
 EmbeddableGCJJavaVM createJavaVM(JavaVMArgs vmArgs) 
 throws GCJVMException
 { }
 static public synchronized 
 JavaVMArgs createDefaultJavaVMInitArgs() 
 throws GCJVMException
 {
 JavaVMArgs args = new JavaVMArgs();
 args.version = JavaVMArgs.JNI_VERSION_1_2; 
 args.nOptions = 0; 
 args.options = null; 
 arg.signoreUnrecognized = true; 
 }
 Class findClass(String className) throws Exception {
 }

 /**
 Destroys the Java virtual machine. What to do here?
 */
 void destroyJavaVM() throws GCJVMException 
 { }
 /*
 Do we need to attach or detach a thread to a GCJ JavaVM?
 int attachCurrentThread(
 void **p_env,
 void *thr_args);
 int detachCurrentThread() { }
 */
 }
 Usage:
 JavaVMArgs * args = EmbeddableGCJJavaVM::createDefaultJavaVMInitArgs();
 args->nOption = 1;
 JavaVMOption ** options = new JavaVMOption * [1];
 options[1]->optionString = "-DaDefine";
 args->options = options;

 EmbeddableGCJJavaVM *javaVM = 
 EmbeddableGCJJavaVM::createJavaVM(args);
 jclass c = javaVM->findClass("A");
 Object *o = c->newInstance();
 o->m();
 Open questions:
 1. Do we need to attach/detach threads to the GCJ JVM?
 2. Do we need to destroy a GCJ JVM?
 3. Is it possible and reasonable to build a JNI based 
 invocation interface upon the CNI based approach?
 4. Two non-java processes p1 and p2 with two threads
 each, say t11, t12, t21 and t22 which use a statically 
 linked gcj object engine. Each process p1 and p2 has its 
 own reference to the gcj object engine because of static
 linkage. Assume now that the non-java processes p1 
 and p2 with their threads use a dynamic linkage scheme. 
 Now two different processes use the same gcj object engine
 where for example t22 and t11 concurrently use the GCJ JVM.
 Does this make sense? Does this cause problems?
 Next steps:
 o Clarify open questions
 o implement CNI invocation
 o test with non-java program
 o let gij use CNI invocation
 o let jvgenmain use CNI invocation
 o let JNI use CNI invocation?
JÃƒÂ¶rg
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de