qos-ch / reload4j

reload4j is a drop-in replacement for log4j 1.2.17
Apache License 2.0
148 stars 22 forks source link

org.apache.log4j.helpers.Loader.isJava1() returns true on Java 19 and other versions #59

Open pburka opened 1 year ago

pburka commented 1 year ago

If the Java version string doesn't include a decimal point, reload4j incorrectly identifies it as Java 1. The initial version of each major release no longer includes a decimal point (since around Java 10 or 11), so reload4j incorrectly identifies these as Java 1 (circa 1995).

|  Welcome to JShell -- Version 19
|  For an introduction type: /help intro

jshell> System.getProperty("java.version")
$1 ==> "19"

jshell> org.apache.log4j.helpers.Loader.isJava1()
$2 ==> true

The simplest fix would be to make isJava1() always return false, since the reload4j website indicates that build targets Java 1.5, so the classfiles won't even work on Java 1.

ceki commented 1 year ago

HI @pburka,

The Loader.isJava1() method is no longer used although the java1 variable is used in Loader.getResource() method. The latter method is used to find configuration files using the Thread Context Class Loader (TCCL). Since java1 returned always true under JDK 9 and later, searching for configuration files never used the TCCL in practice in these "newer" JDKs but it did in JDK 1.8 and older.

May I ask how come you came to find about this issue?

pburka commented 1 year ago

I've hit problems with isJava1() before so I have a unit test in my library that explicitly checks that it returns false! I didn't realize that it's no longer being used, but that would explain why I didn't see any other reload4j issues on Java 19.

ceki commented 1 year ago

Commit 3f35d074 cleans up the code. This was incorporated into release reload4j 1.2.24.

davidmoten commented 1 year ago

FYI The fix for this caused this problem: #62