Hi Akim, > In Bison we have a Java backend. We use gnulib to handle the > Java tool chain. In particular, in configure.ac we have > > gt_JAVACOMP([1.3], [1.4]) > gt_JAVAEXEC > > it worked like a charm for years. > > Until macOS Mojave; Yu Yijun reported that we get: > > 467. java.at:367: testing Calculator ... > ./java.at:367: bison -fno-caret -o Calc.java Calc.y > ./java.at:367: $SHELL ../../../javacomp.sh Calc.java > stderr: > warning: [options] bootstrap class path not set in conjunction with -source > 1.3 > error: Source option 1.3 is no longer supported. Use 1.6 or later. > error: Target option 1.4 is no longer supported. Use 1.6 or later. > ... > I have absolutely no idea what that change implies. What are > the other project based on gnulib that use this? What is the > current policy for updating the requirements?
The essential reference is the timeline of Java releases: https://en.wikipedia.org/wiki/Java_version_history As you can see, Java specification levels 1.3, 1.4, 1.5 are outdated for more than 3 years. And level 1.6 will be outdated in December 2018. So, why not move to gt_JAVACOMP([1.7], [1.7]) already now? What this change implies? 1) You must adapt your source code (or bison-generated code) to be compliant with Java 1.7. In particular, you cannot have variables or methods named 'assert' any more, since this is a keyword since Java 1.4. And a couple of things like that. 2) You cannot use GCJ as Java implementation any more, since it stayed at level 1.5 / 1.6 before it was discontinued. (It was dropped in GCC 7.) 3) Users who want to use the compiled .class / .jar files will need Java 7 or newer. But this is not a problem, since the industry has already moved from Java 6 to Java 7 (mostly). Gettext moved from gt_JAVACOMP([1.3], [1.1]) to gt_JAVACOMP([1.5], [1.6]) recently, as a consequence of this bug report: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892733> There is no policy; you update these gt_JAVACOMP invocations as you like. Bruno
