public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Boehm, Hans" <hboehm@exch.hpl.hp.com>
To: "'Aaron M. Renn'" <arenn@urbanophile.com>,
	Paul Fisher <pnfisher@redhat.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: <34E36C05935CD311AE5000A0C9B6B0BF011A1622@hplex3.hpl.hp.com> (raw)

I'd like to second Aaron's concern, though perhaps for somewhat different
reasons.

My impressions are:

1) GC-related problems are sometimes nontrivial to debug.  Incorrect use of
especially JNI is likely to result in GC-related problems.

2) It will be far harder to debug those GC-related problems if we can't see
all relevant pieces of the client code, for example because some of them are
generated by the compiler.  (Generating them in the preprocessor is OK. 
I know how to use gcc -E.  Generating them later might also be OK if I can
easily generate the complete C code corresponding to the result.)

3) My impression is that automatically JNIizing code completely is
essentially
impossible.  (Adding EnsureLocalCapacity calls appropriately, for example,
seems hard.  So does insertion of the appropriate array access primitives.)
My impression from reading the spec is also that JNI,
like essentially all interfaces, is slightly underspecified and evolving.
All of these suggest that there will be subtle bugs related to JNIized code,
and any compiler transformation is likely to end up being nontrivial.
(Fortunately, most JNI code doesn't seem to need the more esoteric pieces,
but some of it will.)

4) I personally hate to debug problems related to using the more subtle
aspects
of C++ operator overloading, particularly when nonstandard "pointers" and
references get into the picture.  My experience with this part of the
language
hasn't been positive.  It seems to me that this is where the
non-gcc-specific
solutions are headed.

5) It seems to me that anything requiring significant gcc changes will delay
the project appreciably.

Hans

-----Original Message-----
From: Aaron M. Renn [ mailto:arenn@urbanophile.com ]
Sent: Wednesday, January 12, 2000 6:40 PM
To: Paul Fisher
Cc: java-discuss@sourceware.cygnus.com; classpath@gnu.org
Subject: Re: Proposal for CNI/JNI problems


Paul Fisher (pnfisher@redhat.com) wrote:
> > (1) Is it OK to write Classpath in C++ rather than C?
> 
> Yes.
> 
> > (2) Is it OK for Classpath to depend on G++ extensions?
> 
> Yes.

I think this should be considered very carefully.  I would like to avoid
these dependencies if possible.  Particularly any dependencies on gcc.

Personally, it looks like in the core classes there will be so little
code that the JNI/CNI thing could be handled with #ifdef CNI/JNI and
a configure time option added to enable it.  Or a set of macros might
handled almost everything reasonably well.

-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

             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 Boehm, Hans [this message]
  -- 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 Paul Fisher
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00   ` Jochen Hoenicke
2000-04-01  0:00     ` Stuart Ballard
2000-04-01  0:00     ` Jon Olson
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

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=34E36C05935CD311AE5000A0C9B6B0BF011A1622@hplex3.hpl.hp.com \
    --to=hboehm@exch.hpl.hp.com \
    --cc=arenn@urbanophile.com \
    --cc=classpath@gnu.org \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=pnfisher@redhat.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).