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,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Received on 2018-05-18 04:27:31 CEST