JDK 10 removal of javah

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

JDK 10 removal of javah

Andreas Stieger-2
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?

Andreas

--
Andreas Stieger <[hidden email]>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Branko Čibej
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.

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

James McCoy-3
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
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Branko Čibej
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

Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Stefan Hett-2
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

Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Mark Phippard-3
In reply to this post by Branko Čibej
On Fri, May 4, 2018 at 8:49 AM, Branko Čibej <[hidden email]> 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.

--
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

James McCoy-3
In reply to this post by James McCoy-3
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
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Thomas Singer (SyntEvo)
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,
>
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Stefan Sperling
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?
Reply | Threaded
Open this post in threaded view
|

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

James McCoy-3
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
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling
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.
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling
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.
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
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

Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

Thomas Singer (SyntEvo)
In reply to this post by Stefan Sperling
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?
>
Reply | Threaded
Open this post in threaded view
|

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

Michael Osipov
In reply to this post by James McCoy-3
> 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.

I don't share this opinion as a Java developer and Maven PMC for several
reasons:

1. I would expect a baseline raise decision for a Subversion branch to
be announced in advance. The issue was brought up in 2017-12. No one
stood up.
2. None of the code uses any Java 8 features, there is no compelling
reason to raise, just because javah has been replaced.
3. Java 6 and 7 are available from other vendors for free or for paid
for still sometime, regardless of Java 8.
4. Enterprise people tend to freeze stuff for years (which I personally
don't like, but that is another story).
5. We, Maven developers, try to keep the baseline very low to give a
broader community to possibility to use our code as long as possible.

Recently a proposal was made to raise the Maven baseline to Java 8, I
immediately objected because unless someone will make use of Java 8
features, this is going to be pointless. We haven't even embraced NIO2.

Upshot: I'd expect Subversion 1.11 to require Java 8 (or Java 11 if this
will be available on tier 2 and 3 platforms too) for tooling reasons,
but nothing for below.

Michael
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling-9
On Sun, May 20, 2018 at 12:47:39PM +0200, Michael Osipov wrote:

> > On 18.05.2018 14:34, Stefan Sperling wrote:
> > > 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.
>
> I don't share this opinion as a Java developer and Maven PMC for several
> reasons:
>
> 1. I would expect a baseline raise decision for a Subversion branch to be
> announced in advance. The issue was brought up in 2017-12. No one stood up.
> 2. None of the code uses any Java 8 features, there is no compelling reason
> to raise, just because javah has been replaced.
> 3. Java 6 and 7 are available from other vendors for free or for paid for
> still sometime, regardless of Java 8.
> 4. Enterprise people tend to freeze stuff for years (which I personally
> don't like, but that is another story).
> 5. We, Maven developers, try to keep the baseline very low to give a broader
> community to possibility to use our code as long as possible.
>
> Recently a proposal was made to raise the Maven baseline to Java 8, I
> immediately objected because unless someone will make use of Java 8
> features, this is going to be pointless. We haven't even embraced NIO2.
>
> Upshot: I'd expect Subversion 1.11 to require Java 8 (or Java 11 if this
> will be available on tier 2 and 3 platforms too) for tooling reasons, but
> nothing for below.
>
> Michael

Hi Michael,

Thanks for joining this discussion and voicing your opinion.

It is a bit unclear to me what your stake in this discussion is.
Are you using Subversion's Java bindings anywhere and would be impacted
by the proposed change? I don't see how requirements of the Maven project
would directly relate to the problem jamessan is trying to fix, namely
that Subversion 1.10 Java bindings do not compile with JDK 1.10.

If you strongly object to raising our minimum JDK dependency to 1.8 and
can give us a good reason to help us understand why we should not raise it,
would you then also help jamessan to make our build system support JDK
versions smaller than 1.8 as well as 1.10 and above? It sounds like
maintaining support for all these versions implies that extra work would
need to be done, and I'm sure we could use your help in that case.

Thanks,
Stefan
Reply | Threaded
Open this post in threaded view
|

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

Michael Osipov
Am 2018-05-20 um 16:03 schrieb Stefan Sperling:

> On Sun, May 20, 2018 at 12:47:39PM +0200, Michael Osipov wrote:
>>> On 18.05.2018 14:34, Stefan Sperling wrote:
>>>> 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.
>>
>> I don't share this opinion as a Java developer and Maven PMC for several
>> reasons:
>>
>> 1. I would expect a baseline raise decision for a Subversion branch to be
>> announced in advance. The issue was brought up in 2017-12. No one stood up.
>> 2. None of the code uses any Java 8 features, there is no compelling reason
>> to raise, just because javah has been replaced.
>> 3. Java 6 and 7 are available from other vendors for free or for paid for
>> still sometime, regardless of Java 8.
>> 4. Enterprise people tend to freeze stuff for years (which I personally
>> don't like, but that is another story).
>> 5. We, Maven developers, try to keep the baseline very low to give a broader
>> community to possibility to use our code as long as possible.
>>
>> Recently a proposal was made to raise the Maven baseline to Java 8, I
>> immediately objected because unless someone will make use of Java 8
>> features, this is going to be pointless. We haven't even embraced NIO2.
>>
>> Upshot: I'd expect Subversion 1.11 to require Java 8 (or Java 11 if this
>> will be available on tier 2 and 3 platforms too) for tooling reasons, but
>> nothing for below.
>>
>> Michael
>
> Hi Michael,
>
> Thanks for joining this discussion and voicing your opinion.
>
> It is a bit unclear to me what your stake in this discussion is.
> Are you using Subversion's Java bindings anywhere and would be impacted
> by the proposed change? I don't see how requirements of the Maven project
> would directly relate to the problem jamessan is trying to fix, namely
> that Subversion 1.10 Java bindings do not compile with JDK 1.10.

Hi Stefan,

first of all I am a more-than-happy Subversion user for more than ten
years now, second as an ASF member I can take the stake. I use
Subversion and the bindings on several operation systems and in Eclipse.
The Maven project was just an example how we do it and that we don't
change such requirements in a maintenance branch for a minor version.

I fully understand that javah is code and the bindings cannot be
compiled. But this is just another issue we need to solve, though I
haven't looked into the autoconf scripts what is exactly done.

> If you strongly object to raising our minimum JDK dependency to 1.8 and
> can give us a good reason to help us understand why we should not raise it,
> would you then also help jamessan to make our build system support JDK
> versions smaller than 1.8 as well as 1.10 and above? It sounds like
> maintaining support for all these versions implies that extra work would
> need to be done, and I'm sure we could use your help in that case.

My simple objection is that the raise has to happen before 1.10 has been
announced, people might rely on how the baseline has been drawn. That's
all I am trying to say. Believe me, there are so many people using ASF
software, but never contributing back, but start yelling when their
stuff breaks. The same not-so-smart move has been done by Oracle, they
provided throughout Java 9 EA 32 bit binaries, but dropped them from the
GA release w/o further notice. People were pissed.

I am always willing to help ASF fellows as I have done with Ivan and
Lieven for serf stuff. If there is a branch need to review or step in,
no issue. Just waiting for some lines.

Michael
Reply | Threaded
Open this post in threaded view
|

Re: JDK 10 removal of javah

James McCoy-3
In reply to this post by James McCoy-3
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

java10.patch (17K) Download Attachment