Which is mainly because the version of Java in Android is intentionally lacking about half of the standard library. Perhaps this will improve in the future now that they're adopting OpenJDK, though.
On 14 October 2017 at 17:04, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I need to point out that even after removing that there would be a lot of > stuff in log4j-core that doesn’t work in Android. > > Ralph > > > On Oct 14, 2017, at 12:02 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
