When Java first came out, it advocated shared memory multi-threading as the way of handling concurrency and parallelism. Over the last 20 years, Java has slowly been evolving away from this dire decision. Also over the last 20 years, the JVM has ceased being an engine just for Java but has been bringing new languages onto the platform: Groovy, JRuby, Clojure, Kotlin, Ceylon, to name just a few. Often the new languages had features that Java coveted and eventually incorporated, directly or indirectly. Recent mutterings of supporting coroutines so as to deal with single threaded, I/O focused concurrency appear to show envy of Node and JavaScript. Is this a good feature for JVM-based languages to covet? Why not properly support channels and lightweight processes as Go has? Or channels and heavyweight processes as Rust has? Is it that the JVMverse already has such ways of working with concurrency and parallelism, and people do not know about them, or is it that the JVMverse is bereft of doing concurrency and parallelism correctly? Is a 1950s single CPU, operating system viewpoint on concurrency and parallelism still relevant in 2018?

In this session, we will unpack some aspects of this – dictated by interaction with the audience.