RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

Peter Levart peter.levart at gmail.com
Fri Sep 12 11:55:17 UTC 2014

On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>> However the listeners are to be invoked in the same order they have been
>> added.
> I am still unconvinced this is worth the additional
> complexity it would bring to the implementation.
> The deprecated methods were using HashMap to store listeners,
> and therefore the order in which listeners were invoked was also
> undefined. Nobody has ever complained.

What about using a synchronized LinkedHashMap<ListenerAction, 
ListenerAction>() with the following double-purpose inner class:

     private static final class ListenerAction implements 
PrivilegedAction<Void> {
         private final Runnable listener;
         private final AccessControlContext acc;

         ListenerAction(Runnable listener, AccessControlContext acc) {
             this.listener = listener;
             this.acc = acc;

         void invoke() {
             if (acc == null) {
             } else {
                 AccessController.doPrivileged(this, acc);

         // not to be run() directly - use invoke() instead
         public Void run() {
             return null;

         public int hashCode() {
             return System.identityHashCode(listener);

         public boolean equals(Object obj) {
             return (obj instanceof ListenerAction) &&
                    ((ListenerAction) obj).listener == listener;

> (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431) 
>> I'd rather run the listeners in try/catch and throw the 1st exception at
>> the end.
>> Defining the 1st however requires obeying the order the listeners have
>> been added.
>> As far as I see there is no documentation how the listeners are supposed
>> to behave or be invoked.
> We could do that - invoke all listeners and rethrow the exception
> caught by the first listener that failed (on the basis that if any other
> listener subsequently fails it may be because the previous listener
> has left the system in an inconsistent state, and that therefore
> the first exception caught has 'more value' than the others).
> I am not completely convinced this is a better behavior than
> simply stopping invoking listeners at the first exception.
> I wonder if there would be a good wording to say that listeners
> are not supposed to throw, but that if they do, the exceptions
> will be propagated...

You're probably right. But in case you changed your mind, you could 
rethrow the 1st exception thrown, with possible further exceptions added 
to it a suppressed exceptions...

Regards, Peter

> best regards,
> -- daniel 

More information about the core-libs-dev mailing list