Hi James,
Whatever you do, please keep backward compatibility with older JDKs.
Reason is building on older OS X machines for most compatibility which
do not allow latest JDKs.
Thanks for considering.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog
On 2018-05-18 4:27, James McCoy wrote:
On Fri, May 04, 2018 at 08:12:29AM -0400, James McCoy wrote:
On Sat, Dec 23, 2017 at 06:44:13PM +0100, Branko Čibej wrote:
On 23.12.2017 16:30, Andreas Stieger wrote:
Hello,
I was made aware by our Java package maintainer of the fact that JDK 10
is removing the javah tool, after the deprecation from JDK 8. Our javahl
stuff no longer builds and apparently the functionality is in javac now.
JEP 313: Remove the Native-Header Generation Tool (javah)
http://openjdk.java.net/jeps/313
Was anyone looking at this?
Not to my knowledge, and patches are always welcome. If javac has the
same functionality, it shouldn't be too hard to tweak the build system.
Java 10 has now hit Debian as default, so I've started looking into
fixing this.
Basically, javac can now be told to generate the headers at the same
time it generates the class files, by adding "-h
subversion/bindings/javahl/include"
to the existing javac calls. However, this only works with Java 8 or
newer.
It's taken longer than I was hoping, but I'll have something for trunk
soon.
The biggest wrinkle is that "javac -h" _only_ generates a header file if
there are native annotations, whereas "javah" would always generate a
header file. This found some places where we didn't have native
annotations even though they were needed.
It also throws a wrench in our dependency tracking. We can't just say
"Hey make, these .java files all generate a .h file, and libsvnjavahl
depends on all the .h files" anymore.
I was initially going to drop the javah type from build.conf. Since it
looks like we'll need to explicitly list the header files we expect to
generate, it will probably be cleaner to use the package-based javah
stanzas instead. That will also keep the dependencies more accurate.
Cheers,
