RFR: JDK-8046565: Platform Logger API and Service

[Daniel Fuchs]

Hi Stephen,

On 15/10/15 12:48, Stephen Colebourne wrote:
> On 14 October 2015 at 12:20, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> On 14/10/15 07:21, Mandy Chung wrote:
>>> Several log methods throws NPE if the level is legible and the parameter
>>> is null.  E.g.
>>> * @throws NullPointerException if {@code level} is {@code null}, or if the
>>> level
>>> *         is loggable and {@code msgSupplier} is {@code null}.
>>>
>>> Should it throw NPE if the input parameter is null regardless of whether
>>> the level is loggable?
>>
>>
>> Yes probably. The reason it is like that is that it mimics
>> what java.util.logging.Logger does (at least for message suppliers), but
>> it is probably not a good idea to propagate this bad practice.
>>
>> I will change System.Logger spec to mandate to always throw NPE
>> if Supplier<String> is null - and ensure that the implementations
>> we have follow the spec.
>
> I believe the desire in logging is to a sensible degree write
> defensively to avoid getting an exception due to logging which
> obscures the actual error.
>
> Thus, log(level, msg) should accept a null message (but not a null level)
> But, log(level, supplier) should not accept a null supplier or level

Yes exactly. I agree.

> The Javadoc for 'System.Logger' starts with "The minimum set of
> methods that a logger returned by..." which isn't a good description
> of the interface.

Right. Mandy already told me that :-) Working on finding a better
wording.


> I have a major concern that the class names 'Logger' and 'Level'
> duplicate those of java.util.logging. While they are inner classes as
> opposed to top level classes, both IntelliJ and Eclipse will find the
> inner class and top level class when typing "Logger". This will no
> doubt cause many users to import the wrong one. I propose that these
> classes are renamed to avoid this problem. The simplest would be to
> change them from inner classes to top level classes "System.Logger" ->
> "SystemLogger". Alternatively, they could stay as inner classes and be
> prefixed "System.Logger" -> "System.SysLogger" or "System.Logger" ->
> "System.BasicLogger".

I usually like to avoid to have two classes with the same
name in different packages. As you say it can be confusing
when you mistakenly import the wrong one.

In NetBeans - when doing name completion, System.Logger
appears with a different font than j.u.l.Logger because it
is an interface. And if you search the file - then obviously
it is not proposed because it's an inner interface.

After having worked with it for some time I find that using
inner interfaces/classes for Logger and Level is not that
bad. Certainly better than if it was a top-level class of
the same name. It is fortunately rare that you need to use
both (the System. and the j.u.l one) in the same class.

It's hard to find a compelling new name though :-)

best regards,

-- daniel
>
> Stephen
>