public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: java-discuss@sourceware.cygnus.com, classpath@gnu.org
Subject: Re: Proposal for CNI/JNI problems
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <m24scjx2hi.fsf@magnus.bothner.com> (raw)
In-Reply-To: <y68k8lg6t70.fsf@ignucius.devel.redhat.com>

Paul Fisher <pnfisher@redhat.com> writes:

> While it's important that Classpath continue to support JNI,

The first question is why?  What is the goal?  (Obviously JVMs
should support JNI; that is not my question.)  Presumably, the
goal is that Classpath can be used as the standard Java library
for non-Gcj JVMs.  The question then is how portable do we
need to/want to be?

(1) Is it OK to write Classpath in C++ rather than C?  Doing so rules
out architectures that don't have a C++ compiler.  If a platform does
not support C++, then it doesn't support Gcc.  From a GNU point of
view, I don't think it is important to support such platforms.  So C++
is it, as it makes it easier to use CNI or a JNI/CNI hybrid.

(2) Is it OK for Classpath to depend on G++ extensions?  For example,
G++ has some special knowledge of Java, to support CNI.  Whether
these extensions are going to help with JNI is another matter.

Tom Tromey suggested that the ideal way to let people write code
that is both JNI and CNI-compliant is to have a compiler that can
read CNI and emit JNI.  See:
http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00570.html
My first reaction was that this was too difficult.  But it becomes
simpler if we remember that JNI is an Application *Binary* Interface.
All we need do is have G++ have an option to generate JNI calls.

For example, let is call this option -femit-jni.  First, note that
G++ already has the concept that certain classes have the "Java
property".  (In practice, thes are the classes that inherit from
java::lang::Object.)  If the compiler sees a field reference
        VAL->FIELDNAME
*and* -femit-jni has been specified *and* the type of VAL is a
pointer to a class that has the Java property, *then* the compiler
instead generates (code *as if* it had seen):
        static jfieldID f1 =
          (*__jnienv)->GetFieldID(__jnienv, CLS, "FIELDNAME", ...);
        (*__jnienv)->GetObjectField(__jnienv, VAL, f1);

Method invocation can be handled similarly.

What about the __jnienv mentioned before?  That is the JNIEnv pointer
needed by JNI.  It is provided by the JNI call.  The compiler
has to translate the CNI method declaration to a JNI method.
For example:
        jclass java::lang::Object::getClass()
        {
          return ...
        }
would get translated by the compiler to:
        jclass Java_java_lang_Object_getClass(JNIEnv* __jnienv, jobject this)
        {
          return ...;
        }

That is not a big deal.  Basically, it's a special name mangling,
plus an extra hidden argument.

Finally, consider the body of Object::getClass().  We want to be able to
write:
        return Jv_GetObjectClass(this);
We want to have the compiler generate:
	return (*__jnienv)->GetObjectClass(__jnienv, this);
We don't want to teach the compiler about all these CNJ/JNI methods.
Instead, we put it in the cni.h header file:
        #ifdef __JNI
        #define Jv_GetObjectClass(OBJ) \
          (*__jnienv)->GetObjectClass(__jnienv, OBJ) 
        #else
        #define Jv_GetObjectClass(OBJ) _Jv_GetObjectClass(OBJ)
        #endif
Now all we have to do if make sure -femit-jni causes __JNI to be defined.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

  reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Paul Fisher
2000-04-01  0:00 ` Per Bothner [this message]
2000-04-01  0:00   ` Jochen Hoenicke
2000-04-01  0:00     ` Jon Olson
2000-04-01  0:00     ` Stuart Ballard
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00   ` Bernd Kreimeier
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00       ` Bernd Kreimeier
2000-04-01  0:00         ` Per Bothner
2000-04-01  0:00           ` Bernd Kreimeier
2000-04-01  0:00             ` Per Bothner
2000-04-01  0:00               ` Bernd Kreimeier
2000-04-01  0:00                 ` Per Bothner
2000-04-01  0:00                   ` Alexandre Oliva
2000-04-01  0:00                   ` Bernd Kreimeier
2000-04-01  0:00   ` Paul Fisher
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00     ` Aaron M. Renn
2000-04-01  0:00       ` Stuart Ballard
2000-04-01  0:00         ` Chris Blizzard
2000-04-01  0:00           ` Chris Blizzard
2000-04-01  0:00 Lam.Mark
2000-04-01  0:00 ` Aaron M. Renn
2000-04-01  0:00   ` Brian Jones
2000-04-01  0:00 David Pettersson
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00 Boehm, Hans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m24scjx2hi.fsf@magnus.bothner.com \
    --to=per@bothner.com \
    --cc=classpath@gnu.org \
    --cc=java-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).