JEP 264: Platform Logging API and Service

[Daniel Fuchs]

Thanks Roger!

I have updated the specdiff online.
http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html

The only comment I haven't taken into account yet is this:

 >   - the LoggerFinder constructor says "Only one instance will be 
created".
 >     That applies to the normal static logger initialization
 > (getLoggerFinder).
 >     But there might be other cases where the application or service
 > might create a LoggerFinder
 >     for its own purposes, and the phrase is not accurate in that case.

I was wondering whether I should try enforcing this actually, by
throwing a ServiceConfigurationError or whatever if the
LoggerFinder service is already loaded when the constructor
is invoked.

We had trouble in the past with LogManager - because the spec
said there should be only one instance, but the implementation
did not enforce it.
It may be a bit different with LoggerFinder - as this is an
abstract class devoid of instance state (the only method with a
body is getLocalizedLogger and that's stateless) - so there may
not be as much harm as with LogManager.

There is probably no good way of implementing such enforcement
though - so it would be a best effort :-(

best regards,

-- daniel


On 05/10/15 16:06, Roger Riggs wrote:
> Hi Daniel,
>
> This looks good, a few comments...
>
> j.l.System:
>    - the behaviors described by the @implNote in getLogger(name) and
>      @implSpec in getLogger(name, resourceBundle) seem like they should
> be consistent
>      for the two methods.
>
> System.Logger:
>   - log(level, throwable, Supplier) - to be more consistent, the
> Suppler<String> argument
>     should be before the Throwable argument.
>     Then in all cases the msg/string is before the Throwable.
>
> System.Logger.Level
>   - TRACE might be used for more than just method entry and exit,
> perhaps the description can be more
>     general: "usually used for diagnostic information."
>
> LoggerFinder:
>
>   - should the CONTROL_PERMISSION field be renamed to
> "LOGGERFINDER_PERMISSION"?
>
>   - the LoggerFinder constructor says "Only one instance will be created".
>     That applies to the normal static logger initialization
> (getLoggerFinder).
>     But there might be other cases where the application or service
> might create a LoggerFinder
>     for its own purposes, and the phrase is not accurate in that case.
>
>
> Editorial:
>   - The @since tags can be set to "9".
>
>   - "JVM" -> "Java runtime";  JVM would specifically refer to the
> virtual machine implementation.   (j.u.System.LoggerFinder)
>
>   - "used by the JDK" can be omitted.  (j.u.System.LoggerFinder)
>     When used in the context of the JDK documentation itself it seems
> out of place and is unnecessary.
>
>   - the word 'actually' can/should be omitted from descriptions.
> (j.l.System)
>
> Thanks, Roger
>
>
> On 10/5/2015 6:54 AM, Daniel Fuchs wrote:
>>> New JEP Candidate: http://openjdk.java.net/jeps/264
>>
>> Hi I have uploaded an initial prototype specdiff:
>>
>> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html
>>
>>
>> LoggerFinder methods that take a Class<?> caller argument
>> will take a java.lang.reflect.Module callerModule instead when
>> that is  available in jdk9/dev.
>>
>> comments welcome,
>>
>> best regards,
>>
>> -- daniel
>>
>