RFR: 8163162: The separation between system loggers and application loggers should take the extension loader in consideration.

Daniel Fuchs daniel.fuchs at oracle.com
Thu Oct 27 10:30:16 UTC 2016


On 27/10/16 00:17, Mandy Chung wrote:
>
>> On Oct 26, 2016, at 6:58 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> With the deprivileging of some JDK modules, classes loaded
>> by the Platform class loader should get the same kind of
>> loggers than classes loaded by the Boot class loader (null loader).
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8163162/webrev.00/
>>
>
> The patch looks okay.
>
> Nit:
>   final boolean isSystem = AccessController.doPrivileged(…);
>   return isSystem;
>
> It could simply be:
>     returns AccessController.doPrivileged(…);
>
> Nit: The test uses @compile.  It can be @build that will avoid recompilation if the source is not modified.
>
>   37  * @compile systempkg/log/SystemLoggerAccessor.java SystemLoggerInPlatformLoader.java

Thanks Mandy - I will do these before pushing.

best regards,

-- daniel


>> Yes - I've been bitten before with using lambda
>> in logging code - especially in those parts that
>> can be invoked early during platform class
>> initialization - so I tend to avoid using them
>> in places that are in the code path triggered
>> before the full initialization of the logging
>> system.
>
> I thought we identified a known issue and you have workaround it but still use method reference.  It’s okay to leave this one as is.  We had reworked the system initialization to enable lambda to be used very early when module system is initialized (after VM init phase 1 completes).  If you run into any issue, it’s likely a bug.
>
> Mandy
>



More information about the core-libs-dev mailing list