I am wondering if this is a little too early. A lot of tooling our there
does not play well with Java 9 class files.

The last time I tried to use Log4j 2 (which contains Java 9 classes files
in the right multi-jar spot) with an Android app, the Android tooling threw
up all over itself because it was incorrectly trying to do something with
these Java 9 class file :-(

Gary

On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <scolebou...@joda.org>
wrote:

> On 14 October 2017 at 14:05, Rob Tompkins <chtom...@gmail.com> wrote:
> >> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <brit...@apache.org>
> wrote:
> > Feels like a change that would warrant a major version change, but that
> would have us maintaining another major version branch.
>
> No need for a major version change. Its just one more .class file in
> the jar file. The jar file is still usable on Java 7 and 8, its just
> that the *build* is Java 9 specific.
>
> As Pascal says, really we want all the maven plugins to be ready for
> this, but we don't control those timescales.
>
> Options to fix the site plugin problem:
>
> 1) Alter the PR so that releases have to be in two stages - jar file
> build/deploy on Java 9 and site on Java 8. The risk is that someone
> forgets to do the release using Java 9.
>
> 2) Compile the module-info.java file on Java 9 and check it in (as a
> binary module-info.class file). Then the build could stay on Java 7/8.
> The problem however is that whenever a new package is added, the
> module-info.class file would have to be recreated and re-checked in,
> an error-prone process.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to