CNI invocation API proposal

[Joerg Brunsmann <joerg_brunsmann at yahoo dot de>]

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