Add annotations for Java 10+ javac -h for native headers #943
Conversation
|
Thank you for looking into this - these are some random thoughts:
|
|
|
I gave solaris as a sample. We are running machines are work, that use java 1.5. Am I proud of it? No, but I have to live with it. So I know why backwards-compatibility is important. |
|
Just because you are stuck in the past does not mean projects should be. Also why do you need to use newer versions of JNA? Why are you pushing your legacy needs on the world? Java is clearly moving forward much faster. Others need to adapt or be left behind. But that is no reason to hold back projects. I am trying to get things working on current JDK 10 and future JDKs. You want to prevent that for legacy purposes. Or waste time with conditionals supporting older code vs updating the older code. Which you will have to someday... If you are on legacy Java versions, I do not see why you need updated libraries. You have other vulnerabilities, bugs, etc in the core that will not be fixed nor addressed. That is very strange to be updating libraries and not the core. That entire scenario does not make sense, why still on 1.5, why using newer libraries with older jdk, etc. Need to revisit both development and deployment practices. Sorry but IMHO none are valid reasons to hold JNA back. You may need to back port things for your purposes and allow the project to move forward. While you remain in the past. |
|
FYI I still have clients running code I did back in 1.4 days. It builds fine under 11... I packaged hundreds of java packages. Very few require older JDKs and I consider that bad coding. If your code requires a specific JDK and prevents you from moving to newer JDK your writing bad code. Your developers are not forward looking, and that whole scenario needs to change. Not impose such needs on others. Many are going to have serious growing pains with Java going forward. As they learn to stop requiring legacy support and start being more adaptable and allow things to move at a faster pace. |
|
I did not require you to stay in the past - I asked you to put into work not to break support for older JDKs. You did not even consider this. I'm fine if you want to rush into the future, but my usecase is different - if you can't respect this, fine with me, then my review ends at this point and I'll focus on fixing bugs. For you allegation, that I decided to run java 1.5: My boss decided that and I have to live with that decision. The JVM is embedded into a third-party product, that is way past its support time. You don't have to face these issues: consider yourself lucky. |
|
My interest is clearly in moving things forward, not legacy support. If your interest in legacy support, then you could look to make any such modifications. Not request others spend their time on your needs, which contradict their needs. Your use case is different than mine. IMHO you should spend your time for your legacy needs. My needs are for current and future versions of Java. Thus my efforts. I am not rushing into the future... Java is clearly... Guess you missed the memo... What is the current JDK? 10... how is that the future? This is the present... Your the one living in the past, way in the past.... Everyone has long EOL 1.5, and very few if any support 1.6 for much longer, and that is paid support. So I guess JNA cannot be fixed for current JDK 10, because of others legacy needs for support < 8. Without any such means to address the issue for both without different code bases, modifying files on the fly etc. There is no clean way to move forward and support legacy. There has to be a trade off, and IMHO it is dropping legacy support. JNA should build under current JDK which is 10. |
|
Just noticed in #902 (comment) it was mentioned to make things compatible for 8-10, with no mention of need to support < 8. |
… 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
Modifications per #902
|
Closing in favor of #945 due to lack of changes to build system. These were the only changes required for my needs. |
… 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
… 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
Initial modifications for Java 10+
javac -hsincejavahwas removed starting with Java 10 now released per issue #902. I am good with the annotations. I am NOT ok with the FIXME code in there. That was the ONLY way I could find to generate the header files for those classes. I had to introduce a variable in both classes and interfaces, so I could add the annotations. I do not like adding unused variables....However that did generate the header files for the methods exactly as javah did before. The exception is the interfaces. Since I could not make those variables private, those variables show up in the header files, unlike javah. With these modifications, if you do
javahwith < 10, and then dojavac -hwith 9, 10, or 11. The output is the same except the following. A and B are folders,javahis outputted to A,javac -hfrom 11 in B. You can see the only difference is the header files for interfaces due to unused variable being public.Now if the header files for the interfaces are not needed. Then it is a bit better. Still have unused private variables. Seems no other means to mark the class for native generation. Maybe a bug to be fixed in java 11? Likely to late for Java 10. Seems like interfaces and classes need to be able to be marked as Native via annotation or modifier/keyword.
Seems like there should be a better way.
javahremoval seems premature withjavac -hnot having full replacement abilities.@java.lang.annotation.Native@java.lang.annotation.Native