We should deprecate Javah, this is a small task, but still worth doing.
Comments
Strong encapsulation makes one wonder about accessing the native headers of the implementation of other modules, but setting that aside, there are various possibilities here:
1. The build for modules that want to expose their native headers should publish those native headers.
2. Recompile the appropriate classes using -Xmodule:<module> -- this assumes you have access to the java source
3. javac RFE: provide a javac way of generating headers from class files -- this is problematic since the current definition of @Native is @Retention(SOURCE)
16-09-2016
I ran into an edge case trying to remove javah from the JFX build. It would seem that using 'javac -h' folds pretty cleanly into our build, and removes one extra build step. (I did have to annotate a number of our java classes with @Native for this to work which is OK).
Except for this remaining use case in javafx.web.
$JIGSAW_HOME/bin/javah \
-d headers \
java.lang.Character \
java.net.IDN
If javah is to be removed, there needs to be a solution to generate headers for classes that are not in the build. For example, neither of these classes are in the JFX build, and I can foresee situations where customers want to build on other "existing" classes in the module tree/classpath.
16-09-2016
javah -h can stay, javah -d => javac -h
-jni can be a no-op
-force -- need to investigate -- the default is not to overwrite files unnecessarily to avoid triggering C compilations because .h files have been rewritten
obviously all -*path opts map to javac equivalents
02-01-2014
javah does not map trivially onto javac -h, since javac -h is just "the useful subset" of javah.
But that being said, we could arrange for javac JNIWriter to be a class that can be reused by javah. javah will not end up being extremely trivial, but can still be a simple wrapper around functionality of JNIWriter.
FWIW, JNIWriter was a cut-n-paste of javah Gen.
02-01-2014
Comparing the options of javah with javac,
-o <file> Output file (only one of -d or -o may be used) // does not exist in javac, support/eliminate ?
-v -verbose Enable verbose output // -v support/eliminate?
-h --help -? Print this message // -h is javah in javac, eliminate ?
-version Print version information // OK
-jni Generate JNI-style header file (default) // should we support/eliminate?
-force Always write output files // eliminate
-classpath <path> Path from which to load classes // OK
-cp <path> Path from which to load classes // OK
-bootclasspath <path> Path from which to load bootstrap classes // OK
There also command line behavioral differences between javah and javac -h
ex: javac -h out Foo.java vs. javah Foo -d out
27-12-2013
This feature is about changing the implementation of javah, instead of calling com.sun.tools.javah under the hood, the javah command line tool should call com.sun.tools.javac -h
19-11-2013
Reviewed and accepted by Georges and Mark, should be assigned to someone and JEP should be submitted to socialize the removal of the command line tool.