Project Loom? Better Futures? What’s next for JVM concurrent programming
summary
Project Loom introduces virtual threads and continuations to the JVM, making threads cheap to create and block so thousands can run while the JVM schedules them on a small set of kernel threads; development starts in 2017 and early‑access builds exist. It retrofits blocking JDK APIs to block virtual threads, but orchestration still needs abstractions: futures remain useful for composition and IOs as lazy descriptions solve cancellation, uninterruptible regions and composability issues that Loom alone does not. The net claim: better sequential readability, not a full replacement for concurrency libraries.
AI-written summary · about
chapters (9)
- 0:00Start
- 5:25Current solutions Thread pooling
- 9:32Problems with Future • lost control flow • lost context
- 10:36What is Loom? Virtual threads
- 11:52What is Loom? Retrofit
- 14:54Problems with threads • communication • orchestration • interruption
- 15:53Thread communication/ synchronization • semaphores
- 17:32Towards declarative concurrency
- 22:19Better Futures What kind of high-level operations might we expect?
related talks
01h 00mProject Loom? Better Futures? What’s next for JVM concurrent programming
50mProject Loom: Helping Write Concurrent Applications on the Java Platform
51mWhat's Looming in Java The Why and What of Project Loom
44mLoom: Revolution or Implementation Detail?
01h 13mProject loom: Modern scalable concurrency for the Java platform
39mProject Loom: Modern Scalable Concurrency for the Java Platform
42mProject Loom Update
43mProject Loom: Fibers and Continuations for the Java Virtual Machine