Name: krT82822 Date: 10/10/99


The behavior of 'javah -jni' has been changed in 1.2.
E.g.
package a;
class C { native void m() }

In 1.1. it was not possible to do 'javah -jni C', only the
correct 'javah -jni a.C' worked.
1.2 also accepts the wrong 'javah -jni C' and generates a
bogus header file. We have received some bug reports for
the Linux JDK (the problem itself is platform independent)
about runtime linking problems that traced down to this problem.
IMO javah should check if the given classname is the same as
in the .class file, i.e. javah should check if it was given
a fully qualified classname.

--------------

10/10/99 eval1127@eng -- under 1.1.x, if you compile C with no "-d .", C.class ends up (predictably) in the current dir, BUT javah will complain if
you try to run "javah -jni C".

Under Java2, using "javac C.java" results in a C.class file in ".", and javap appropriately complains that it does not contain C. However, javah -jni C silently
"works", creates C.h in ".", and eats the package name.

class C {

       public native void m();
}

( 67 )% java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-I)
Java HotSpot (TM) Client VM (build 1.3-I, interpreted mode)
( 68 )% javac C.java
( 69 )% javap C
Error: Binary file 'C' contains a.C
( 70 )% javah -jni C
( 71 )% cat C.h
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class C */

#ifndef _Included_C
#define _Included_C
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class: C
 * Method: m
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_C_m
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif


(Review ID: 96012)
======================================================================

Name: jl125535 Date: 11/19/2003


I suggest javah should complain that the class could not be found.

(Review ID: 217249)
======================================================================