public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jochen Hoenicke" <Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE>
To: Per Bothner <per@bothner.com>
Cc: 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: <14460.37463.273837.406646@celan.Informatik.Uni-Oldenburg.DE> (raw)
In-Reply-To: <m24scjx2hi.fsf@magnus.bothner.com>

On Jan 11, Per Bothner wrote:
> 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?  Presumably, the
> goal is that Classpath can be used as the standard Java library
> for non-Gcj JVMs. 

Yes.

> 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?  [...]
> (2) Is it OK for Classpath to depend on G++ extensions?  [...]

I don't feel too good with using C++ in classpath.  I can't rationally
explain this though.  

> 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.

> [...]

I like this idea (indepent of using it for classpath).  I don't know
how difficult this is, since I don't know much about the internals of
g++.  But when I converted the java.util.zip classes, there were some
issues that a compiler can't solve:

CNI has the method "elements" to access the elements of an array.
The corresponding JNI method is "Get<Type>ArrayElements", but it needs
an "Release<Type>ArrayElements" later.  This pair is necessary, to
support copying garbage collectors, that may move the array on the
fly, or to support jvms that store array elements in a different way
(e.g. packing boolean arrays).

Under JNI you have to register global references.  AFAIK libgcj's
garbage collector scans the data area, so one doesn't need to
register them under CNI.

Another point is how to put pointers to native structures into a
classfile.  Sun didn't solve it well.  If I understand the code in
japhar's java/util/zip correctly sun used an int field to store the
pointer and later changed it to long to support 64bit architectures.
libgcj declares natives fields as "gnu.gcj.RawData", but this is not
portable to other jvms, where the garbage collector doesn't know that
this class is special.  My solution was to put the structure into a
java byte array, which imposes a little overhead, but should be
portable (and you get it freed automatically).

  Jochen

  parent 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
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                   ` Bernd Kreimeier
2000-04-01  0:00                   ` Alexandre Oliva
2000-04-01  0:00   ` Jochen Hoenicke [this message]
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00     ` Jon Olson
2000-04-01  0:00     ` Stuart Ballard
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
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 David Pettersson
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00 Boehm, Hans
2000-04-01  0:00 Lam.Mark
2000-04-01  0:00 ` Aaron M. Renn
2000-04-01  0:00   ` Brian Jones

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=14460.37463.273837.406646@celan.Informatik.Uni-Oldenburg.DE \
    --to=jochen.hoenicke@informatik.uni-oldenburg.de \
    --cc=classpath@gnu.org \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=per@bothner.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).