On 30 October 2017 at 23:09, Stephen Colebourne <scolebou...@joda.org> wrote: > Does commons-logging need to be a full module with a module-info.java? > Probably not at this point. Adding Automatic-Module-Name is probably > sufficient. However, if someone wants to do the work, then adding > module-info shouldn't be blocked IMO. > > I don't believe that module-info.java requires Java 6 or later. It > would be possible to create the module-info.class file using java 9 > and then use a much earlier compiler version to build the rest of the > jar. Or the module-info.class binary bytecode file could be checked > into git (probably simpler!).
The module-info.java file must also be stored somewhere in Git so the class file can be recreated. An approach would be: Add module-info.java to correct location so project compiles using Java 9. If using an earlier version of Java, skip the compilation and copy the pre-compiled class-file instead. [Ideally there should also be a check that the .class file is newer than the .java file] Not sure how easy that would be to do in Maven, but once done, it could be applied to all Commons components > Stephen > > > On 28 October 2017 at 21:31, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> Gary, >> >> As you know Log4j has a maven module for Java 9. It contains the >> module-info.java file. That module compiles with Java 9 and targets Java 9 >> as there isn’t much point targeting anything earlier. That class files >> produced are then overlaid on top of the classes produced for Log4j-api, >> which is targeted at 1.7 and uses the 1.7 compiler. Commons Logging could do >> exactly the same thing and just have a maven module for the Java 9 support >> and then use whatever compiler it wants for the current commons logging >> classes. >> >> That said, why does commons logging need to be a “real” module anyway? >> >> Ralph >> >>> On Oct 28, 2017, at 10:07 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>> From a pragmatic POV, the oldest Java byte codes you can get Java 9 to emit >>> are for Java 1.6. Since we will want, I assume, to produce a module info >>> class in the jar, we will need to use Java 9 for that (to keep an RM's life >>> manageable.) >>> >>> This means to me that we should set the bar at Java 1.6 for the bare >>> minimum, which seams reasonable in 2017 soon to be 2018 and considering >>> Java 6 and 7 are EOL. >>> >>> Gary >>> >>> On Sat, Oct 28, 2017 at 10:32 AM, Benedikt Ritter <brit...@apache.org> >>> wrote: >>> >>>> Hello, >>>> >>>> maybe we should decide on what we want to achieve here, before I start the >>>> endeavor of creating an RC for such an old component. >>>> >>>> My understanding of Logging is, that it is in semi dormant mode. That we >>>> don’t want to add any new features and instead point users to Log4j2. Since >>>> Logging has a wide installation base we decided not to upgrade the Java >>>> version requirement and instead stay at Java 1.2 and only release super >>>> critical fixes/updates. >>>> Upgrading to Java 6 seems to contradict this plan. So where do we want to >>>> go with Logging? >>>> >>>> Regards, >>>> Benedikt >>>> >>>>> Am 28.10.2017 um 18:20 schrieb Ralph Goers <ralph.go...@dslextreme.com>: >>>>> >>>>> That isn’t strictly true Gary, There are ways to build the module-info >>>> without upgrading the main code to Java 9. That said, it is a bit of a hack >>>> to do it. >>>>> >>>>> Ralph >>>>> >>>>>> On Oct 28, 2017, at 8:19 AM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>>> >>>>>> Let's update to at least a minimum of Java 6 such that the build can run >>>>>> with Java 9. Builing with Java 9 will be a requirement to add module >>>> info. >>>>>> >>>>>> Gary >>>>>> >>>>>> On Oct 28, 2017 01:21, "Benedikt Ritter" <brit...@apache.org> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> After I was able to update the the build to the latest parent POM, I’m >>>>>>> running into animal sniffer problems. The build is defined to target >>>> Java >>>>>>> 1.2 but there are classes which require later JDKs: >>>>>>> >>>>>>> - Jdk13LumberjackLogger >>>>>>> - Jdk14Logger >>>>>>> >>>>>>> This breaks the build because animal sniffer reports that these classes >>>>>>> don’t work on Java 1.2. I don’t understand how this is supposed to >>>> work. >>>>>>> Did we ship those classes and users have to decide whether they want to >>>>>>> load them or not depending on the JRE they are running on? Do we want >>>> to >>>>>>> exclude the two classes from animal sniffer? >>>>>>> >>>>>>> Regards, >>>>>>> Benedikt >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >> > > --------------------------------------------------------------------- > 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
