Skip to content
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

Closed
wltjr opened this issue Jan 6, 2018 · 3 comments
Closed

Functions.java needs annotation for java 9+ javac -h vs javah #902

wltjr opened this issue Jan 6, 2018 · 3 comments

Comments

@wltjr
Copy link

wltjr commented Jan 6, 2018

  1. 4.5.1/GIT
  2. Oracle JDK 9.0.1 (there is no javah on EA 10)
  3. Gentoo Linux
  4. amd64/64bit
  5. If I do 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.
  6. Steps to reproduce
    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."

@matthiasblaesing
Copy link
Member

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.

@matthiasblaesing
Copy link
Member

Oh - and if you want to look into fixing the build system to be compatible with jdk8 - 10, the work would be appreciated.

@wltjr
Copy link
Author

wltjr commented Jan 6, 2018

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.

matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Mar 24, 2018
matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Mar 24, 2018
matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Mar 24, 2018
matthiasblaesing added a commit to matthiasblaesing/jna that referenced this issue Apr 25, 2018
… 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
idosu pushed a commit to idosu/jna that referenced this issue May 8, 2018
… 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants