Could somebody help me to understand what we mean by JPMS support, please? Because I have the impression that people think `2.x` does not have JPMS support and `main` excels at it.
`2.21.0` brought `2.x` a fully-fledged JPMS support. JPMS and OSGi descriptors are auto-generated by `bnd-maven-plugin`. Piotr and I manually marked every single package that needs to be exported and checked every single generated `module-info.java` and `MANIFEST.MF`. IIRC, 3+ users shared positive feedback in GitHub Issues and the next `2.x` release will even support `jlink` due to #1896. Since there are no `module-info.java` files lying around (`bnd-maven-plugin` adds them to the JAR at the `package` phase), IDEs are not confused by the module-vs-class path dilemma too. OTOH, JPMS support in the `main` branch was first established by hand-written `module-info.java` files and then later on reimplemented (work in progress!) by Piotr via porting stuff from `2.x`. Nobody has tested it yet, AFAIK. `jlink` is known to not work there. In the context of JPMS support, `2.x` is a clear winner over `3.x`, AFAIC. If not, I would appreciate your help in explaining what I am missing. Though `3.x` is good at two things regarding modularization: 1. It breaks down `log4j-core` into more fine-grained modules (e.g., `log4j-csv`) 2. It has slightly improved package encapsulation. That is, some internal classes are indeed moved to internal packages. `2.x` can never implement #2, since it is a breaking change. Thought #1 can very well be implemented for `2.x` – users will just need to add a new JAR to their classpath.
