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
Received on 2018-05-04 16:27:30 CEST