JetBrains presents a practical look at three Project Loom components inside IntelliJ IDEA in a blog post published on August 27, 2026: Virtual Threads, Scoped Values, and Structured Concurrency. The central idea is not to add separate APIs, but to address three interconnected problems in concurrent Java applications: scalability, passing context between tasks, and managing thread lifecycles and errors.
The article explains that writing multithreaded code remains vulnerable to thread leaks, swallowed exceptions, race conditions, and delayed cancellation. Traditional reliance on thread pools and CompletableFuture can also distribute cancellation and error-handling logic across several branches, increasing the likelihood that it will not be updated when a new concurrent task is added.
Virtual Threads Reduce the Cost of Waiting
Virtual threads are based on JEP 444 and have been stable since Java 21. Unlike platform threads, which are tied to operating-system threads, virtual threads are managed by the JVM and can be created at a much lower cost. JetBrains notes that creating a virtual thread takes microseconds rather than milliseconds, and that the thread releases its platform thread when it waits for a database, network connection, file, or synchronization mechanism.
This makes them particularly suitable for workloads that depend on blocking operations, reducing the need to configure thread-pool sizes in advance. The article also notes that Java 24 introduced, through JEP 491, an improvement allowing virtual threads blocked inside synchronized methods or statements to release their platform thread instead of keeping it occupied.
Shared Context Without ThreadLocal Problems
Scoped Values, stable since Java 25 according to JEP 506, address a different problem. Applications often need to pass data such as a session ID or trace ID to multiple parts of a request. This was commonly done with ThreadLocal, but its values are mutable and remain associated with the thread's lifetime unless manually removed, which can lead to memory leaks or security issues. JetBrains notes that frameworks such as Spring may use ThreadLocal internally even when the developer does not use it directly.
ScopedValue provides a model in which a value is bound once within a specific scope, then automatically made available to the code running inside it and cleaned up when the scope ends. The binding cannot be modified from inside the scope, and the value is inherited by child tasks when used with structured concurrency without explicitly passing the context. In practice, this reduces the number of control points that developers need to track when executing parallel tasks.
Structured Concurrency Gives Tasks a Defined Lifetime
Structured Concurrency, based on JEP 533, targets structural problems in concurrent code. However, it is still in its seventh preview in Java 27, so JetBrains does not recommend using it in production environments yet. The concept is based on treating a group of related tasks as a single unit of work with an owner, a lifetime, and a clear failure policy.
In the example presented by JetBrains, the application fetches a customer's order history and product recommendations in parallel to build a customer profile. Using StructuredTaskScope, it is possible to set a two-second timeout, require both tasks to succeed, and automatically cancel the other task if one fails or the timeout expires. Instead of repeating cancel() calls in exception-handling branches, the cancellation policy becomes part of the task scope.
The article also explains a different case that does not require every task to succeed: if the application obtains recommendations from two caches and only needs the first successful response, it can use anySuccessfulOrThrow(). When a successful result arrives, the scope is closed and the other task is automatically cancelled; if both tasks fail, an exception explaining the reason for the failure is thrown.
What Changes Inside IntelliJ IDEA?
The benefit is not limited to code syntax. Since IntelliJ IDEA 2026.1, virtual threads created inside StructuredTaskScope are grouped into containers representing their scopes, making the relationship between the parent task and child tasks visible in the debugger. As a result, the thread dump does not show only a flat list of threads from a general pool, but provides a better indication of which tasks belong to the same request.
To try these features, developers need Java 27, which was an Early Access version according to the article, and must set the language level to use preview features. IntelliJ IDEA provides JDK downloads from the project settings and displays inline hints when tools such as SDKMAN! or asdf are used to manage JDK versions. An initial structure for StructuredTaskScope can be created using the sts live template.
The Editorial Perspective from certi.news
The actual change here is the transfer of part of concurrency management from the developer's manual responsibility to a model in which the code's structure expresses the task's lifetime and failure policy. Virtual Threads address the cost of scaling, Scoped Values regulate context propagation, while Structured Concurrency attempts to make cancellation and error propagation predictable. Together, these features may reduce repetitive code in applications that perform multiple waiting operations in parallel.
However, the limits of the current development are clear: Structured Concurrency has not yet become stable, and Java 27 was an Early Access release when the article was published. Therefore, the blog post does not prove that every application will automatically achieve an improvement, nor does it eliminate the need to test how the libraries and frameworks in use behave with these models. The current value for developers lies in understanding the pattern and experimenting with it safely, while keeping preview features out of production until their APIs stabilize and sufficient operational experience becomes available.