On Wed, 13 Oct 2021 17:15:53 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
> Aside note: why `String.class.getName()`? is the logged message generated by > java.lang.String? that would be dangerous - as strings are used all over the > place in java.util.logging... I had a look at the original issue for which this test was introduced https://bugs.openjdk.java.net/browse/JDK-8247907. As Max notes in that JBS issue, the bug was in log messages which are parameterized. Internally, the implementation of `com.sun.org.slf4j.internal.Logger` just delegates the calls to a `java.util.logging.Logger` and the fix was to properly transform the parameterization placeholders before passing on the calls to the `java.util.logging.Logger`[1]. So from what I understand, this `LogParameters` testcase is just there to test a parameterized log message through the `com.sun.org.slf4j.internal.Logger` and as such it doesn't matter what logger name (or class) is passed to create the logger instance. To avoid any confusion about the `String.class` usage for the logger instance, I have now updated the PR to use a different logger name (and class) while constructing the `java.util.logging.Logger` and `com.sun.org.slf4j.internal.Logger` instances. Additionally, I've added some code comments in the test and also added a `@summary` to explain what this test does. The test continues to pass with these changes. [1] https://hg.openjdk.java.net/jdk/jdk/rev/216c6baa0564#l2.119 ------------- PR: https://git.openjdk.java.net/jdk/pull/5927
