Current implementation in CommonsLoggerFactory.java has an "impl" package import from Apache commons logging. This might not be present at runtime and check
if library isn't present (e.g. in uDig).
Module should not depend on specific commons-logging implementation.
Maybe it helps if the check would look like this:
Handling this case (and any other logging bridges) should indeed be done by reflection.
As part of the upcoming Java 18.9 roadmap compatibility we will need to review our compatibility with different logging libraries and have an opportunity to take stock of what works and what can be removed.
This logger - Jdk14Logger appears to still be available in recent releases of commons logging.
It looks like that the class is available from version 1.0 to 1.1.1 of commons-logging jar. While we upgraded to never version of SLF4J and commons-logging 1.2+ the class ist not available in core packages anymore
However, I'll provide a patch to check if class name is "Jdk14Logger" and return null in this case. Otherwise the behavior doesn't change.
For dependency analysis and cleanup I'd suggest to create another issue.