Re: Duplicate JNI files.

[Etienne M. Gagnon]

On Fri, Sep 07, 2001 at 09:05:54PM -0400, Brian Jones wrote:
> 
> 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.

The downloadable 0.1.6 version does (with sablepath, which is a pretty 
straitfoward
packaging of Classpath).  The upcoming version should work too.

In fact, SableVM's JNI implementation should allow you to use *.so libs compiled
right out of Classpath.  [I haven't tried it because of the difficulty of
building Classpath without Japhar].

> No big deal, see above.

So, is there any reason no to get rid of the moved files [cvs remove]?

> > bigint
> > cpgdkpixbuf
> > gtkpeer
> > javaio
> > javalang
> > javalangmath
> > javanet
> > javautil
> > runtime
> 
> I'm not fond of these names.

I'm not, either.  So why not:
a) One *.so per "java package"
b) Call them: libxxx.so where xxx is the package name in JNI notation, e.g.
   java_util, gnu_java_awt_peer, etc.

This requires minor changes in the .java files.

Also, why don't you also make sure that ALL .java classes with native methods
also have a System.loadLibrary call in a static block?

> > One initial comment:  The 'System.loadLibrary ("runtime");' in
> > java/lang/Throwable.java makes no sense 
> 
> No idea, I probably didn't write it.

How about getting rid of the static block?  Thanks :)

> I do not believe we've ever had one, and BigInteger doesn't work
> obviously.  :)

I'm all for the libgcj all java version :)

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

This is an excellent read :)  You can look at SableVM's code, if you want a
look under the hood...  [You shouldn't "need" to look, as JNI was meant as a 
black
box].


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

SableVM's jni.h has NO hardcoded non portable bits (at least my working version
which is not yet in CVS, but I can send it to this list, if you want.  It is
in the public domain).  It has a dependency on a jni-systemspecific.h which
contains the very few system specific definitions.  You could probably
work out the auto* magic to compute them dynamically, or it is very simple
to simply add the definitions for a new platform (all you need is to
define things like signed 32 bit int, 32 bit float, etc.).

It has one conditional on "_SableVM" which provides incomplete types
for non SableVM inclusion.  I can redefine this as "_VM" if you prefer.
The idea is that some opaque types should be defined differently if
you use jni.h to implement a VM than if you include it in "user code".
I simply didn't want to maintain two distinct jni.h files.

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

All this is nice.  So, how about NOT generating the javah stuff as part
of the build?  This stuff only need regeneration when people add/remove/
modify "native method declarations" in java code.  We could provide a
script to do this when needed (or make it an "optional" hand coded
target in the root Makefile.am, like I do with "indent" [see Sablepath,
downloadable version].

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

I'm a lottle late on the sablepath-libs demo; you don't know all that
can happen on a Friday as a professor;-)  It's coming along, though.

> 
> Brian


Thanks!

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