Re: JDK 10 removal of javah

[Mark Phippard]

On Fri, May 4, 2018 at 8:49 AM, 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.
>
>

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

[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

Re: JDK 10 removal of javah

[James McCoy]

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: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

[Joe Orton]

On Thu, May 03, 2018 at 08:32:56PM +0100, Philip Martin wrote:
> Your patch is an improvement so I would be happy to see it on
> trunk/1.10.  Going further and removing some .pc files is probably also
> suitable for 1.10.  Changing the DSO names and installation location is
> probably not suitable for 1.10.

OK, committed to trunk in r1830882.  Thanks for reviewing!

Regards, Joe