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