`select` statement for Java

[Ryan Schmitt]

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
>
>