RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code

[Sundararajan Athijegannathan]

+1. It is better not to fix this bug.

-Sundar

On 24/08/18, 7:36 PM, Daniel Fuchs wrote:
> 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