[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: JDK 10 removal of javah

From: Branko Čibej <brane_at_apache.org>
Date: Fri, 4 May 2018 14:49:51 +0200

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.

-- Brane
Received on 2018-05-04 14:49:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.