Idea for CNI/JNI wrapper

[per at bothner dot com]

This is a follow-up to Paul Fishers "Proposal for CNI/JNI problems"
from 11 Jan 2000.  The goal was to be able to automatically translate
native code written using CNI (as that is more convenient and the
prferred format of GCJ) into machine code that uses JNI.  His idea
is a variant of gcjh that translates a Java class into a C++ class
that has appropriate magic methods whose implementation is to
call JNI.  His problem was how to handle field accesses.  I have an
idea for that:  Generate helper classes.

For example, given a class:

public class Complex
{
  public double re;
  public double im;
}

we generate:

class ::Complex : public ::java::lang::Object
{
  const jobject;

private:
  class re$Field
  {
    jdouble operator*()
    {
      static jfieldID id = __jnienv->GetFieldID(...);
      return __jnienv->GetDoubleField(id);
    }
    re$Field operator=(jdouble) { ... SetDoubleField... }
  }
  class im$Field { ... }
public:
  re$Field re;
  re$Field im;
}

This is of course a very rough sketch.  I haven't really though about
how __jnienv should be handled:  as a field of ::Complex, or as
compiler magic.

It would be better if we modified CNI to add a JvRef<T> which
would be a template version of T*, and encouraged a CNI style
where JvRef<T> is used in place of T*.  In that case, when you
want to generate JNI, just specialize JvRef so that the above
generated ::Complex class is a specialization of JvRef.

Again, this is just a vague idea!
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/