JEP 264: Platform Logging API and Service

Peter Levart peter.levart at
Wed Sep 30 07:46:56 UTC 2015

On 09/29/2015 11:17 PM, Ralph Goers wrote:
> 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

Hi Ralph,

ServiceLoader can be used to load all services that implement a 
particular type (it's an Iterable). So you can decide which one(s) to 
use in your own logic. You just have to design the service type in a way 
where it's implementations expose some attributes that are relevant for 
selection and initialize the underlying service lazily, after selection 
is done. This would usually mean that the service interface/abstract 
class implements a factory for the real service and exposes some 
properties such as version, priority, etc...

Would that work for Log4j?

Regards, Peter

>> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fuchs at> wrote:
>> On 20/09/15 15:46, Peter Levart wrote:
>>> On 09/18/2015 06:17 PM, mark.reinhold at wrote:
>>>> New JEP Candidate:
>>>> - 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

More information about the core-libs-dev mailing list