On Wed, 14 Oct 2026 09:42:30 GMT, Serguei Spitsyn <[email protected]> wrote:
> Thank you for taking care about this issue. However, I'd prefer to go in an > opposite direction and align the extension events behavior with normal > events. I'll file a separate enhancement to get rid of this spec wording: > `... and enables the event. Or, if the callback is null, disables the event. > Note that unlike standard events, setting the callback and enabling the event > are a single operation.` This approach will cause a minor compatibility > issue, of course. But it is important to achieve a symmetry with normal > events here and get rid of unneeded complexity. Just a note about your fix... > It is correct in general. However, it is over-passing the capability checks > which SetEventNotificationMode has (e.g.`can_support_virtual_threads` > cpability for `VirtualThreadMount`/`VirtualThreadUnmount` extension events). > Please, let me know about your opinion. Thanks, I agree that callback registration and event enabling should be separate, as with standard events. My patch follows the current spec, but it also changes when existing agents start receiving notifications. Updating the spec through JDK-8394716 makes more sense to me. Thanks for filing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33295#issuecomment-6209604147
