Hi Ralph, > Am 15.10.2017 um 21:20 schrieb Ralph Goers <ralph.go...@dslextreme.com>: > > I should point out - just for reference - that Log4j has a maven module > dedicated to Java 9 and only that is built with the Java 9 compiler. > Everything else uses Java 7. We also use Java 7 when running the maven site > plugin. It complains when it finds Java 9 classes but it doesn’t fail. > > I don’t think waiting is a very good option. At the very least commons lang > should add the Automatic-Module-Name header. This can be done with any > compiler version. But adding a module-info.java file is pretty > straightforward - especially since it is likely that everything will be > exported.
We’re shipping with Automatic-module-name header since 3.6. Cheers, Benedikt > > Ralph > >> On Oct 15, 2017, at 3:04 AM, Stephen Colebourne <scolebou...@joda.org> wrote: >> >> Log4J is adding module-info.java now, and its not overly complicated >> to do here either. The main question seems to be around the maven site >> plugin, but thats likely to be fixed soon. ie. I'd like to get to the >> point where all the basic commons projects have module-info.java >> (because proper modularization is going to occur bottom up, so the >> earlier we can get these out the better). >> >> FWIW, its up to Android to sort out its tooling - Java 9 is not going away! >> >> I'd like to establish if there are any fundamental objections to the >> concept of building only on Java 9. I'm also willing to try and find a >> way to get the build to still work on Java 7, but that releases have >> to be on Java 9. >> >> Stephen >> >> >> >> On 15 October 2017 at 10:49, Benedikt Ritter <brit...@apache.org> wrote: >>> Okay, let’s get back to topic. I feel that the community want’s to wait >>> some more until at least all maven plugins we use work with Java 9? >>> >>> Regards, >>> Benedikt >>> >>>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <boa...@gmail.com>: >>>> >>>> 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> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > > > --------------------------------------------------------------------- > 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
