Re: Duplicate JNI files.

[Etienne M. Gagnon]

On Fri, Sep 07, 2001 at 09:03:27AM -0400, Brian Jones wrote:
> I haven't deleted the old native/java.* things yet.  Things were moved
> to make room for a "cni" directory at the same level as the "jni"
> directory.  I asked about putting all of them in one directory and
> agreement was that would be fine.  I have no problem with splitting
> them up either... it doesn't matter for automake/autoconf which way it
> is done.

OK, this confirms my guess that the newer stuff is in native/jni.

I. COPY VS MOVE --> Consequences & solutions

The problem with "moving without deleting" is one of consistency.  You
probably didn't notice the following ChangeLog entry that happened
AFTER you "moved" native/java.lang/Double.c to native/jni/java_lang_Double.c :

2001-04-20  J. Russell Smyth  <address@hidden>
...
        * native/java.lang/Double.c (toString): Corrected format
        specifiers for sprintf call to give better precision.
                                                

Which means that, currently, there is a bugfix in native/java.lang/Double.c
which has not been applied to native/jni/java_lang_Double.c.  To make it
worse, native/jni/java_lang_Double.c has also been modified since the
move.

The good news is that Double.c is the only file which has had this problem
so far (old copy modified).

Solution
--------
For this reason, I urge you to "cvs -f remove" all "moved files".  
(Personally I prefer to say "copied files" when the original copy
is left in place).

As for the Double.c problem, you could use cvs diff to extract a patch of
the modification made by Russell Smyth, then apply this patch to the
newer copy.  Then I would "cvs -f remove" the old copy along all other
moved files.

II.  About the native/jni organization (and some inconsistencies)

I agree that to the auto* tools, the organization of native/jni doesn't
matter much.  But for my poor human brain, and for "simple brain-dead
yet useful" utility scripts, it can make a bigger difference.  ;)

So, what I propose is an "intuitive" organization of these directories.
Mainly, what I see is one directory per "libxxx.so" library, where the
directory name is "xxx", matching the name found in Java source files,
e.g. System.loadLibrary("xxx").

Now (back to my brain-dead scripts), I have a little script that effectively
goes through the Java sources, and it tells me that the following libraries
are loaded from Java code (I exclude all the test stuff):

bigint
cpgdkpixbuf
gtkpeer
javaio
javalang
javalangmath
javanet
javautil
runtime

One initial comment:  The 'System.loadLibrary ("runtime");' in
java/lang/Throwable.java makes no sense (and the whole static block
should be removed).  This is because "runtime" represents the VM, which
is obviously running and "available as a library" at the time of this
call!  If you think a little about it, you'll notice that "loadLibrary"
itself is a native method (or it necessarily calls one) of class
System.  Q: Wouldn't you expect System to have a static initializer
calling "loadLibrary" so that the native "loadLibrary" method can be
successfully linked? va.lang.System?  (chicken/egg)


So, let's get rid of "runtime".  We are now left with:

native/jni/bigint
native/jni/cpgdkpixbuf
...

You'll see that there is no "native/jni/javalangreflect".  This is
because I definitely think that the "test" stuff should be put
apart, in its own directories, and be kept completely optional.

Also, you'll notice that the current Classpath "native/jni" code
does not build the "libbigint.so" library, even though it is required
by the Java source code...  [Thanks to brain-dead scripts, finding
such things can be easy;-)]

I definitely think that this whole JNI stuff should be buildable
without ANY dependency on a VM.  All you need is a "plain" JNI
definitions file.  [SableVM's definition file has been written
with that in mind, and is released into the "Public Domain".  Do
you want it?].  In fact, this was the primary objective of the
JNI designers: no VM dependency whatsoever for compiling the stuff.

A little later today, I will let you know when sablepath-libs is
ready, so that you see how one can build the native libraries
without any vm dependency.

Obviously, there are some consequences to breaking the libraries
into "java" / "native" code.  One of them is that the generation
of JNI header files is now "semi-automatic".  You first build
/ install the java classes, then you run a simple script that
regenerates the JNI header files.  You store the generated
header files into CVS and distribution packages.  As not every
VM already has a "javah" like tool, you remove, by doing so,
an artificial build dependency on specific VMs, or even
proprietary tools ["javah"].  (In fact, one could write a
Java based tool to emulate "javah".  As long as one is able to
run an "older" version of his VM, he will be able to work
in a completely Free environment).

So, Brian, does this sounds as a good  organization the native/jni
sources?

Have fun!

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/