Re: Duplicate JNI files.

[Brian Jones]

"Etienne M. Gagnon" <address@hidden> writes:

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

The fix didn't matter much, since we're using the gcj method to create
strings (or will be... can't remember).  This is a piece of code I
changed that I'd love to test but I need a VM that works with our JNI
libs.  Perhaps SableVM would do.

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

No big deal, see above.

> The good news is that Double.c is the only file which has had this problem
> so far (old copy modified).
>
> 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").

Hmm, ok.

> 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

I'm not fond of these names.
 
> One initial comment:  The 'System.loadLibrary ("runtime");' in
> java/lang/Throwable.java makes no sense 

No idea, I probably didn't write it.

> 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 do not believe we've ever had one, and BigInteger doesn't work
obviously.  :)

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

Yes.  I bought the JNI book (from Sun) a couple of months ago and they
include a Windows example of how to compile/link/code generically, but
briefly.


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

I think the jni.h file (this is what you're talking about, right?)
should probably be generated based on the target of the build.  This
way it properly takes advantage of what is or isn't there in hardware.

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

I'm almost done eith a full javap replacement that uses GNU bytecode.
Writing javah is trivial as well with this package and I'll do it
soon.  Getting the decompilation to java assembly to display as I want
(just as Sun's javap does) has proven tricky.

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

That's fine.  My cable modem has been flaky all week (experiencing
more than 50% packet loss) and sometimes down.  I'll remove the files
shortly.

Brian
-- 
Brian Jones <address@hidden>