On 5/4/2018 2:49 PM, Branko Čibej 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.
-- Brane
FTR: Java SE public updates are EOL for Java 6 and 7 already (last
public update for Java SE 6 was update 45 on 2013-10-15 [2] / for Java 7
it was update 80 on 2015-04-14 [3]). Special to Java 8-11 is that Java 9
also no longer receives free public updates (as of March 2018) while
Java 8 still does (until January 2019 for commercial and December 2020
for non-commercial use) with Java 10 being actually the "rebranding" of
Java 9 which is going to receive public free updates (commercial and
non-commercial) till September 2018. [1] Java 11 has been declared the
next LTS release of Java (to be released in September 2018 - extended
support will be provided till at least September 2026).
Note that for paid commercial support all versions including Java 6
still receive extended support (Java 6 till December 2018) and are being
supported (sustaining support) indefinitely.
Since I'm not too involved in the java world, I won't make any
suggestions here, but my feeling would be that we'd still keep Java 6/7
support for 1.10.x and raise the Java support to Java 8+ or maybe even
Java 11+ for SVN 1.11.x based on when we'll ship that version.
[1] = http://www.oracle.com/technetwork/java/eol-135779.html
[2] = https://en.wikipedia.org/wiki/Java_version_history#Java_6_updates
[3] = https://en.wikipedia.org/wiki/Java_version_history#Java_7_updates
--
Regards,
Stefan Hett
