Re: JDK 10 removal of javah

On Fri, May 4, 2018 at 8:49 AM, Branko Čibej <brane_at_apache.org> wrote:

> On 04.05.2018 14:12, 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.
> >
> > Is it acceptable to bump our minimum Java version for building (and
> > runtime?) to 8? I know we could still build for older Java versions
> > while using newer toolchain, but even that has been emitting deprecation
> > notices:
> >
> > /usr/lib/jvm/default-java/bin/javac -target 1.6 -source 1.6 …
> > warning: [options] bootstrap class path not set in conjunction with
> -source 1.6
> > warning: [options] source value 1.6 is obsolete and will be removed in a
> future release
> > warning: [options] target value 1.6 is obsolete and will be removed in a
> future release
> >
> > If we're fine with bumping up to Java 8, is that something we'd be
> > willing to backport to 1.10 or would we need to add detection for what
> > toolchain is being used?
>
> We use the -source and -target options to at least marginally make sure
> that we don't use language features that aren't available in the
> supported Java versions (although, without the bootstrap classpath
> option, that's probably not a good enough guarantee).
>
> In any case, it appears that Java 6 and 7 are obsolete. If that's indeed
> the case, I have no objection to making Java 8 our minimum required
> version for JavaHL, especially if that means we can avoid supporting two
> different build modes ('javah' vs. 'javac -h'). Also, if headers will be
> generated as part of the Java source compilation, we may be able to
> finally enable parallel builds for JavaHL on Unix.
>
>

I am fine with requiring Java8. For Subclipse, Eclipse pretty much made
this a requirement a long time ago and I have lost interest in trying to
support really old versions still. If someone has a hard requirement on
Java 6/7 I just cannot envision the story of why they also need or care
about SVN 1.10+ or why we need to cater to them.

So +1 from me.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/