From: ###@###.### (Steve Schoettler)
This does not look like form output to me.



Summary: javah generates long return value in stub file even if return value
is short
Result: the java program gets garbage data back from the native method
Workaround: edit the stub file to change long to short, or change the java
declaration so the native method returns int
Platform: Windows NT 3.51/Intel, using JDK 1.0, and the Visual C++ 4.0 tools.

If the java source says
  public native short getType()

The javah generated .h file says:
  _declspec(dllexport) short H..._getType(...)

The javah generated .c stub file says:
  extern long H..._getType(...)

If the native C implementation of the getType function is defined
  long H..._getType(...)
then you get a linker error (functions differ by only return type)

If the native C implementation is defined
  short H..._getType(...)
then there are no compile or link errors, but the java program doesn't
return the correct value.

If you hand-edit the javah-generated .c stub file to say
  extern short H..._getType(...)
and recompile then everything works fine.

So, I looked in src/win32/java/main/javah.c, version 1.19, and sure enough
there's a big switch statement that combines a bunch of types and outputs
"extern long" (line 760) into the .c stub file, whereas the .h file
generating code has a specific case for short (line 212). I could see how
this might be a problem for little-endian machines like Intel and not for
other platforms.

This could be a bug for some of the other types in the switch statement
(boolean, byte, short, char), but I haven't tested those.

Steve Schoettler
B Mobile
###@###.###