It starts to be off topic, but it's not clear to me that in Java we want to map a generator to an iterator and not to stream (a push iterator with a cleanup semantics).
regards, Rémi > From: "Alex Otenko" <[email protected]> > To: "Alan Bateman" <[email protected]> > Cc: "loom-dev" <[email protected]> > Sent: Tuesday, January 13, 2026 10:28:13 AM > Subject: Re: [External] : Re: Ephemeral threads > Yes, I understand that now that's not easy to do in Java. I just don't think > it's all that exotic, and certainly not a bug. After all, we've all written at > least one iterator when we did a coding interview. > There is 1:1 correspondence between the iterators and the generators. So if we > can GC the iterators without special dance, we should be able to do that for > the generators. You could see an iterator as an explicit declaration that you > are not going to use any features that rely on there being a finally - no > unlocking, no resource management outside of what a finalizer can achieve, no > peer to coordinate with, etc. Likewise an explicit declaration by an engineer > that this here piece of code entering a wait is perfectly fine to GC, doesn't > seem all that different. > Yes, in general there are thread semantics, try-finally, reference loops and > other obstacles - but we don't need to solve a general case, just the one that > is in 1:1 correspondence with the iterators. > I understand that there may be safe ways to implement the same with the > existing > mechanisms - like, the user of the generator might wrap the interaction in a > try-with-resource, and that way control the lifecycle explicitly. > On Tue, 13 Jan 2026, 08:00 Alan Bateman, < [ mailto:[email protected] | > [email protected] ] > wrote: >> On 13/01/2026 06:42, Alex Otenko wrote: >> > I think there are plenty of designs with generators, iterators and >> > async where non-termination is not a bug. >> That is true is some other languages/runtimes. If Java were to add >> generators or some other exotic control flow in the future then there >> would be more spooky issues to work through, some of which overlap with >> the spooky issues that have come up in the discussion here. >> -Alan
