<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Related, there are no changes needed to Java to implement efficient generators using virtual threads. See <a href="https://github.com/robaho/generators">https://github.com/robaho/generators</a></div><div dir="ltr"><br><blockquote type="cite">On Jan 13, 2026, at 6:35 AM, Michael van Acken <michael.van.acken@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb Andrew Haley <<a href="mailto:aph@redhat.com">aph@redhat.com</a>>:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/01/2026 07:45, Michael van Acken wrote:<br>[...]<br>
> I have been thinking about this as well, what the difference between<br>
> various perspectives/designs actually is.<br>
> <br>
> My first and up to now only idea: a thread comes with hard promises about<br>
> what things will happen in the future.<br>
> <br>
> Its accumulated call/handler stack is a batch of unfinished business that<br>
> is guaranteed to be worked upon.<br>
<br>
That would be a major change to Java. People tend to assume that threads <br>
will make progress "eventually", but there can be no guarantees.</blockquote><div><br></div><div>Thank you for pointing this out. It made me aware just how much my</div><div>thinking is predicated around the idea that a method call does complete</div><div>in either of two ways. Of course, even a simple endless loop prevents </div><div>completion, nor is there any guarantee that it happens before JVM exit.</div><div><br></div><div>Non-completion comes to my mind usually in the negative "How do I prevent</div><div>this piece of code from ending up not completing?" (trying to avoid anticipated</div><div>future pain), or from trying to find out why something unexpectedly hangs. In the</div><div>latter case I am grateful for any support the JVM gives me to narrow the problem</div><div>down, closing the circle to the observability mechanisms mentioned earlier in this</div><div>thread.</div><div><br></div><div>Up to now, a method call not completing is for me either something that should</div><div>be avoided or is an abnormal program condition. Actively embracing this in places </div><div>other than e.g. a thread's top-level method would require some adjustment on my part.</div><div><br></div><div>-- mva</div><div><br></div></div></div>
</div></blockquote></body></html>