Re: JDK 10 removal of javah

[James McCoy <ja...@jamessan.com>]

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?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: JDK 10 removal of javah

[James McCoy <ja...@jamessan.com>]

On Thu, May 17, 2018 at 10:27:18PM -0400, James McCoy wrote:
> The biggest wrinkle is that "javac -h" _only_ generates a header file if
> there are native annotations, whereas "javah" would always generate a
> header file.  This found some places where we didn't have native
> annotations even though they were needed.
> 
> It also throws a wrench in our dependency tracking.  We can't just say
> "Hey make, these .java files all generate a .h file, and libsvnjavahl
> depends on all the .h files" anymore.
> 
> I was initially going to drop the javah type from build.conf.  Since it
> looks like we'll need to explicitly list the header files we expect to
> generate, it will probably be cleaner to use the package-based javah
> stanzas instead.  That will also keep the dependencies more accurate.

I've finally cleaned things up and the attached patch works (for me) on
Linux.  gen_base.py now has one TargetJava class (based mainly on the
old TargetJavaHeaders), which describes how to generate the .class and
optionally .h files.

Since javac only produces header files when the .java file has native
code, build.conf now lists all such files in a "native" attribute to
avoid unsatisfiable dependencies.

I know there is still work to be done for Windows, and I'll need some
help with that.  As I mentioned above, multiple files are generated per
javac command, which our current ezt templates for VisualStudio don't
seem to support.  From some brief searching, the solution files do
appear to handle this, but it's not something I can readily test.

I haven't committed to trunk since I didn't want to break the Windows
builds.  I'm open to suggestions on how to move forward.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

[Branko Čibej <br...@apache.org>]

On 18.05.2018 14:40, Stefan Sperling wrote:
> On Fri, May 18, 2018 at 02:36:06PM +0200, Branko Čibej wrote:
>> On 18.05.2018 14:34, Stefan Sperling wrote:
>>> On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote:
>>>> On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote:
>>>>> Elsewhere in this discussion thread it was suggested to raise the
>>>>> minimum JDK version requirement to Java 1.8.
>>>>> Your statement "please keep backward compatibility with older JDKs"
>>>>> could mean anything between "please leave everything as it is now" to
>>>>> "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
>>>>>
>>>>> This requirement would be introduced for Subversion 1.11.
>>>>> Can you explain which versions of OS X / JDK you expect to support when
>>>>> Subversion 1.11 will be released in probably 2 to 3 years from now?
>>>> No one would be able to build the stable release of Subversion with JDK
>>>> 10 for 2 to 3 years?
>>>>
>>>> Supporting both pre-8 and post-8 JDKs wouldn't be trivial.  I've been
>>>> working under the assumption that we can bump up to JDK 8 and backport
>>>> that change to 1.10.
>>>>
>>>> If that's not going to be the case, should my current work still go to
>>>> trunk?  Then someone can find the time to adapt things to also work with
>>>> pre-8 JDK?
>>> I think you should aim to proceed with your plan as it was.
>>> If anyone has strong objections to this, they should be constructive and
>>> try to provide an alternative solution without pushing an additional
>>> burden on you.
>> Given that Java 6 and 7 are obsolete ... I think it won't hurt to make
>> Java 8 the oldest supported version on the 1.10.x branch.
>> -- Brane
> Yes, I agree.
>
> Sorry for confusing the matter by mentioning 1.11.
> I was just responding to the vaguely worded request from Syntevo and
> I hadn't read the context of this entire discussion thread yet.
>
> We would normally not change minimum dependency versions within a
> stable release branch but this looks like a case where we can make
> a reasonable exception to this rule.

Java 8 is the earliest available for Mac OS from Oracle, unless you
really, really try hard to find Apple's Java 6 installer — which is only
needed for running some seriously obsolete software. The other platforms
where requiring Java 8 /might/ be a problem is the infamous RHEL, which
tends to be years behind the times. However, they have ancient
Subversion as well, so ... pooh.

-- Brane

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

[Stefan Sperling <st...@elego.de>]

On Fri, May 18, 2018 at 02:36:06PM +0200, Branko Čibej wrote:
> On 18.05.2018 14:34, Stefan Sperling wrote:
> > On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote:
> >> On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote:
> >>> Elsewhere in this discussion thread it was suggested to raise the
> >>> minimum JDK version requirement to Java 1.8.
> >>> Your statement "please keep backward compatibility with older JDKs"
> >>> could mean anything between "please leave everything as it is now" to
> >>> "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
> >>>
> >>> This requirement would be introduced for Subversion 1.11.
> >>> Can you explain which versions of OS X / JDK you expect to support when
> >>> Subversion 1.11 will be released in probably 2 to 3 years from now?
> >> No one would be able to build the stable release of Subversion with JDK
> >> 10 for 2 to 3 years?
> >>
> >> Supporting both pre-8 and post-8 JDKs wouldn't be trivial.  I've been
> >> working under the assumption that we can bump up to JDK 8 and backport
> >> that change to 1.10.
> >>
> >> If that's not going to be the case, should my current work still go to
> >> trunk?  Then someone can find the time to adapt things to also work with
> >> pre-8 JDK?
> > I think you should aim to proceed with your plan as it was.
> > If anyone has strong objections to this, they should be constructive and
> > try to provide an alternative solution without pushing an additional
> > burden on you.
> 
> Given that Java 6 and 7 are obsolete ... I think it won't hurt to make
> Java 8 the oldest supported version on the 1.10.x branch.
> -- Brane

Yes, I agree.

Sorry for confusing the matter by mentioning 1.11.
I was just responding to the vaguely worded request from Syntevo and
I hadn't read the context of this entire discussion thread yet.

We would normally not change minimum dependency versions within a
stable release branch but this looks like a case where we can make
a reasonable exception to this rule.

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

[Branko Čibej <br...@apache.org>]

On 18.05.2018 14:34, Stefan Sperling wrote:
> On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote:
>> On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote:
>>> Elsewhere in this discussion thread it was suggested to raise the
>>> minimum JDK version requirement to Java 1.8.
>>> Your statement "please keep backward compatibility with older JDKs"
>>> could mean anything between "please leave everything as it is now" to
>>> "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
>>>
>>> This requirement would be introduced for Subversion 1.11.
>>> Can you explain which versions of OS X / JDK you expect to support when
>>> Subversion 1.11 will be released in probably 2 to 3 years from now?
>> No one would be able to build the stable release of Subversion with JDK
>> 10 for 2 to 3 years?
>>
>> Supporting both pre-8 and post-8 JDKs wouldn't be trivial.  I've been
>> working under the assumption that we can bump up to JDK 8 and backport
>> that change to 1.10.
>>
>> If that's not going to be the case, should my current work still go to
>> trunk?  Then someone can find the time to adapt things to also work with
>> pre-8 JDK?
> I think you should aim to proceed with your plan as it was.
> If anyone has strong objections to this, they should be constructive and
> try to provide an alternative solution without pushing an additional
> burden on you.

Given that Java 6 and 7 are obsolete ... I think it won't hurt to make
Java 8 the oldest supported version on the 1.10.x branch.

-- Brane

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

[Stefan Sperling <st...@elego.de>]

On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote:
> On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote:
> > Elsewhere in this discussion thread it was suggested to raise the
> > minimum JDK version requirement to Java 1.8.
> > Your statement "please keep backward compatibility with older JDKs"
> > could mean anything between "please leave everything as it is now" to
> > "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
> > 
> > This requirement would be introduced for Subversion 1.11.
> > Can you explain which versions of OS X / JDK you expect to support when
> > Subversion 1.11 will be released in probably 2 to 3 years from now?
> 
> No one would be able to build the stable release of Subversion with JDK
> 10 for 2 to 3 years?
> 
> Supporting both pre-8 and post-8 JDKs wouldn't be trivial.  I've been
> working under the assumption that we can bump up to JDK 8 and backport
> that change to 1.10.
> 
> If that's not going to be the case, should my current work still go to
> trunk?  Then someone can find the time to adapt things to also work with
> pre-8 JDK?

I think you should aim to proceed with your plan as it was.
If anyone has strong objections to this, they should be constructive and
try to provide an alternative solution without pushing an additional
burden on you.

Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

[James McCoy <ja...@jamessan.com>]

On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote:
> Elsewhere in this discussion thread it was suggested to raise the
> minimum JDK version requirement to Java 1.8.
> Your statement "please keep backward compatibility with older JDKs"
> could mean anything between "please leave everything as it is now" to
> "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
> 
> This requirement would be introduced for Subversion 1.11.
> Can you explain which versions of OS X / JDK you expect to support when
> Subversion 1.11 will be released in probably 2 to 3 years from now?

No one would be able to build the stable release of Subversion with JDK
10 for 2 to 3 years?

Supporting both pre-8 and post-8 JDKs wouldn't be trivial.  I've been
working under the assumption that we can bump up to JDK 8 and backport
that change to 1.10.

If that's not going to be the case, should my current work still go to
trunk?  Then someone can find the time to adapt things to also work with
pre-8 JDK?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: JDK 10 removal of javah

[Thomas Singer <th...@syntevo.com>]

We are using OS X 10.7.5 for building SVN binaries. This seems to work 
with Java 1.8.

--
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog


On 2018-05-18 9:46, Stefan Sperling wrote:
> On Fri, May 18, 2018 at 08:40:35AM +0200, Thomas Singer wrote:
>> Whatever you do, please keep backward compatibility with older JDKs. Reason
>> is building on older OS X machines for most compatibility which do not allow
>> latest JDKs.
>>
>> Thanks for considering.
> 
> Could you be more specific about which versions of JDK are required
> for compatibility with which old versions of OS X?
> 
> Elsewhere in this discussion thread it was suggested to raise the
> minimum JDK version requirement to Java 1.8.
> Your statement "please keep backward compatibility with older JDKs"
> could mean anything between "please leave everything as it is now" to
> "bumping the minimum requirement to Java 1.8 is absolutely fine with me".
> 
> This requirement would be introduced for Subversion 1.11.
> Can you explain which versions of OS X / JDK you expect to support when
> Subversion 1.11 will be released in probably 2 to 3 years from now?
> 

Re: JDK 10 removal of javah

[Stefan Sperling <st...@elego.de>]

On Fri, May 18, 2018 at 08:40:35AM +0200, Thomas Singer wrote:
> Whatever you do, please keep backward compatibility with older JDKs. Reason
> is building on older OS X machines for most compatibility which do not allow
> latest JDKs.
> 
> Thanks for considering.

Could you be more specific about which versions of JDK are required
for compatibility with which old versions of OS X?

Elsewhere in this discussion thread it was suggested to raise the
minimum JDK version requirement to Java 1.8.
Your statement "please keep backward compatibility with older JDKs"
could mean anything between "please leave everything as it is now" to
"bumping the minimum requirement to Java 1.8 is absolutely fine with me".

This requirement would be introduced for Subversion 1.11.
Can you explain which versions of OS X / JDK you expect to support when
Subversion 1.11 will be released in probably 2 to 3 years from now?

Re: JDK 10 removal of javah

[Thomas Singer <th...@syntevo.com>]

Hi James,

Whatever you do, please keep backward compatibility with older JDKs. 
Reason is building on older OS X machines for most compatibility which 
do not allow latest JDKs.

Thanks for considering.

--
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog


On 2018-05-18 4:27, James McCoy wrote:
> On Fri, May 04, 2018 at 08:12:29AM -0400, 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.
> 
> It's taken longer than I was hoping, but I'll have something for trunk
> soon.
> 
> The biggest wrinkle is that "javac -h" _only_ generates a header file if
> there are native annotations, whereas "javah" would always generate a
> header file.  This found some places where we didn't have native
> annotations even though they were needed.
> 
> It also throws a wrench in our dependency tracking.  We can't just say
> "Hey make, these .java files all generate a .h file, and libsvnjavahl
> depends on all the .h files" anymore.
> 
> I was initially going to drop the javah type from build.conf.  Since it
> looks like we'll need to explicitly list the header files we expect to
> generate, it will probably be cleaner to use the package-based javah
> stanzas instead.  That will also keep the dependencies more accurate.
> 
> Cheers,
> 

Re: JDK 10 removal of javah

[James McCoy <ja...@jamessan.com>]

On Fri, May 04, 2018 at 08:12:29AM -0400, 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.

It's taken longer than I was hoping, but I'll have something for trunk
soon.

The biggest wrinkle is that "javac -h" _only_ generates a header file if
there are native annotations, whereas "javah" would always generate a
header file.  This found some places where we didn't have native
annotations even though they were needed.

It also throws a wrench in our dependency tracking.  We can't just say
"Hey make, these .java files all generate a .h file, and libsvnjavahl
depends on all the .h files" anymore.

I was initially going to drop the javah type from build.conf.  Since it
looks like we'll need to explicitly list the header files we expect to
generate, it will probably be cleaner to use the package-based javah
stanzas instead.  That will also keep the dependencies more accurate.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: JDK 10 removal of javah

[Mark Phippard <ma...@gmail.com>]

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/

Re: JDK 10 removal of javah

[Stefan Hett <st...@egosoft.com>]

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

Re: JDK 10 removal of javah

[Branko Čibej <br...@apache.org>]

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