Unintentional broken compatibility of Ant 1.10.6 with Java 8

[Jaikiran Pai <ja...@apache.org>]

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. One such issue has been reported here
https://bz.apache.org/bugzilla/show_bug.cgi?id=63457 and a fix (and a
prevention to hopefully not run into these issues again) is being worked
upon. This obviously will involve a new release of Ant 1.10.x.

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, if you plan to use this version against Java 8. In the
meantime, you can still try out the 1.10.6 release and report any other
issues that you might run into.

-Jaikiran

Re: Unintentional broken compatibility of Ant 1.10.6 with Java 8

[Jaikiran Pai <ja...@apache.org>]

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Unintentional broken compatibility of Ant 1.10.6 with Java 8

[Stefan Bodewig <bo...@apache.org>]

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?

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

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org