<div dir="ltr"><div dir="ltr"><div dir="ltr">Having read the thread in its entirety, my (uncalled for) $0.02 is that I agree with</div><div dir="ltr">Maurizio here:<div><br></div><div>> I think API-wise, this is easy to do. Could become (as you say) a no-op</div>in the future (or changed to implement the best practice "du jour"), or<br>even be deprecated if no longer needed.<br></div><div dir="ltr"><br></div><div><div>It seems beneficial to me to be able to mark methods with extra metadata about</div><div>whether or not they are intended to block. Especially with the growth of io_uring</div><div>on Linux and IoRing on Windows, I imagine folks might be linking to API's which</div><div>implement a dual blocking/non-blocking IO API.</div></div><div><br></div><div>On the other hand I'm not a JDK maintainer and don't know what kind of burden</div><div>this would add to implement and maintain.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 14, 2023 at 12:54 PM Brian S O'Neill <<a href="mailto:bronee@gmail.com">bronee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's not the same process. Optimize first and then measure isn't the <br>
same as measure first and then optimize. Because the Blocker class <br>
exists and is in use, how can you measure what affect it has for real <br>
applications compared to it not existing? Perhaps it should be off by <br>
default and then be enabled with a system property?<br>
<br>
On 2023-07-14 09:37 AM, Ron Pressler wrote:<br>
> <br>
> <br>
>> On 14 Jul 2023, at 16:19, Brian S O'Neill <<a href="mailto:bronee@gmail.com" target="_blank">bronee@gmail.com</a>> wrote:<br>
>><br>
>> This sounds reasonable, but the current "wait and see" model is inconsistent. JEP 444 says, use JFR and we'll get back to you. Was this process followed when the decision was made to add the Blocker class, or is it a premature optimization that should be removed?<br>
> <br>
> It is the same process, and we’re still in the "wait and see” phase for Blocker, too, as it’s not part of any spec (and we’d love to get rid of of its uses eventually). It’s not a premature optimisation that’s at issue here at all because what you’re proposing isn’t an internal optimisation but a change to the specification before we know whether and how to best do it. If it were just an optimisation it’s conceivable we could find the time to do it in the near future, but what you’re talking about is a premature spec change.<br>
> <br>
> — Ron<br>
</blockquote></div>