Feat(SystemClock): Added PreciseClock implementation to the system clock class, for the benefit of Java 8 users.

[jaykataria1111]

Straight forward change to override the behavior of System Clock, to implement the Precise Clock interface, for the benefit of Java 8 users. The PR is for issue #3198

Checklist

• Base your changes on 2.x branch if you are targeting Log4j 2; use main otherwise
• ./mvnw verify succeeds (if it fails due to code formatting issues reported by Spotless, simply run ./mvnw spotless:apply and retry)
• Non-trivial changes contain an entry file in the src/changelog/.2.x.x directory
• Tests for the changes are provided
• Commits are signed (optional, but highly recommended)

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	✅
build-ubuntu-latest	clean install	3.9.8	✅
build-windows-latest	clean install	3.9.8	✅

Generated by gradle/develocity-actions

[ppkarwasz]

The build failure is due to the 2.24.2 release being published (BND checks your code against 2.24.2 now, instead of 2.24.1 before).

Please, rebase.

[jvz]

Code changes look good to me. Can you add a changelog entry for this? You can copy src/changelog/.2.x.x /3121_instant_format.xml as an example of a changed entry.

[jaykataria1111]

Hi @jvz , @ppkarwasz There we go did it 📦

[ppkarwasz]

@jaykataria1111,

Since the Java 8 and Java 9+ versions of the SystemClock class are identical now, can you remove the Java 9+ version (in log4j-core-java9). The log4j-core-java9 package has a lot of dummy classes, whose purpose is to make the module compilable, they are not packaged. Can you remove those dummy classes too?

[ppkarwasz]

The class itself is older, so we should remove the @since.

[jaykataria1111]

Sounds good!

[ppkarwasz]

Personally I find {@inheritDoc} a little bit useless, since IDEs will look at the Javadoc of the parent class/implemented interface anyway, if the Javadoc is missing.

[jaykataria1111]

Sounds good, will remove this too!

[jaykataria1111]

@ppkarwasz

Great opportunity for me to learn here:

The log4j-core-java9 package has a lot of dummy classes, whose purpose is to make the module compilable, they are not packaged. Can you remove those dummy classes too

1. What does it mean to make the module "compatible"?
2. they are not packaged - How do I identify the classes that are packaged.
3. How do I identify these dummy classes?

[ppkarwasz]

@jaykataria1111 ,

The log4j-core-java9 package has a lot of dummy classes, whose purpose is to make the module compilable, they are not packaged. Can you remove those dummy classes too

1. What does it mean to make the module "compatible"?

To make it "compilable".

The log4j-core-java9 module is compiled before log4j-core and has no access to the classes of log4j-core.
In order to compile a class like SystemClock we had to add to log4j-core-java9 also the classes it depends upon, e.g., those in the core.time directory.

These are the classes that I call "dummy" classes.

2. they are not packaged - How do I identify the classes that are packaged.

We use the Maven Assembly plugin to package the classes in log4j-core-java9. There is an explicit list of classes to package in the java9.xml descriptor.

3. How do I identify these dummy classes?

They should have a comment near the top that says that they are "dummy" or something equivalent.