JEP 264: Platform Logging API and Service

[Ralph Goers]

FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a “priority” - the binding with the highest priority wins - at the moment. At some future time we might consider supporting multiple bindings.

It would have been nice if ServlceLoader could be extended by the user to do these sort of checks instead of not being able to use it at all.

Ralph

> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> On 20/09/15 15:46, Peter Levart wrote:
>> 
>> 
>> On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
>>> New JEP Candidate:http://openjdk.java.net/jeps/264
>>> 
>>> - Mark
>> 
>> Hi,
>> 
>> What is the purpose of exposing a factory for loggers in the generally
>> exported package (java.lang) and making it standard Java API as opposed
>> to keeping it internal API as it is now
>> (sun.util.logging.PlatformLogger)? Is this going to become an official
>> front-end for JDK-internal and applications use, available in the
>> platform itself?
> 
> Hi Peter,
> 
> sun.util.logging.PlatformLogger is a module private API in
> java.base, yet it is used by other modules in the JDK - and
> this requires qualified exports to the modules that use it.
> Having a public API that JDK modules could use would simplify
> the module graph in this respect.
> 
> In time, I'd hope to see sun.util.logging.PlatformLogger disappear
> in favor of the public API.
> 
>> Otherwise I think it's good to add support for interfacing other
>> backends (besides JDK14 Logging and stderr) to platform logger. If one
>> wants to interface some other backend to platform logger now, it's
>> actually doable, but only via the intermediate JDK14 Logging API, like this:
>> 
>> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND
>> 
>> Adding support to skip JDK14 Logging would simplify configuration and
>> make it more lightweight.
> 
> Yes - the goal of the LoggerFinder service API is to make it possible
> for applications - or frameworks - to provide their own implementation.
> 
> best regards,
> 
> -- daniel
> 
>> 
>> Regards, Peter
>> 
> 
>