Nashorn logging and JUL implementations

[Piotr P. Karwasz]

Hi all,

As reported by one of our users[1], there are some issues concerning the 
compatibility of Nashorn with alternative `java.util.logging` 
implementations. While we can implement a workaround in Log4j, I believe 
that a proper solution requires the collaboration of both projects.

As you are probably aware the standalone `jjs` application provides a 
`-log` option[2] that allows users to modify the logging configuration 
of the Nashorn Shell. There are however some issues with this code:

1. The code is contained in `nashorn-core`, so it will affect all 
applications, even those that use Nashorn as a library. I strongly 
believe that application developers should be in full control of the 
logging configuration, without having libraries modify that 
configuration behind their back.

2. The code relies on the usage of the `Logger.setLevel()`, 
`Logger.addHandler()` and `Logger.setUseParentHandler()` JUL methods. 
These methods have no equivalents in pure logging APIs such as Log4j API 
and SLF4J and are no-ops. For users of the JUL-to-Log4j API bridge this 
means that the `-log` option will be ignored.

3. The code relies on the usage of the `Logger.getLevel()` method to 
find the **effective** level of a logger. Similarly to the setter 
methods, pure logging APIs do not provide a way to find out if a level 
configuration was explicitly provided by the user or it was inherited 
from the parent logger. While we can fix the coherence between 
`setLevel()` and `getLevel()` (see [4]), this looks more like a 
workaround to me and Nashorn should probably replace `Logger.getLevel()` 
with `Logger.isLoggable()` (the latter will always provide the effective 
level).

4. Nashorn uses a logger wrapper (`DebugLogger`), which makes all the 
location information in the logs point to the `DebugLogger` class itself.

I can certainly provide help in solving these issues, but before 
creating some PRs, I would like to know what the Nashorn team thinks 
about changes to the logging code and what directions would be 
acceptable for the team.

Piotr

[1] https://github.com/apache/logging-log4j2/issues/3119

[2] 
https://github.com/openjdk/nashorn/blob/2eb88e4024023ee8e9baacb7736f914e3aa68aa4/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/options/Options.java#L541

[3] 
https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/logging/DebugLogger.java

[4] https://github.com/apache/logging-log4j2/pull/3125