Support Java Modules

[aalmiray]

v1.2.25 defines an automatic module name

$ jarviz module name --gav ch.qos.reload4j:reload4j:1.2.25
subject: reload4j-1.2.25.jar
name: ch.qos.reload4j
source: manifest
automatic: true
valid: true

$ jarviz module descriptor --gav ch.qos.reload4j:reload4j:1.2.25
subject: reload4j-1.2.25.jar
name: ch.qos.reload4j
version: 1.2.25
open: false
automatic: true
requires:
  java.base mandated
contains:
  org.apache.log4j
  org.apache.log4j.chainsaw
  org.apache.log4j.config
  org.apache.log4j.helpers
  org.apache.log4j.jdbc
  org.apache.log4j.net
  org.apache.log4j.or
  org.apache.log4j.or.jms
  org.apache.log4j.or.sax
  org.apache.log4j.pattern
  org.apache.log4j.rewrite
  org.apache.log4j.spi
  org.apache.log4j.varia
  org.apache.log4j.xml

$ jarviz bytecode show --gav ch.qos.reload4j:reload4j:1.2.25
subject: reload4j-1.2.25.jar
Unversioned classes. Bytecode version: 49 (Java 5) total: 218

I'd be great if the library supplied a full Java module descriptor. It's possible to keep bytecode baseline compatible with Java 8 while providing a full module descriptor thanks to ModiTect. This will help modular projects that consume this library, specifically those that create custom Java Runtimes with jlink, as the latter does not support automatic modules but explicit modules.

ModiTect requires Java 9 to be used for running the build. Reload4j currently targets Java 5 bytecode. I think it might not be possible to use the plugin directly. The alternative would be to have an additional source set containing moudle-info.java compiled with Java 9+, then merge all classes into a single JAR. module-info.class should be placed in the versioned space (META-INF/versions/x) and a Multi-Release: true attributed added to the JAR's manifest.

If this feature is added then slf4j-reload4j would also need to be made fully modular (can't open a ticket at jira.qos.ch to file it at this moment).

[123Haynes]

I'm not the maintainer, but imho supporting modules fully is not worth the effort for this library.
It is intended as a drop-in replacement for log4j 1 so projects who can't upgrade to newer versions of log4j or migrate to other logging frameworks get at least security updates.
Those projects probably don't care so much about modules.
In your project cdevents/sdk-java you are already using slf4j everywhere so it would be trivial to migrate to a newer logging library.
You'd only need to replace the log4j.properties with the config file of the logging framework of your choice and replace the dependency in the pom.xml.

That being said, this is just my personal opinion. Feel free to correct me if I missed something 😄

[aalmiray]

True. cdevents could switch to other slf4j implementations such as logback or simple.