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
