public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00       ` Bernd Kreimeier
@ 2000-04-01  0:00         ` Per Bothner
  2000-04-01  0:00           ` Bernd Kreimeier
  0 siblings, 1 reply; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bernd Kreimeier; +Cc: java-discuss, classpath

Bernd Kreimeier <bk@lokigames.com> writes:

> compile time additional information about object memory layout,
> for a JNI source?

Well, in some ways you have more information, because you all
the low-level details needed for JNI.  But in other ways it is much
harder [to compile JNI to the CNI ABI] because JNI is all function
calls and it may be difficult to infer the programmer's intention.
For example, you have a JNI function that gets a jfieldID, and
other functions to actually use the jfieldID to access a field.
The problem is the compiler needs to follow the chain of
getting the jclass -> getting the jfieldID -> getting the actual field
before it can figure out the actual field.  It need to replace all
of that with a direct field access in CNI.  Following that chain
can be difficult when (e.g.) a jfieldID is cached.  It may require
some global analysis (i.e. more than a single method).

> In other words, the semantics of JNI code prohibits all
> CNI-like optimizations due to parsing complexity issues?

Not the parsing;  the global analysis mentioned above.

> If a hypothetical G++ "emit-jni" option would generate JNI C 

G++ emits assembly code, not C. -femit-jni would emit binary
code *equivalent* to JNI C (i.e. *as if* compiled from JNI C),
but not actually C.

> No doubt, JNI ABI compatibility would make CNI a much more
> viable option. In this case, the major concerns seem to be
> Hans Boehm's points (3) and (5), quote:

Those are certainly important concerns.  We may have to settle
for conditional compilation in tricky cases.  The goal, though,
would be that *most* native methods would not need conditional
compilation, or that the -femit-jni at least greatly reduces
the uglyness of conditional compilation.  If we can't figure out
how to do that, then there isn't much point in the idea.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00   ` Jochen Hoenicke
@ 2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00     ` Jon Olson
  2000-04-01  0:00     ` Stuart Ballard
  2 siblings, 0 replies; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss, classpath

"Jochen Hoenicke" <Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE> writes:

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

It doesn't have to be an all-or-nothing solution.  For something
like Release<Type>ArrayElements, we can require that people put
JNI-specific code in an #ifdef __JNI section.   Ideally, we want
to remove the need for that, but it might be good enough to
just *minimize* the need for #ifdef __JNI, at least in the short
term.  In other words, in can be an incremental process:  Start
out by having G++ munge the header mangling and add __jnienv;
then add support for field access;  then method access;  then
other features depending on priority.

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

Well, we can still use gnu.gcj.RawData (or gnu.RawData) with JNI.
However, for the JNI case gnu.gcj.RawData would be a real class:

public class RawData
{
  int index;
}

Here index is an index into a global RawDataTable

typedef void * RawPointer;

RawPointer** RawDataTable;

#ifdef __JNI
#define JvGetRawData(rdata) RawDataTable[rdata->index]
#define JvAllocRawData(data) new Rawdata(AssignrawdataIndex(data))
#define JvFreeRawData(data) RawDataTable[rdata->index] = NULL
#else
#define JvGetRawData(rdata) ((RawPointer) rdata)
#define JvAllocRawData(data) (data)
#define JvFreeRawData(data) { }
#endif
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 Proposal for CNI/JNI problems Paul Fisher
@ 2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00   ` Paul Fisher
                     ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss, classpath

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/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00         ` Per Bothner
@ 2000-04-01  0:00           ` Bernd Kreimeier
  2000-04-01  0:00             ` Per Bothner
  0 siblings, 1 reply; 28+ messages in thread
From: Bernd Kreimeier @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

Per Bothner writes:
 > of that with a direct field access in CNI.  Following that chain
 > can be difficult when (e.g.) a jfieldID is cached.  It may require
 > some global analysis (i.e. more than a single method).

That's what I meant. So, it should be easier to do the reverse
(expand CNI to JNI calls) but then ID caching and other
optimizations would have to be added automatically as well?

 > > If a hypothetical G++ "emit-jni" option would generate JNI C 
 > 
 > G++ emits assembly code, not C. -femit-jni would emit binary
 > code *equivalent* to JNI C (i.e. *as if* compiled from JNI C),
 > but not actually C.

I know that's the current proposal. Why is CNI-to-JNI C conversion
out of the question? It would address some issues (like
porting to non-G++ platforms, Hans Boehm's point (2), etc.).

 > Those are certainly important concerns.  We may have to settle
 > for conditional compilation in tricky cases. 

OK IMO. Now, wouldn't CNI-to-JNI C ease identifying related
problems? 

Is it significantly easier to map on assembly level?
There'd be little point in a C level conversion if this
inevitably led to "cfront-with-Java-structs" for mixed
C++/CNI code. Is that the case?

                                     b.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  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
  0 siblings, 2 replies; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bernd Kreimeier; +Cc: java-discuss, classpath

Bernd Kreimeier <bk@lokigames.com> writes:

> ANTLR?

ANRLR is not a compiler;  it is parser-generator.  It does not handle
C++ name resolution, for example, as far as I know.

> What do you mean by annotated-CNI?

CNI with macros that are no-ops when using CNI, but that help whatever
tools is used to convert to JNI.

> Is a modification of gcjh a good way to simplify the task for
> the parser/converter? I.e. marking Java-turned-C++ classes, 
> enforcing naming schemes/prefixes etc.? 

I don't see how it helps.  The problem is analyzing the user's C++
native code.

> Having parts of the toolchain being pure Java (along with the
> ability to compile them to native code for bootstrap) is the
> foundation for much more portability.

But why is this an inportant goal for GNU Classpath?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00   ` Jochen Hoenicke
  2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00     ` Jon Olson
@ 2000-04-01  0:00     ` Stuart Ballard
  2 siblings, 0 replies; 28+ messages in thread
From: Stuart Ballard @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jochen Hoenicke; +Cc: Per Bothner, java-discuss, classpath

Jochen Hoenicke wrote:
> 
> 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).

Classpath has been using a library called NSA, which Paul wrote IIRC,
that can be implemented either with native VM support if available
(which Japhar has) enabling the native data to actually be stored as
part of the object, or using a hash table based on the
System.identityHashCode of the object if not. I haven't heard about any
problems with this approach. Admittedly it's a little overhead if your
VM doesn't provide the support, but it's only a little and it doesn't
take much to add the support to a VM. Plus it's 100% portable.

Stuart.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  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     ` Aaron M. Renn
  2000-04-01  0:00   ` Jochen Hoenicke
  2000-04-01  0:00   ` Bernd Kreimeier
  2 siblings, 2 replies; 28+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss, classpath

Per Bothner <per@bothner.com> writes:

> The first question is why?  What is the goal?

The goal is for Classpath to be the "standard" set of Java class
libraries for the majority of free JVMs.  Or at least, with a
reasonable amount of effort, a VM should be able to support Classpath.
Therefore, we need to support JNI in some form.

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

> For example, let is call this option -femit-jni.

This sounds like a good solution, and it's certainly better than the
pure-C++ solution that I was working on.

Do you, or anyone else in the gcc/gcj camp, have time to work on such
a feature?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00     ` Per Bothner
@ 2000-04-01  0:00       ` Bernd Kreimeier
  2000-04-01  0:00         ` Per Bothner
  0 siblings, 1 reply; 28+ messages in thread
From: Bernd Kreimeier @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

Per Bothner writes:
 > Gcj will (soon) digest JNI source as is. 

Very good.

 > We handle "compilation of Java+JNI source to native code"
 > using any C compiler combined JNI run-time support.
 > You will be free to use JNI.  It's your choice: JNI gives you
 > portability, but it is much slower and much more tedious to 
 > use than CNI.

OK, let's push this a bit further. CNI is elegant and efficient
because it knows which VM it will be executed with, and can thus
take shortcuts. I guess that the discussion about a CNI+JNI
abstraction, or preproecessor mappings of one to the other
indicate that it is difficult if not impossible to exploit at
compile time additional information about object memory layout,
for a JNI source?

In other words, the semantics of JNI code prohibits all
CNI-like optimizations due to parsing complexity issues?


 > The current discussion is about a *third* option: Write your
 > application in CNI (mostly, perhaps with some conditional
 > compilation), and then use a special compiler (G++) that translates
 > your CNI source into a JNI binary.  That binary will work with *any*
 > JVM that support JNI.  That gives you the convenience of writing CNI,
 > and the speed of CNI when running on a CNI-supported platform.  You
 > also get (most of) the advantage of JNI portability, since you can use
 > any JVM that supports JNI, but you are restricted to compiling your
 > native code using G++.

If a hypothetical G++ "emit-jni" option would generate JNI C 
(not C++ or heavily macro'ed) code, this restriction would
only hurt on machines that have no G++ (which could be overcome
by cross-compiling to C or native).


 > The goal is to give people (and library writers) options.

No doubt, JNI ABI compatibility would make CNI a much more
viable option. In this case, the major concerns seem to be
Hans Boehm's points (3) and (5), quote:

  (3) automatically JNIizing [CNI] code completely
       is essentially impossible

[Question is, how much ground can be covered? Good enough 
 for 90% of the usual applications using native methods?]

  (5) anything requiring significant gcc changes will
       delay the project appreciably

[Good point. How long will it take to add ability to link 
 against JNI-ABI compliant DLL's, by comparison?]

                                        b.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  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
  1 sibling, 1 reply; 28+ messages in thread
From: Aaron M. Renn @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Paul Fisher; +Cc: java-discuss, classpath

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/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00                 ` Per Bothner
  2000-04-01  0:00                   ` Bernd Kreimeier
@ 2000-04-01  0:00                   ` Alexandre Oliva
  1 sibling, 0 replies; 28+ messages in thread
From: Alexandre Oliva @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: Bernd Kreimeier, java-discuss, classpath

On Jan 16, 2000, Per Bothner <per@bothner.com> wrote:

> Bernd Kreimeier <bk@lokigames.com> writes:

>> What do you mean by annotated-CNI?

> CNI with macros that are no-ops when using CNI, but that help whatever
> tools is used to convert to JNI.

And, preferrably, no-ops that would be warned about when missing, so
as to arrange that ``porting'' to JNI isn't a pain just because CNI
doesn't require certain stuff.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00           ` Bernd Kreimeier
@ 2000-04-01  0:00             ` Per Bothner
  2000-04-01  0:00               ` Bernd Kreimeier
  0 siblings, 1 reply; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bernd Kreimeier; +Cc: java-discuss, classpath

Bernd Kreimeier <bk@lokigames.com> writes:

> I know that's the current proposal. Why is CNI-to-JNI C conversion
> out of the question?

You need to analyze CNI (i.e. C++) source code.  You need to recognize
CNI field and method references, which are just C++ field/method
references.  That implies a semantic analysis of the C++ code.  The
logical tool is a compiler. The only C++ compiler we have available is
G++. It does not emit C source.  Adding an option to emit C is a major
project. It is even worse if you want human-readable C.

What you can do is convert annotated-CNI to JNI C.  That loses some
of the simplicity of CNI, but may be worth considering.  However,
that is a quite different idea.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00         ` Chris Blizzard
@ 2000-04-01  0:00           ` Chris Blizzard
  0 siblings, 0 replies; 28+ messages in thread
From: Chris Blizzard @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Stuart Ballard, Aaron M. Renn, Paul Fisher, java-discuss, classpath

Chris Blizzard wrote:
> 
> If you want to do this you might want to look at the C++ portability
> guidelines that Mozilla has in place.  These rules are a result of many years
> of pain at Netscape porting their code base to 20 some-odd platforms.

Sorry, here's the URL:

http://www.mozilla.org/hacking/portable-cpp.html

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
If a kid asks where rain comes from, I think a cute thing to tell
him is "God is crying." And if he asks why God is crying, another
cute thing to tell him is "Probably because of something you did."
------------

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00   ` Bernd Kreimeier
@ 2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00       ` Bernd Kreimeier
  0 siblings, 1 reply; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bernd Kreimeier; +Cc: java-discuss, classpath

Bernd Kreimeier <bk@lokigames.com> writes:

> How does this address compilation of Java+JNI source
> to native code? With or w/o the flexibility of TowerJ?

Separate issue, as I expained in a subsequent message.
We handle "compilation of Java+JNI source to native code"
using any C compiler combined JNI run-time support.

The current discussion is purely about how to write the
Classpath libraries, and any other application that
want to *optimize* for JVMs that use CNI, but still
JVMs that only support JNI.  (The former may support
CNI *as well* as JNI;  at gcj will soon support both.)

> If classpath and/or gcj requires CNI, and does not digest
> JNI source as is, then it is not the right tool for many
> purposes (like mine).

Gcj will (soon) digest JNI source as is.  I don't know about
other projects using Classpath.

> Is the combined classpath+gcj roadmap acknowledging that 
> people do use, and will continue to use, JNI? Maybe I am
> missing something - I'd appreciate a cnfirmation. I can't
> make myself dependend on CNI/gcj, and I suspect I am not
> alone.

You will be free to use JNI.  It's your choice: JNI gives you
portability, but it is much slower and much more tedious to use than
CNI.  The current discussion is about a *third* option: Write your
application in CNI (mostly, perhaps with some conditional
compilation), and then use a special compiler (G++) that translates
your CNI source into a JNI binary.  That binary will work with *any*
JVM that support JNI.  That gives you the convenience of writing CNI,
and the speed of CNI when running on a CNI-supported platform.  You
also get (most of) the advantage of JNI portability, since you can use
any JVM that supports JNI, but you are restricted to compiling your
native code using G++.

The goal is to give people (and library writers) options.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00     ` Aaron M. Renn
@ 2000-04-01  0:00       ` Stuart Ballard
  2000-04-01  0:00         ` Chris Blizzard
  0 siblings, 1 reply; 28+ messages in thread
From: Stuart Ballard @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Aaron M. Renn; +Cc: Paul Fisher, java-discuss, classpath

"Aaron M. Renn" wrote:
> 
> Paul Fisher (pnfisher@redhat.com) wrote:
> > > (1) Is it OK to write Classpath in C++ rather than C?
> >
> > Yes.

I don't see a problem with this. After all, Mozilla does this and is
still extremely portable. We should be careful about using some of the
less widely-deployed features, though, just as Moz is.

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

Agreed.

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

I'm wondering if it wouldn't be possible to provide a portable perl
script as part of the Classpath code that would be equivalent to this,
but would output C++ source using JNI. If g++ wanted to support the
-femit-jni feature, the perl code could be turned off in configure, but
classpath could still compile on any C++ compiler.

The only problem that I can see is that the perl code would have to be
very intelligent to figure out that a given class inherited from
java::lang::Object (possibly indirectly). It might be necessary to
*also* include some kind of "magic comment" that would label such
classes to the perl code, and be ignored by g++ which could figure it
out for itself.

Stuart.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00   ` Jochen Hoenicke
  2000-04-01  0:00     ` Per Bothner
@ 2000-04-01  0:00     ` Jon Olson
  2000-04-01  0:00     ` Stuart Ballard
  2 siblings, 0 replies; 28+ messages in thread
From: Jon Olson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jochen Hoenicke, Per Bothner; +Cc: java-discuss, classpath

On Wed, 12 Jan 2000, Jochen Hoenicke wrote:

>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

Interesting idea, putting the native peer class into a byte array.
Seems like kind of a hack, but I guess it solves the problem.
Sun's solution of using a long to store a pointer is a real kludge.

My solution was to store an `int' as the peer and to make any
Java class which require a native peer a subclass of this Peer
class:

public class Peer
{
  protected int _peer;
  public Peer(int peer)	{ _peer = peer; }
  public native void destroy();
  protected void finalize() {
    destroy();
  }
}

Native code stores peer objects in a C++ Vector and manages
recovering space when finalized in destroy().

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
INTERNET:  olson@mmsi.com
PHONE:     (520)746-9127
FAX:       (520)889-5790

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00   ` Paul Fisher
@ 2000-04-01  0:00   ` Jochen Hoenicke
  2000-04-01  0:00     ` Per Bothner
                       ` (2 more replies)
  2000-04-01  0:00   ` Bernd Kreimeier
  2 siblings, 3 replies; 28+ messages in thread
From: Jochen Hoenicke @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00                 ` Per Bothner
@ 2000-04-01  0:00                   ` Bernd Kreimeier
  2000-04-01  0:00                   ` Alexandre Oliva
  1 sibling, 0 replies; 28+ messages in thread
From: Bernd Kreimeier @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

Per Bothner writes:
 > > Is a modification of gcjh a good way to simplify the task for
 > > the parser/converter? I.e. marking Java-turned-C++ classes, 
 > > enforcing naming schemes/prefixes etc.? 
 > 
 > I don't see how it helps.  The problem is analyzing the user's C++
 > native code.

If you can safely separate the user written C++ (e.g. classes
which are not the native equivalent of Java classes) from the
C++ statements that are actual Java access by CNI, maybe the
problem gets closer to textual replacement then. So, if
gcjh enforces a certain mind of annotation, namespace, the
analysis of the user's code might be simnplified? Especially
if done before CPP expands CNI statements for gcj's G++?


                                        b.




p.s.:
 > > Having parts of the toolchain being pure Java (along with the
 > > ability to compile them to native code for bootstrap) is the
 > > foundation for much more portability.
 > 
 > But why is this an inportant goal for GNU Classpath?

I do not know whether portability is a goal for GNU Classpath. 
I personally consider it important. Free Software written in Java,
with minimal native dependencies both at built time and runtime,
that can be compiled to native code or bytecode, could IMO
make large inroads into new user groups - Joe Windows will
always shy away from libtool/Perl/G++/Cygwin.

 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00             ` Per Bothner
@ 2000-04-01  0:00               ` Bernd Kreimeier
  2000-04-01  0:00                 ` Per Bothner
  0 siblings, 1 reply; 28+ messages in thread
From: Bernd Kreimeier @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

Per Bothner writes:
 > You need to analyze CNI (i.e. C++) source code.  You need to recognize
 > CNI field and method references, which are just C++ field/method
 > references.  That implies a semantic analysis of the C++ code. 

Yep.

 > The logical tool is a compiler. The only C++ compiler we have
 > available is G++.

ANTLR? Bootstrapping issues aside.

 > It does not emit C source.  Adding an option to emit C is a major
 > project. It is even worse if you want human-readable C.

Granted. I wasn't focused on G++.

 > What you can do is convert annotated-CNI to JNI C. 

What do you mean by annotated-CNI?

 > That loses some of the simplicity of CNI

Is a modification of gcjh a good way to simplify the task for
the parser/converter? I.e. marking Java-turned-C++ classes, 
enforcing naming schemes/prefixes etc.? 


 > However, that is a quite different idea.

Having parts of the toolchain being pure Java (along with the
ability to compile them to native code for bootstrap) is the
foundation for much more portability. I'd prefer e.g. an ANTLR
solution for that reason alone, given that the feasibility
of either approach still seems equally dubious to me :-\.

                                                  b.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00   ` Paul Fisher
@ 2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00     ` Aaron M. Renn
  1 sibling, 0 replies; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss, classpath

Paul Fisher <pnfisher@redhat.com> writes:

> This sounds like a good solution, and it's certainly better than the
> pure-C++ solution that I was working on.
> 
> Do you, or anyone else in the gcc/gcj camp, have time to work on such
> a feature?

I don't think I have time to actually do the work.  I can help out, in
pointing to where I think things need to be done.  Though the specific
case of changing the method header might be best to ask the gcc
mailing list, because I've heard rumours about plans to clean up the
code that does name mangling.  They might also be the best to suggest
the cleanest place to fix this.  (Adding support to re-writing
field references and method invocation is probably easier, because
it is more obvious what needs to be changed:  It basically needs to
be done when the tree nodes are generated.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00   ` Paul Fisher
  2000-04-01  0:00   ` Jochen Hoenicke
@ 2000-04-01  0:00   ` Bernd Kreimeier
  2000-04-01  0:00     ` Per Bothner
  2 siblings, 1 reply; 28+ messages in thread
From: Bernd Kreimeier @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss, classpath

  [Just voicing opinion. I don't contribute, I'd just 
   use (if I can use, that is)]

Per Bothner writes:
 > (1) Is it OK to write Classpath in C++ rather than C? 

As long as portability isn't affected.

 > (2) Is it OK for Classpath to depend on G++ extensions?

Affects portability. Even if G++ is available, a second
compile option is always valuable during development,
especially when depending on an evolving and instable toolchain.

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

How does this address compilation of Java+JNI source
to native code? With or w/o the flexibility of TowerJ?

 > JNI is an Application *Binary* Interface.

It is also an API specification.

 > All we need do is have G++ have an option to generate JNI calls.

If classpath and/or gcj requires CNI, and does not digest
JNI source as is, then it is not the right tool for many
purposes (like mine).

Is the combined classpath+gcj roadmap acknowledging that 
people do use, and will continue to use, JNI? Maybe I am
missing something - I'd appreciate a cnfirmation. I can't
make myself dependend on CNI/gcj, and I suspect I am not
alone.

                                       b.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Proposal for CNI/JNI problems
@ 2000-04-01  0:00 Paul Fisher
  2000-04-01  0:00 ` Per Bothner
  0 siblings, 1 reply; 28+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss; +Cc: classpath

I've been working on coming up with an "acceptable" solution for
dealing with our current merger problems regarding the use of CNI and
JNI.  While it's important that Classpath continue to support JNI, CNI
does have significant benefits, and I'd like to start porting
Classpath to CNI, assuming we can get some sort of sane API mapping
worked out.

In the ideal world, I'd like to be able to write a Java class, mark
appropriate native methods, and then write CNI code.  gcjh would be
able to generate appropriate wrapper code that would translate CNI
calls into JNI calls at runtime.

The process seems to be rather straightforward, with the exception of
accessing fields.  The only fool proof method (that I know of) to
solve the problem is to trap reads and writes to a section of memory
set aside for fields when using JNI.  This would be unacceptably slow.
So I've written a bit of C++ which tries to turn the transparent
access of fields in CNI into something that the compiler can insert
appropriate JNI calls when needed.

Assuming we follow a few rules, we can treat fields as being
"mostly-transparent" and clue the compiler into inserting JNI calls at
appropriate locations.

Where transparency fails:
1) sizeof (field) != sizeof (basic data type)
2) reading/writing directly to the field must occur after the field
   has been "accessed"
3) fields are LocalRefs

Entering a C method when using JNI, would bundle up all the Java
fields into JNIField<type> objects stored in a CNI-like looking
structure.  So a jint field, would turn into a JNIField<jint> field.
JNIFields contain an automatic typecast for their appropriate basic
data type, such that in most cases, the object can be treated as
though it were a basic data type.  Any C++ operators that contain side
effects are overloaded.  JNIFields do not hold the value stored in the
equivalent Java field, until the JNIField is accessed through either
the automatic typecast or one of the overloaded operators.  For any
reading and writing that occurs w.r.t the address of the JNIField
directly, the JNIField destructor compares the initial field value
with the field value held when the current scope exits.

For cases where this transparency isn't good enough (I doubt this
would happen often), we can always just #ifdef out CNI and JNI
versions of a native function.

Assuming these losses are acceptable, I'll continue on with this
project.  Thoughts?

Here's a brief look at the current C++ class that I'm experimenting
with for the basic JNIField:

template<class T>
class JNIField
{
  T val, old_val;

  JNIEnv *env;
  jobject obj;
  jfieldID id;
  char *clazz, *field, *sig;

public:
  JNIField<T> (JNIEnv *env, jobject obj, 
	       char *clazz, char *field, char *sig);
  ~JNIField ();

  operator T();

  JNIField<T>& operator = (const T);
  JNIField<T>& operator += (const T);
  JNIField<T>& operator -= (const T);
  JNIField<T>& operator *= (const T);
  JNIField<T>& operator /= (const T);
  
  JNIField<T>& operator %= (const T);
  JNIField<T>& operator ^= (const T);
  JNIField<T>& operator &= (const T);
  JNIField<T>& operator |= (const T);
  JNIField<T>& operator >>= (const T);
  JNIField<T>& operator <<= (const T);

  const JNIField<T>& operator++ ();
  const JNIField<T>  operator++ (int);
  const JNIField<T>& operator-- ();
  const JNIField<T>  operator-- (int);

  void resolve_field ();
  void set_field (T new_val);
  T get_field ();
};

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00       ` Stuart Ballard
@ 2000-04-01  0:00         ` Chris Blizzard
  2000-04-01  0:00           ` Chris Blizzard
  0 siblings, 1 reply; 28+ messages in thread
From: Chris Blizzard @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Stuart Ballard; +Cc: Aaron M. Renn, Paul Fisher, java-discuss, classpath

Stuart Ballard wrote:
> 
> "Aaron M. Renn" wrote:
> >
> > Paul Fisher (pnfisher@redhat.com) wrote:
> > > > (1) Is it OK to write Classpath in C++ rather than C?
> > >
> > > Yes.
> 
> I don't see a problem with this. After all, Mozilla does this and is
> still extremely portable. We should be careful about using some of the
> less widely-deployed features, though, just as Moz is.
> 

If you want to do this you might want to look at the C++ portability
guidelines that Mozilla has in place.  These rules are a result of many years
of pain at Netscape porting their code base to 20 some-odd platforms.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
If a kid asks where rain comes from, I think a cute thing to tell
him is "God is crying." And if he asks why God is crying, another
cute thing to tell him is "Probably because of something you did."
------------

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 ` Aaron M. Renn
@ 2000-04-01  0:00   ` Brian Jones
  0 siblings, 0 replies; 28+ messages in thread
From: Brian Jones @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Aaron M. Renn; +Cc: Lam.Mark, classpath, Paul Fisher, java-discuss

"Aaron M. Renn" <arenn@urbanophile.com> writes:

> > configurer.  I may be missing the point, but could someone in the know
> > please clarify this?  Thanks.
>  
> Classpath (and many if not most Unix free software packages) relies on 
> GNU autoconf to configure itself for compilation.  Kaffe and Japhar also
> rely on this, and libgjc too I suspect.  I'm not sure how well these tools
> work on Windows or other platforms or how every package handles these
> non-Unix like platforms.  Anybody with real life examples?  (I know many
> GNU tools have been ported to Win)
> 

On Windows you can use cygwin in order to gain some sort of familiar
compiler environment with autoconf, automake, bash, gcc, g++, etc.  I
use cygwin extensively at work... without it I wouldn't work where I
do.  I just haven't had the time to finish installing it at home and
porting classpath to it, if it can be called porting because I don't
think it will take much effort...assuming libtool works anyway...

See http://sourceware.cygnus.com/

Brian
-- 
Brian Jones <cbj@gnu.org>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 David Pettersson
@ 2000-04-01  0:00 ` Per Bothner
  0 siblings, 0 replies; 28+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: David Pettersson; +Cc: java-discuss

David Pettersson <dapet@mai.liu.se> writes:

> I think there are two problems if JNI C interface is not supported. 

We are talking about the classpath *implementation*, not whether
JNI should be supported.  There are two separate issues:

(1) Supporting JNI code written in C.  such code can be compiled with
any C compiler, resulting an object file using the JNI ABI.
Implementing JNI is a task that needs to be supported by JVM run-time.
(Gcj will probably also use compile-/link-time tools to implement
JNI.)

(2) Writing libraries that can be invoked using either JNI or CNI.
This requires conditional compilation and/or a smart compiler.
Using pure conditional compilation would allow full portability to
any JVM and C/C++ compiler.  However, it becomes very tedious and
ugly, and you give up the simplicity of CNI.  An alternative is
some kind of pre-processor.  The ultimate pre-processor is
G++, which is what I suggested.  It allows libraries to maintain
(most of) the simplicity of CNI, while still producing code that
is binary compatible with JVMs that only understand JNI.

The discussion is about (2).

> Classpath will not be able to compile with other C compilers.

True.

> Classes that use JNI can not be used with gcc/gcj.

False.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
@ 2000-04-01  0:00 David Pettersson
  2000-04-01  0:00 ` Per Bothner
  0 siblings, 1 reply; 28+ messages in thread
From: David Pettersson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi,

I think there are two problems if JNI C interface is not supported. 

Classpath will not be able to compile with other C compilers.
Classes that use JNI can not be used with gcc/gcj.

David.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: Proposal for CNI/JNI problems
@ 2000-04-01  0:00 Boehm, Hans
  0 siblings, 0 replies; 28+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Aaron M. Renn', Paul Fisher; +Cc: java-discuss, classpath

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/

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Proposal for CNI/JNI problems
  2000-04-01  0:00 Lam.Mark
@ 2000-04-01  0:00 ` Aaron M. Renn
  2000-04-01  0:00   ` Brian Jones
  0 siblings, 1 reply; 28+ messages in thread
From: Aaron M. Renn @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Lam.Mark; +Cc: classpath, Paul Fisher, java-discuss

Lam.Mark (LamM@intgame.com) wrote:
> >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.
> 
> Pardon me, but isn't depending on a configure time option simply shifting
> the dependency from gcc to the configurer?  I work on Win32 systems, and in
> my case, a C++ compiler is readily available but I have difficulty finding a
> configurer.  I may be missing the point, but could someone in the know
> please clarify this?  Thanks.
 
Classpath (and many if not most Unix free software packages) relies on 
GNU autoconf to configure itself for compilation.  Kaffe and Japhar also
rely on this, and libgjc too I suspect.  I'm not sure how well these tools
work on Windows or other platforms or how every package handles these
non-Unix like platforms.  Anybody with real life examples?  (I know many
GNU tools have been ported to Win)

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: Proposal for CNI/JNI problems
@ 2000-04-01  0:00 Lam.Mark
  2000-04-01  0:00 ` Aaron M. Renn
  0 siblings, 1 reply; 28+ messages in thread
From: Lam.Mark @ 2000-04-01  0:00 UTC (permalink / raw)
  To: classpath, 'Aaron M. Renn', Paul Fisher; +Cc: java-discuss

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

Pardon me, but isn't depending on a configure time option simply shifting
the dependency from gcc to the configurer?  I work on Win32 systems, and in
my case, a C++ compiler is readily available but I have difficulty finding a
configurer.  I may be missing the point, but could someone in the know
please clarify this?  Thanks.

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Proposal for CNI/JNI problems Paul Fisher
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     ` 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   ` Jochen Hoenicke
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   ` 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
  -- 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

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