Releases: Kotlin/kotlinx.coroutines
Releases · Kotlin/kotlinx.coroutines
0.30.1
Maintenance release:
- Added
Dispatchers.Main
to common dispatchers, which can be used from Android, Swing and JavaFx projects if a corresponding integration library is added to dependencies. - With
Dispatchers.Main
improvement tooling bug in Android Studio #626 is mitigated, so Android users now can safely start the migration to the latestkotlinx.coroutines
version. - Fixed bug with thread unsafety of shutdown sequence in
EventLoop
. - Experimental coroutine dispatcher now has
close
contract similar to JavaExecutor
, so it can be safely instantiated and closed multiple times (affects only unit tests). - Atomicfu version is updated with fixes in JS transformer (see #609)
0.30.0-eap13
- Features based on version
0.30.0
- Uses Kotlin version
1.3.0-rc-57
- Uses Kotlin/Native version
0.9.2
- Replace buildSequence and buildIterator with sequence and iterator
- Apply @BuilderInference on all builders (including extension methods to workaround inference bug)
0.30.0
- [Major] Further improvements in exception handling — no failure exception is lost.
async
and async-like builders cancel parent on failure (it affectsCompletableDeferred
, and all reactive integration builders).- This makes parallel decomposition exception-safe and reliable without having to rember about
awaitAll
(see #552). Job()
wih parent now also cancels parent on failure consistently with other scopes.- All coroutine builders and
Job
implementations propagate failure to the parent unless it is aCancellationException
. - Note, "scoping" builders don't "cancel the parent" verbatim, but rethrow the corresponding exception to the caller for handling.
SupervisorJob()
andsupervisorScope { ... }
are introduced, allowing for a flexible implementation of custom exception-handling policies, see a new section in the guide on supervision.- Got rid of
awaitAll
in documentation and rewrotecurrentScope
section (see #624).
- [Major] Coroutine scheduler is used for
Dispatchers.Default
by default instead of deprecatedCommonPool
.- "
DefaultDispatcher
" is used as a public name of the default impl (you'll see it thread names and in the guide). -Dkotlinx.coroutines.scheduler=off
can be used to switch back toCommonPool
for a time being (until deprecated CommonPool is removed).
- "
- Make
CoroutineStart.ATOMIC
experimental as it covers important use-case with resource cleanup in finally block (see #627). - Restored binary compatibility of
Executor.asCoroutineDispatcher
(see #629). - Fixed OOM in thread-pool dispatchers (see #571).
- Check for cancellation when starting coroutine with
Dispatchers.Unconfined
(see #621). - A bunch of various performance optimizations and docs fixes, including contributions from @AlexanderPrendota, @PaulWoitaschek.
0.27.0 Public API review
Version 0.27.0
- [Major] Public API revision. All public API was reviewed and marked as preparation to
1.0
release:@Deprecated
API. All API marked as deprecated will be removed in 1.0 release without replacement.@ExperimentalCoroutinesApi
API. This API is experimental and may change in the future, but migration mechanisms will be provided. Signature, binary compatibility and semantics can be changed.@InternalCoroutinesApi
. This API is intended to be used only from withinkotlinx.coroutines
. It can and will be changed, broken
and removed in the future releases without any warnings and migration aids. If you find yourself using this API, it is better to report
your use-case to Github issues, so decent, stable and well-tested alternative can be provided.@ObsoleteCoroutinesApi
. This API has serious known flaws and will be replaced with a better alternative in the nearest releases.- Regular public API. This API is proven to be stable and is not going to be changed. If at some point it will be discovered that such API
has unfixable design flaws, it will be gradually deprecated with proper replacement and migration aid, but won't be removed for at least a year.
- [Major] Job state machine is reworked. It includes various performance improvements, fixes in
data-races which could appear in a rare circumstances and consolidation of cancellation and exception handling.
Visible consequences of include more robust exception handling for large coroutines hierarchies and for different kinds ofCancellationException
, transparent parallel decomposition and consistent view of coroutines hierarchy in terms of its state (see #220 and #585). - NIO, Quasar and Rx1 integration modules are removed with no replacement (see #595, #601, #603).
withContext
is now aligned with structured concurrency and awaits for all launched tasks, its performance is significantly improved (see #553 and #617).- Added integration module with Play Services Task API. Thanks @SUPERCILEX and @lucasvalenteds for the contribution!
- Integration with Rx2 now respects nullability in type constraints (see #347). Thanks @Dmitry-Borodin for the contribution!
CompletableFuture.await
andListenableFuture.await
now propagate cancellation to the future (see #611).- Cancellation of
runBlocking
machinery is improved (see #589). - Coroutine guide is restructured and split to multiple files for the sake of simplicity.
CoroutineScope
factory methods addJob
if it is missing from the context to enforce structured concurrency (see #610).Handler.asCoroutineDispatcher
has aname
parameter for better debugging (see #615).- Fixed bug when
CoroutineSchedule
was closed from one of its threads (see #612). - Exceptions from
CoroutineExceptionHandler
are reported by default exception handler (see #562). CoroutineName
is now available from common modules (see #570).- Update to Kotlin 1.2.70.
0.26.1
Version 0.26.1
- Android
Main
dispatcher isasync
by default which may significantly improve UI performance. Contributed by @JakeWharton (see #427). - Fixed bug when lazily-started coroutine with registered cancellation handler was concurrently started and cancelled.
- Improved termination sequence in IO dispatcher.
- Fixed bug with
CoroutineScope.plus
operator (see #559). - Various fixes in the documentation. Thanks to @SUPERCILEX, @yorlov, @dualscyther and @soudmaijer!
0.26.0: Structured concurrency
- Major rework of
kotlinx.coroutines
concurrency model (see #410 for a full explanation of the rationale behind this change):- All coroutine builders are now extensions on
CoroutineScope
and inherit itscoroutineContext
. Standalone builders are deprecated. - As a consequence, all nested coroutines launched via builders now automatically establish parent-child relationship and inherit
CoroutineDispatcher
. - All coroutine builders use
Dispatchers.Default
by default ifCoroutineInterceptor
is not present in their context. - CoroutineScope became the first-class citizen in
kolinx.coroutines
. withContext
block
argument hasCoroutineScope
as a receiver.- GlobalScope is introduced to simplify migration to new API and to launch global-level coroutines.
currentScope
andcoroutineScope
builders are introduced to extract and provideCoroutineScope
.- Factory methods to create
CoroutineScope
fromCoroutineContext
are introduced. CoroutineScope.isActive
became an extension property.- New sections about structured concurrency in core guide: "Structured concurrency", "Scope builder" and "Structured concurrency with async".
- New section in UI guide with Android example: "Structured concurrency, lifecycle and coroutine parent-child hierarchy".
- Deprecated reactive API is removed.
- All coroutine builders are now extensions on
- Dispatchers are renamed and grouped in the Dispatchers object (see #41 and #533):
- Dispatcher names are consistent.
- Old dispatchers including
CommonPool
are deprecated.
- Fixed bug with JS error in rare cases in
invokeOnCompletion(onCancelling = true)
. - Fixed loading of Android exception handler when
Thread.contextClassLoader
is mocked (see #530). - Fixed bug when
IO
dispatcher silently hung (see #524 and #525).
0.25.3
- Distribution no longer uses multi-version jar which is not supported on Android (see #510).
- JS version of the library does not depend on AtomicFu anymore:
All the atomic boxes in JS are fully erased. - Note, that versions 0.25.1-2 are skipped for technical reasons (they were not fully released).
0.25.0
- Major rework on exception-handling and cancellation in coroutines (see #333, #452 and #451):
- New "Exception Handling" section in the guide explains exceptions in coroutines.
- Semantics of
Job.cancel
resultingBoolean
value changed —true
means exception was handled by the job, caller shall handle otherwise. - Exceptions are properly propagated from children to parents.
- Installed
CoroutineExceptionHandler
for a family of coroutines receives one aggregated exception in case of failure. - Change
handleCoroutineException
contract, so custom exception handlers can't break coroutines machinery. - Unwrap
JobCancellationException
properly to provide exception transparency over whole call chain.
- Introduced support for thread-local elements in coroutines context (see #119):
ThreadContextElement
API for custom thread-context sensitive context elements.ThreadLocal.asContextElement()
extension function to convert an arbitrary thread-local into coroutine context element.- New "Thread-local data" subsection in the guide with examples.
- SLF4J Mapped Diagnostic Context (MDC) integration is provided via
MDCContext
element defined inkotlinx-coroutines-slf4j
integration module.
- Introduced IO dispatcher to offload blocking I/O-intensive tasks (see #79).
- Introduced
ExecutorCoroutineDispatcher
instead ofCloseableCoroutineDispatcher
(see #385). - Built with Kotlin 1.2.61 and Kotlin/Native 0.8.2.
- JAR files for
kotlinx-coroutines
are now JEP 238 multi-release JAR files.- On JDK9+
VarHandle
is used for atomic operations instead ofAtomic*FieldUpdater
for better performance. - See AtomicFu project for details.
- On JDK9+
- Reversed addition of
BlockingChecker
extension point to control whererunBlocking
can be used (see #227).runBlocking
can be used anywhere without limitations (again), but it would still cause problems if improperly used on UI thread.
- Corrected return-type of
EventLoop
pseudo-constructor (see #477, PR by @Groostav). - Fixed
as*Future()
integration functions to catch allThrowable
exceptions (see #469). - Fixed
runBlocking
cancellation (see #501). - Fixed races and timing bugs in
withTimeoutOrNull
(see #498). - Execute
EventLoop.invokeOnTimeout
inDefaultDispatcher
to allow busy-wait loops insiderunBlocking
(see #479). - Removed
kotlinx-coroutines-io
module from the project, it has moved to kotlinx-io. - Provide experimental API to create limited view of experimental dispatcher (see #475).
- Various minor fixes by @LouisCAD, @Dmitry-Borodin.
0.24.0
- Fully multiplatform release with Kotlin/Native support (see #246):
- Only single-threaded operation inside
runBlocking
event loop is supported at this moment. - See details on setting up build environment here.
- Only single-threaded operation inside
- Improved channels:
- Provides
BlockingChecker
mechanism which checks current context (see #227).- Attempts to use
runBlocking
from any supported UI thread (Android, JavaFx, Swing) will result in exception.
- Attempts to use
- Android:
- Worked around Android bugs with zero-size ForkJoinPool initialization (see #432, #288).
- Introduced
UI.immediate
extension as performance-optimization to immediately execute tasks which are invoked from the UI thread (see #381).- Use it only when absolutely needed. It breaks asynchrony of coroutines and may lead to surprising and unexpected results.
- Fixed materialization of a
cause
exception forJob
onCancelling handlers (see #436). - Fixed JavaFx
UI
on Java 9 (see #443). - Fixed and documented the order between cancellation handlers and continuation resume (see #415).
- Fixed resumption of cancelled continuation (see #450).
- Includes multiple fixes to documentation contributed by @paolop, @sahillone, @rocketraman, @bdavisx, @mtopolnik, @Groostav.
- Experimental coroutines scheduler preview (JVM only):
- Written from scratch and optimized for communicating coroutines.
- Performs significantly better than ForkJoinPool on coroutine benchmarks and for connected applications with ktor.
- Supports automatic creating of new threads for blocking operations running on the same thread pool (with an eye on solving #79), but there is no stable public API for it just yet.
- For preview, run JVM with
-Dkotlinx.coroutines.scheduler
option. In this caseDefaultDispatcher
is set to new experimental scheduler instead of FJP-basedCommonPool
. - Submit your feedback to issue #261.