Releases: cashapp/zipline
Releases · cashapp/zipline
1.16.0
1.15.0
- New: Use different dispatchers for cache vs code execution. Both the cache and QuickJS need to be
thread-confined, but they don't need to be confined to the same thread. With this release we've
added a newCoroutineDispatcher
parameter toZiplineLoader.withCache()
. It is used when
reading and writing the cache. The existingCoroutineDispatcher
used to create the
ZiplineLoader
is used to access QuickJS. - New:
EventListener.cacheHit()
is called on each cache hit.
1.14.0
- New:
ZiplineLoader.load()
andloadOnce()
now accept a suspending function. - New: Don't crash in
ZiplineLoader
when writing to the disk cache fails. Use the new
LoaderEventListener
type to observe such failures. - Fix: Don't crash in Gradle if the Zipline runtime library is absent.
- New: Extend Kotlin's
AutoCloseable
inZipline
,ZiplineService
andZiplineScope
. - Upgrade: [Oracle Linux 8][oracle_linux_8] for x86_64 Linux (
amd64/oraclelinux:8
on Docker). - Upgrade: [Kotlin Serialization 1.7.1][kotlin_serialization_1_7_1].
1.12.0
- Fix: Don't allocate a stack trace when canceling a coroutine or a job. We've observed that
applications create many instances ofCancellationException
, such as when canceling a flow
in routine business logic. Unfortunately, we've also seen that creating the stack traces for
these exceptions is slow on Kotlin/Native. With this update Zipline reuses a single instance of
CancellationException everywhere. We believe that losing the diagnostic information is worth
the performance benefit. - Fix: Don't break the configuration cache. Zipline's compile task violated a Gradle requirement
by reading another task's property before that task had completed. - New:
ZiplineFunction.asDynamicFunction()
short-circuits Kotlin Serialization in Kotlin/JS. This
new mechanism allows performance-sensitive code to reduce the amount of work required to call
bridged functions. - Upgrade: [Kotlin Serialization 1.7.0][kotlin_serialization_1_7_0].
1.11.0
- New:
apiTracking
property on thezipline { }
Gradle extension allows disabling API generation. - Fix: Calling
Zipline.close()
will now callZiplineService.close()
on all bound services. Strong
references to the services will also be cleared to prevent reference cycles on native. - Upgrade: [Kotlin 2.0.0][kotlin_2_0_0]]
1.10.0
- Fix: Clean source paths that show up in stack traces.
- Fix: Don't leak Zipline instances. We had a bug where our memory-leak detection itself introduced
a memory leak. We held a reference to a Zipline instance that was intended to be used to report
services that were garbage collected but not closed.
1.9.0
- Breaking: Reorder the parameters in
ZiplineLoader
soFileSystem
always precedesPath
. - Fix: Release unused services in
Zipline.close()
. This was a memory leak. - Fix: Don't break Gradle's configuration cache in the
ziplineApiDump
task. - New:
ZiplineCryptography
adds aSecureRandom
API for guest code. - New:
Zipline.getOrPutAttachment()
lets you attach application data to a Zipline instance. - New: Support building Zipline with the new Kotlin K2 compiler.
- Upgrade: [Kotlin 1.9.23][kotlin_1_9_23]
- Upgrade: [kotlinx.coroutines 1.8.0][kotlinx_coroutines_1_8_0]
- Upgrade: [Okio 3.9.0][okio_3_9_0]
- Upgrade: [SQLDelight 2.0.2][sqldelight_2_0_2]
1.7.0
- New: Gradle APIs to optimize production builds for either small artifact size or developer
experience. Call the appropriate functions in thezipline {}
block of your build file:zipline { ... optimizeForSmallArtifactSize() }
- Fix: Don't crash when very large
Long
values are sent over a bridged API. Zipline uses JSON to
encode values shared between host and guest, and that converts all primitive numeric types to
Double
. It is necessary to add@Contextual
to all serializedLong
values to get this fix.
1.6.0
- Upgrade: [SQLDelight 2.0.0][sqldelight_2_0_0]
1.5.1
- Fix: remove the Zipline version from the
klib
metadata in thezipline-cinterop-quickjs
artifact. This restores the behavior from 1.4.0 to work around [KT-62515].