[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Duplicate JNI files.
Etienne M. Gagnon
Re: Duplicate JNI files.
Fri, 7 Sep 2001 10:19:53 -0400
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
The good news is that Double.c is the only file which has had this problem
so far (old copy modified).
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
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,
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):
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:
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
Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/