-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functions.java needs annotation for java 9+ javac -h vs javah #902
Comments
Thank you for the heads up. At this point for master the required build JDK is 8 or 9 (4.X will only support jdk8). It is still unclear how oracle/openJDK will handle target/source versions in the javac compiler post java 9 with the increased release schedule. |
Oh - and if you want to look into fixing the build system to be compatible with jdk8 - 10, the work would be appreciated. |
I will see about making the needed changes and submitting a PR. Mostly wanted to document it in case I forget and its on another's radar. I assume it mostly needs annotations vs inheriting any native classes. Just have to see the differences in what it produces. Make sure annotated Function.java using javc -h produces the same header file that would be with javah. Seems the same thus far with Native.java. Regarding source/target. Those are pretty much legacy replaced by --release. To use --source/target properly you need older rt.jar to link against for bootclasspath. I think they want to get away from that and it is not necessary with --release. Bootclasspath was never handled correctly on gentoo, and all source/target usage is incorrect, if set to anything but the version of JDK used for compile. Otherwise you link against newer methods etc that may not exist in older rt.jar and have issues. Though --release I do not believe is 100% the same as source/target not sure. I know some stuff that requires tools.jar and other classes in 9+ requires like --add-modules --add-exports. Which does not work with --release. I do not believe you can use --add stuff with source/target. If you can likely need older rt.jar. As those do not handle the bootclasspath issue as --release does. I haven't read anything about source/target going away but seems like eventually they maybe replaced by release. Not sure having an older source with newer target makes sense. Usually if using a older source would want an older target. I could maybe see newer source for older target. Most times they will be set to the same for anything < current JDK. Thus seems --release makes more sense long term. Hard to say till say 11 is out. I have 10 EA now, but haven't had a chance to start with that. Still working on making sure everything is good to go for 9. I think by February at latest I will be testing and onto 10. So I am ready come March 1st. I was behind the gun on Java 9. Seems many are in the same boat. Though we had lots of heads up as to what was coming. :) Anyway if no one else does this. By the time I get to 10 stuff, I will have no choice to fix as there is no javah. Which I am using temporarily for now. |
… version is 6) Closes: java-native-access#902 Closes: java-native-access#943
… version is 6) Closes: java-native-access#902 Closes: java-native-access#943
… version is 6) Closes: java-native-access#902 Closes: java-native-access#943
… version is 6) - Support for JDK 10 requires removal of usage of javah, which was replaced by the javac of JDK8, which can generate headers while processing the java classes (bumping the minimum build JDK to 8) - A new build target "native-build-package" was introduced, to create a zip file with the files necessary to build the native libraries, only requireing the JDK present on the build system, but can be an older JDK. Properties to select the build.os.name, build.os.arch and build.os.endianess were added to allow cross-system generation of the build package - the native Makefile is not modified by the build.xml anymore, as the two parameters JNA_JNI_VERSION and CHECKSUM are already passed in via command line parameters - Support for "-d32" and "-d64" datamodel selectors was removed as it was only needed for solaris and JDK8 (minimum build JDK) on solaris only supports 64 bit Closes: java-native-access#902 Closes: java-native-access#943
… version is 6) - Support for JDK 10 requires removal of usage of javah, which was replaced by the javac of JDK8, which can generate headers while processing the java classes (bumping the minimum build JDK to 8) - A new build target "native-build-package" was introduced, to create a zip file with the files necessary to build the native libraries, only requireing the JDK present on the build system, but can be an older JDK. Properties to select the build.os.name, build.os.arch and build.os.endianess were added to allow cross-system generation of the build package - the native Makefile is not modified by the build.xml anymore, as the two parameters JNA_JNI_VERSION and CHECKSUM are already passed in via command line parameters - Support for "-d32" and "-d64" datamodel selectors was removed as it was only needed for solaris and JDK8 (minimum build JDK) on solaris only supports 64 bit Closes: java-native-access#902 Closes: java-native-access#943
javac -h
on Functions.java I get no output. I do not get generated C/jni headers for Functions.java. I do get generated headers from Native.java. Its either a bug in javac -h handling, and/or Functions.java needs annotations since not inheriting Native stuff that triggers generation of headers in Java 9+. For the time being using javah in Java 9 for Funtions.java, but javah is no longer as of EA 10. Thus need to fix Functions.java to work with 9+ javac -h.a. Install JDK 9+
b.
javac -h -cp jna.jar com/sun/jna/Function.java
c. No headers are generated
Repeat A & B using Native.java you get generated headers.
Seems to be either not having annotations or not containing native methods. Something causes Native.java to generate its headers, and prevents Function.java's headers from being generated. The following command only works for Native.java. Using javah on the same works for both.
Does not generate com_sun_jna_Function.h but does generate com_sun_jna_Native.h
javac -h native -cp ${PN}.jar src/com/sun/jna/{Function,Native}.java
Generates both via legacy javah
javah -d native -cp ${PN}.jar com.sun.jna.{Function,Native}
From Java 9 javac man page
"-h directory
Specifies where to place generated native header files.
When you specify this option, a native header file is generated for each class that contains native methods or that has one or more constants annotated with the java.lang.annotation.Native annotation."
The text was updated successfully, but these errors were encountered: