AMA About the Java Language — Brian Goetz and Nicolai Parlog
Why Stack Overflow recommends it
Stack Overflow users link it as the source of Brian Goetz's remark that Project Loom will kill reactive programming, when arguing that virtual threads remove the need for reactive frameworks.
Recommended by 1 people across 2 different months, 2021 to 2024.
What it is
A one-hour Q&A session from Philly ETE 2021 in which Brian Goetz, who led Java language evolution, answers audience questions about where Java is heading and why past design choices were made. Nicolai Parlog facilitates the questions.
What people said
Recommends Basil Bourque · 2024-04 · Stack Overflow · on “Do Java 21 virtual threads address the main reason to switch to reactive single-thread frameworks?”
Yes, virtual threads eliminate the need for reactive approach Platform threads in Java are mapped directly to a thread host operating system thread. Those OS threads are “expensive” in terms of memory and CPU. Virtual threads, in contrast, are managed within the JVM. As a result, virtual threads are extremely “cheap”, meaning they are quite efficient in both memory and CPU. With virtual threads, you can reasonable expect to run even millions of tasks simultaneously on common computer hardware. Yes, most, if not all, of the work done as reactive code can be done instead with Java virtual threads. The coding is vastly simpler to write, comprehend, trace, and debug . Reactive approach was inven
Recommends Basil Bourque · 2024-10 · Stack Overflow · on “Reactive API needs to call parallel downstream APIs and await responses”
Reactive unneeded Reactive programming was a transitional technology created to maximize the performance of multithreaded workloads. Unfortunately, reactive programming is confusing, difficult to reason about, and nearly impossible to debug. With the creation of virtual threads in Project Loom [LINK] for Java, the need for reactive largely evaporates. See Do Java 21 virtual threads address the main reason to switch to reactive single-thread frameworks? [LINK] , and video [this video] with Brian Goetz. With virtual threads you get the high-performance of reactive, but also the simplicity of straightforward code, plus you can leverage all the debugging and thread-tracking features of our existing t
Cites lkatiforis · 2021-09 · Stack Overflow · on “Is there proposal for introducing reactive programming constructs in Java/JakartaEE?”
Java 9 has introduced the Flow API [LINK] , which enables us to adopt Reactive Programming using just the JDK. However, Flow API is just an API, does not implement the Reactive specification. Brian Goetz, one of the architects of the Java language, said: " I think Project Loom is going to kill Reactive Programming " ( interview link [this video] ) That being said, I think, the need for additional libraries such as Project Reactor or RxJava will be necessary.
Cites Thomas Schütt · 2024-07 · Stack Overflow · on “Reactive Programming Advantages/Disadvantages”
Virtual threads Since Java 21 [LINK] with its cheap virtual threads [LINK] the one exclusive plus of reactive programming (namingly not to consume lots of expensive native threads caused by slow IO) is not existent any more. See video [this video] of Brian Goetz [LINK] being asked what he sees as the future of reactive programming after the arrival of Project Loom [LINK] and virtual threads: I think Loom is going to kill reactive programming … reactive programming was a transitional technology … I am curious to see what will happen to reactive programming, at least in the JVM world. Not being able to use ThreadLocal is a big minus of reactive programming.