Re: JDK 10 removal of javah
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, - sel
Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)
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)
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)
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
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)
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)
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)
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)
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)
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
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
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
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
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
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
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
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
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
JDK 10 removal of javah
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 Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)