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