Re: Classpath build process and VM-specific issues

[Etienne Gagnon]

On Wed, Apr 07, 2004 at 11:19:47AM +0100, Andrew Haley wrote:
>  > "jbyte" must have a single platform-specific definition, as all
>  > JVMs on that platform should be able to execute the same JNI
>  > library code (no recompilation required).
> 
> I didn't know that.  Is that requirement documented anywhere?  I can't
> see how you'd do it on a machine with 32-bit and 64-bit modes, for
> example.  Do we know that every JVM will use the same calling
> convention for CNI?

CNI is a gcj-specific thing, so gcj can do whatever they like...

As for JNI, yes it is a requirement.  JNI was *specifically*
developed to get rid of the multiple VM-specific native interfaces
that were developed in early Java implementations (Sun's, Netscape's,
Microsoft's).

In the JNI specification (e.g. chapters 11 to 13 of ISBN 0-201-32577-2
"The Java Native Interface, Programmer's Guide and Specification), you
find the following text:

  11.1 Design Goals

  The most important goal of the JNI design is ensuring that it offers
  binary compatibility among different Java virtual machine
  implementations on a given host environment. The same native library
  binary will run on different virtual machine implementations on a
  given host environment without the need for recompilation.


>  > /* test function (unused).  This function will cause a compiler
>  >  * warning when jbyte != signed char */
> 
> Maybe, maybe not.  Is this guaranteed by the standard to cause a
> warning?

Do we really care?  I think that it is sufficient to clearly document
the requirement to define or not JBYTE_IS_NOT_SIGNED_CHAR
appropriately.  We both probably know very few platforms (I know of
none, but I don't currently work on embedded processors...) that do
not have 8-bit bytes (=> chars).

This function is simply an appropriate test to add to a configure
script in a GNU environment, for the programmer's convenience *only*.

>  >   /* make a robust integer out of pointer value */
>  >   ptrdiff_t value = (char *) ptr - (char *) 0;
> 
> Don't do this subtraction, it isn't portable.  Use intptr_t instead.

ANSI/ISO 9899-1990 (the old standard, I guess) does not have intptr_t.

> And a little stylistic nit: it isn't a good idea to cat return values
> from malloc().


"cat"?  What do you mean?  [I know the example JNI code should have
checked that malloc() had actually succeeded.  And the code has a
memory leak, as the malloc()ed memory isn't freed, but this code was
simply meant as a test for wrapping/unwrapping native pointer...
Writing robust and portable C code is painful. ;-)]


Etienne

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