Allow 1.5 series to build with Java 9 and later #222
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It has never been clear to me why Thomas added this line in 2013 (c795b6b). I have no build difficulties without it. It certainly can't remain for Java 9+, where the runtime files have been rearranged and there is no rt.jar. Perhaps this will impair building on some other platform. We'll see.
Java 12 bumps the earliest -source/-target that can be requested from 6 to 7, so change the request accordingly if building on 12 or later. Anyone with an actual need to run the resulting pljava.jar on a Java 6 runtime will have to build it with 11 or earlier.
Java 9 moves the batteries-included Nashorn JavaScript engine from the boot classpath to the application classpath. Maven does such wacky things with class loader delegation that suddenly the script engine is no longer found by default when building on 9 or later. (https://issues.apache.org/jira/browse/MANTRUN-200) Workaround is to pass a classpathref of maven.plugin.classpath explicitly to <script> elements, as suggested by Cristian Florescu (https://issues.apache.org/jira/browse/MANTRUN-200?focusedCommentId=16207112&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16207112). It is also necessary for the <ant> task in the POM to propagate that reference explicitly to the subordinate Ant project. It turns out the <scriptdef> in pljava-packaging Just Works, as it already had an explicit classpath for other reasons.
Java 8 added a -h option to javac to allow generation of .h files from Java sources in one step, subsuming (most of) the function of the older javah command. Java 10 duly axed javah, leaving only the javac -h option, a stroke of brilliance that left no way to h a class file, such as java.sql.Types, for which no source file is present. The smart-alecky workaround would be to add a new <scriptdef> in the build process that would iterate java.sql.Types.class.getDeclaredFields() and write them to an .h file. It would hardly be difficult (at least for this special case, a class defining only some int constants and loadable at build time with no dependency issues). But that hardly seems necessary, considering that (as of Java 12) there have been no changes to java.sql.Types constants since Java 8, there is only one PL/Java source file (type/Oid.c) that uses them, and that file will probably go away anyway in a foreseeable PL/Java release. So here, a version of java_sql_Types.h generated on Java 8 is simply provided in include/fallback/jdbc. If it is not gone by the time new Types constants are added in a future Java version, they can be added to it then. There is some conditional compilation in Oid.c based on this file, so continue to generate it when possible (using javah unless the build JDK is 10 or newer), switching to javac -h and the fallback copy only for 10 or newer.
The nar-maven-plugin knows that if it runs javah, it needs to add the JDK's include directories to C's include path. In the Java 10+ case where it will not run javah, it must be explicitly told to add those to the include path.
jcflack
added a commit
that referenced
this pull request
Jun 28, 2019
Permits building the 1.5 series with Java 9 or newer JDKs, otherwise without radical change or loss of back compatibility. The Java 12 compiler can no longer generate code for targets older than Java 7, so if a PL/Java must be built to run in Java 6, the build must be done with a JDK no newer than 11. Addresses issue #212.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To this point, PL/Java 1.5.x has required a Java 8 (or 7, or with considerable nursing, 6) JDK to build, though it can then run on later JREs (and user code can be written to the later language standards and APIs). Java 9 introduced changes that threatened to be hard to work into the build system while preserving 1.5.x's ability to be built in the older environments. The original plan was to keep the 1.5.x build requirements unchanged, and make the next major version purely Java 9 and later (and drop some of the ancient-PG-release support as well).
But issue #212 raised the stakes, as apparently Debian distros are out now or imminently that won't have a Java 8 development kit handy for package building. So, this PR tweaks 1.5.x as minimally as possible with the aim of allowing it to be built on Java 9 or later, without giving up its compatibility with older versions. The plan is still not to require Java 9 until the still-work-in-progress next major version.