RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation
Daniel Fuchs
daniel.fuchs at oracle.com
Tue Dec 6 17:49:13 UTC 2016
On 06/12/16 17:30, Mandy Chung wrote:
>
>> On Dec 6, 2016, at 1:36 AM, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
>>
>> Hi Daniel,
>>
>> Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/
>
> 109 boolean simleConsoleOnly = !Layer.boot().findModule("java.logging").isPresent();
>
> typo: s/simle/simple
>
> 107 Class sploggerType = splogger.getClass();
> :
> 123 Class sloggerType = slogger.getClass();
> 124 System.out.println("slogger: " + sloggerType);
> 125 if (sloggerType.equals(sploggerType)) {
>
> This check is redundant. Is this the intended check?
>
> Assuming the above check is not needed, you can further simplify something like this:
>
> String expectedType = Layer.boot().findModule("java.logging").isPresent()
> ? "SimpleConsoleLogger" : "JdkLazyLogger”;
Hi Mandy,
No it's not redundant. Sorry for using bad variable names
which differ only by 1 letter.
splogger => System.Logger returned for a platform class (loaded
by platform class loader)
slogger => System.Logger returned for a regular class (not loaded
by platform logger or its ancestor).
if java.logging is not present and no provider is found then both
will be a SimpleConsoleLogger, otherwise the former will be a lazy
logger, and the latter a logger returned by java.logging implementation
of the DefaultLoggerFinder...
Before 8163162 they would have been of the same class - so the test
just checks that 8163162 is doing what we expect.
best regards,
-- daniel
>
> Mandy
>
More information about the core-libs-dev
mailing list