JEP 264: Platform Logging API and Service

Roger Riggs Roger.Riggs at Oracle.com
Mon Oct 5 14:06:08 UTC 2015


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
>




More information about the core-libs-dev mailing list