Hi Harsha,
On 23/08/2018 17:35, Daniel Fuchs wrote:
So all in all - maybe this is worth fixing but better early
in the release than late. I also wonder whether such a behavior
change should deserve a release note (or a switch to revert
to the old behavior - though I do hope that isn't necessary).
On second thought - it occurred to me that what you are proposing
to do in the platform could very well be implemented in the
client (listener) code instead.
The workaround would be simple:
-------------------------------
package com.foo.monitoring;
import javax.management.*;
final class PlatformMXBeaNotificationListener implements
NotificationListener {
private final NotoificationListener delegate;
PlatformMXBeaNotificationListener(NotoificationListener delegate) {
this.delegate = delegate;
}
public void handleNotification(Notification notification,
Object handback) {
executor.execute(() ->
delegate.handleNotification(notification, handback));
}
private static final Executor executor
= Executors.newSingleTreadExecutor();
}
--------------------------------
This way the threading would remain in control of the
client application, and the debugger would be able to
step in the delegate's handleNotification(...) method?
Given the unquantifiable risk posed by changing the threading
model in the platform, then maybe leaving the current
implementation as is and documenting that workaround
leaving it up to the client code to decide whether to use
that or not, would be the better idea?
best regards,
-- daniel
