`select` statement for Java

[Alex Otenko]

I was about to say that.

The benefit of select is not syntactic. It is the non-deterministic choice.
In the case of Go it is a bunch of channels. In case of Java there is nio
API for epoll, but no such thing for queues. Being able to inspect which
queues are ready, is something asynchronous code can do, but blocking code
can't.

Alex

On Mon, 3 Feb 2020, 23:32 Ryan Schmitt, <rschmitt at pobox.com> wrote:

> I've lurked on these mailing lists for a long time, and I promise this is
> not one of those "why don't you just" questions. I make reference to Go's
> `select` statement only as a convenient analogy for the kind of
> "multi-block" functionality I'm thinking about. What is interesting to me
> about this problem is that I don't see a way to implement any kind of
> functionality like this, *except on top of asynchronous code*. I'm not
> aware of any primitives in Java that you could use to build multiplexed
> blocking operations, such as blocking on multiple `BlockingQueue`
> instances. I'm curious to hear what the experts think of this problem.
>
> On Mon, Feb 3, 2020 at 2:21 PM John Rose <john.r.rose at oracle.com> wrote:
>
> > On Feb 3, 2020, at 10:38 AM, Ryan Schmitt <rschmitt at pobox.com> wrote:
> > >
> > > Are there any current or planned constructs in Java that allow blocking
> > on
> > > multiple streams of events simultaneously, similar to the `select`
> > > statement in Go? I realize that technically speaking this is probably
> > > orthogonal to Loom, but it seems like an important capability in order
> to
> > > get the most out of the blocking, imperative thread abstraction that
> Loom
> > > is fundamentally about.
> >
> > That’s easy to answer, in a literal sense:  No, Java is not likely
> > ever to have a bespoke “select” syntax, just as it is not likely ever
> > to have the SQL-like keywords of LINQ, or the COMMON statement
> > of Fortran or the PICTURE statement of Cobol.  Java invests
> > complexity in API richness, so that the existing language constructs,
> > combined with well-designed APIs, produce readability without
> > the need for a long catalog of special-purpose syntaxes.
> >
> > In a less literal, but more useful sense:  Yes, Java is likely to have
> > a notation which covers the same ground as  “select”.  If I had to
> > guess, I’d say that when pattern-matching switches go live, somebody
> > will build APIs which use such switches much as Go uses its special
> > “select” statement.  This “notation” (not “syntax”) is mostly API,
> > with careful use of syntax.
> >
> > Yes, the syntax of Java does expand, but almost never for single
> > purposes; it always expands in ways that serve many APIs, including
> > those not yet conceived of.  *That* is how we grow a language.
> >
> > https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
> > https://www.youtube.com/watch?v=_ahvzDzKdB0
> >
> > A less general, perhaps more useful answer can be obtained by
> > looking at the existing API points for threads and channels, and
> > asking “Does Loom support these with good quality?”  And also,
> > “What is the best notation for using these API points, in today’s
> > Java syntax?”  And finally, after those questions are answered,
> > “Which proposals for future syntax changes are likely to those
> > API usages more readable?”  And with vanishing rarity, “Are we
> > missing a future syntax proposal that would make this and many
> > other notations markedly clearer and more robust?”  None of
> > these questions is answered by “Hey, we forgot to add Go’s select
> > syntax!”
> >
> > — John
> >
> >
>