On Fri, May 4, 2018 at 8:49 AM, Branko Čibej <br...@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/