Re: JDK 10 removal of javah

[James McCoy]

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
Index: trunk/Makefile.in
===
--- trunk/Makefile.in	(revision 1835511)
+++ trunk/Makefile.in	(working copy)
@@ -218,7 +218,6 @@
 # special compilation for files destined for javahl (i.e. C++)
 COMPILE_JAVAHL_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(LT_CFLAGS) $(JAVAHL_INCLUDES) -o $@ -c
 COMPILE_JAVAHL_JAVAC = $(JAVAC) $(JAVAC_FLAGS)
-COMPILE_JAVAHL_JAVAH = $(JAVAH)
 COMPILE_JAVAHL_COMPAT_JAVAC = $(JAVAC) $(JAVAC_COMPAT_FLAGS)
 
 # On Mac OS X, export an env variable so that the tests can run without
@@ -393,7 +392,6 @@
 JAVADOC = @JAVADOC@
 JAVAC_FLAGS = @JAVAC_FLAGS@
 JAVAC_COMPAT_FLAGS = @JAVAC_COMPAT_FLAGS@
-JAVAH = @JAVAH@
 JAR = @JAR@
 
 JAVA_CLASSPATH=$(abs_srcdir)/subversion/bindings/javahl/src:@JAVA_CLASSPATH@
@@ -494,8 +492,8 @@
 install-static: @INSTALL_STATIC_RULES@
 
 # JavaHL target aliases
-javahl: mkdir-init javahl-java javahl-javah javahl-callback-javah javahl-remote-javah javahl-types-javah javahl-util-javah javahl-lib @JAVAHL_TESTS_TARGET@ javahl-compat
-install-javahl: javahl install-javahl-java install-javahl-javah install-javahl-lib
+javahl: mkdir-init javahl-java javahl-callback-java javahl-remote-java javahl-types-java javahl-util-java javahl-lib @JAVAHL_TESTS_TARGET@ javahl-compat
+install-javahl: javahl install-javahl-java install-javahl-lib
 javahl-compat: javahl-compat-java @JAVAHL_COMPAT_TESTS_TARGET@
 
 clean-javahl:
Index: trunk/build/generator/gen_base.py
===
--- trunk/build/generator/gen_base.py	(revision 1835511)
+++ trunk/build/generator/gen_base.py	(working copy)
@@ -900,115 +900,67 @@
   def __init__(self, name, options, gen_obj):
 TargetLinked.__init__(self, name, options, gen_obj)
 self.link_cmd = options.get('link-cmd')
-self.packages = options.get('package-roots', '').split()
+self.package = options.get('package')
 self.jar = options.get('jar')
 self.deps = [ ]
-
-class TargetJavaHeaders(TargetJava):
-  def __init__(self, name, options, gen_obj):
-TargetJava.__init__(self, name, options, gen_obj)
 self.objext = '.class'
-self.javah_objext = '.h'
 self.headers = options.get('headers')
 self.classes = options.get('classes')
-self.package = options.get('package')
-self.output_dir = self.headers
+self.native = options.get('native', '')
+self.output_dir = self.classes
+self.headers_dir = self.headers
 
   def add_dependencies(self):
 sources = _collect_paths(self.sources, self.path)
+native = _collect_paths(self.native, self.path)
 
+class_pkg_list = self.package.split('.')
+sourcepath = build_path_split(self.path)[:-len(class_pkg_list)]
+sourcepath = build_path_join(*sourcepath)
+
 for src, reldir in sources:
   if src[-5:] != '.java':
 raise GenError('ERROR: unknown file extension on ' + src)
 
+  sfile = SourceFile(src, reldir)
+  sfile.sourcepath = sourcepath
+
   class_name = build_path_basename(src[:-5])
 
-  class_header = build_path_join(self.headers, class_name + '.h')
-  class_header_win = build_path_join(self.headers,
- 

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

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

[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.

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

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

[Michael Osipov]

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

Re: JDK 10 removal of javah

[Thomas Singer]

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: 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

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

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.

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

[James McCoy]

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

[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?

Re: JDK 10 removal of javah

[Thomas Singer]

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]

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]

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: 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