On 24/05/19 9:56 AM, Stefan Bodewig wrote: > On 2019-05-24, Jaikiran Pai wrote: > >> As you all might know, we released Ant 1.10.6 some days back. That >> release was built using Java 11 but targeted to be usable with Java 8 >> (our minimum requirement runtime that we support). However, due to a bug >> in our build and release process, we have broken the compatibility of >> this version against Java 8. > I remember we had a similar case years ago when Java 1.4 introduced > StringBuffer.append(StringBuffer) and a release built on 1.4 would no > longer work on 1.3. This is too bad. Can --release fix it only if Java8 > is installed (or at least its rt.jar) in additon to the JDK your > building with?
From my experimentation so far, the --release fixes it (keeping aside our Java9+ tasks) without asking for a Java 8 installation (with JAVA_HOME pointing to a higher, for example Java 11 version). The documentation[1] doesn't say much on how it does that, but I guess the JDK ships with these public APIs for the (limited) supported --release versions. That in itself isn't a solution though because we need to tackle the other main issue - if we do set --release option in our javac, as stated in the documentation[1] of this attribute, this ends up using (only) the public APIs available in Java 8 (the version we use for the --release attribute). This effectively means that you will end up seeing compile errors for the jmod and the link tasks (the new ones) even when using JAVA_HOME pointing to Java 11. So I'm in the process of restructuring the build.xml (and issue a PR for review) to accommodate the following: 1. Mandate/force Java 9+ (preferably Java 11) for release managers and optionally let other users specify it. 2. Split out the compilation process of the new Java 9+ tasks from the current existing compilation target(s). 3. Use --release = 8 for all "regular" (the targets not meant to compile Java 9+ code) javac tasks in addition to --source and --target = 1.8. If users build Ant with Java 8, the --release will be ignored (that's a feature of our javac task) and if they build with Java 9+, the --source --target will be ignored (that's a feature of the JDK's javac). So using all 3 of these attributes should be fine without the need for additional conditionals. 4. Compile Java 9+ code (the new tasks) with --source, --target = 1.8 and _without_ the --release attribute. This will effectively let it compile fine and use the new Java 9+ Java APIs. Plus it will allow these tasks to be functional in Java 9+ environments. 5. Mandate/force (through the build.xml) the release manager to run our existing tests through *both* the Java runtime that's being used to build the project and also against Java 8 (the minimal version we support). This is one of things we got wrong in our release/build process and missed catching this issue. What we have been doing is building and running the tests in the same version. So although we have our Jenkins CI running against Java 8, 9, 11 - all of them compile the code and then run these tests on the same version from start to the end. With this new proposed mechanism, we should be able to catch issues like this, in future. Of course, I don't plan to mandate this on every one, so this will be a separate target which is responsible for running these tests against multiple Java version and will only be mandated for release managers. Others (including our CI jobs) will have a choice to run them. 6. This step is really optional and something that I haven't fully thought through. I was thinking maybe while we are at it, make these new Java 9+ task resources (classes and any other related artifacts), into a multi-release jar. But I don't see this as a necessity to sort out our current issue. 7. Update our CI jobs to use Java 11 as the JAVA_HOME and then run the testsuite using Java 8, 9, 10 and 11 (the new build.xml target that I propose in #5 should simplify this process). In theory, I guess what I have outlined in above steps should get us past this issue. I will know more when I get something working. All this said, I haven't yet had the time to look into the archives of OpenJDK mailing lists to see if this was a expected incompatibility change in that class or whether this needs to be discussed. I'll take that up later though. >> This mail is just an advance notice to users who might have been >> planning to upgrade their setups to this released version, to wait for a >> newer release, > Sounds as if we should also put that as "news" on the website, on the > home page and into the FAQ (known problems). Yes, that sounds right. I can take this up later tonight if no one else gets there before me. [1] https://docs.oracle.com/en/java/javase/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9 -Jaikiran --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
