Skip to content

Build(deps): Bump org.jetbrains.kotlinx:kotlinx-serialization-json from 1.7.3 to 1.8.0

Dependabot requested to merge dependabot-gradle-org.jetbrains.kotlinx-kotlinx-serialization-json-1.8.0 into main

Bumps org.jetbrains.kotlinx:kotlinx-serialization-json from 1.7.3 to 1.8.0.

Release notes

Sourced from org.jetbrains.kotlinx:kotlinx-serialization-json's releases.

1.8.0

This release contains all of the changes from 1.8.0-RC. Kotlin 2.1.0 is used as a default, while upcoming 2.1.10 is also supported. Also added small bugfixes, including speedup of ProtoWireType.from (#2879).

Changelog for 1.8.0-RC is presented below:

@JsonIgnoreUnknownKeys annotation

Previously, only global setting JsonBuilder.ignoreUnknownKeys controlled whether Json parser would throw exception if input contained a property that was not declared in a @Serializable class. There were a lot of complaints that this setting is not flexible enough. To address them, we added new @JsonIgnoreUnknownKeys annotation that can be applied on a per-class basis. With this annotation, it is possible to allow unknown properties for annotated classes, while general decoding methods (such as Json.decodeFromString and others) would still reject them for everything else. See details in the corresponding PR.

Stabilization of SerialDescriptor API and @SealedSerializationApi annotation

SerialDescriptor, SerialKind, and related API has been around for a long time and has proven itself useful. The main reason @ExperimentalSerializationApi was on SerialDescriptor's properties is that we wanted to discourage people from subclassing it. Fortunately, Kotlin 2.1 provides a special mechanism for such a case — SubclassOptInRequired. New kotlinx.serialization.SealedSerializationApi annotation designates APIs as public for use, but closed for implementation — the case for SerialDescriptor, which is a non-sealed interface for technical reasons. Now you can use most of SerialDescriptor and its builders API without the need to opt-in into experimental serialization API. See the PR for more details.

Note: All SerialKinds are stable API now, except PolymorphicKind — we may want to expand it in the future.

Generate Java 8's default method implementations in interfaces

TL;DR This change ensures better binary compatibility in the future for library. You should not experience any difference from it.

kotlinx.serialization library contains a lot of interfaces with default method implementations. Historically, Kotlin compiled a synthetic DefaultImpls class for them. Starting from Kotlin 1.4, it was possible to compile them using as Java 8's default methods to ensure that new methods can still be added to interfaces without the need for implementors to recompile. To preserve binary compatibility with existing clients, a special all-compatbility mode is supported in compiler to generate both default methods and synthetic DefaultImpls class.

Now, kotlinx.serialization finally makes use of this all-compatibility mode, which potentially allows us to add new methods to interfaces such as SerialDescriptor, Encoder, Decoder, etc., without breaking existing clients. This change is expected to have no effect on existing clients, and no action from your side is required.

... (truncated)

Changelog

Sourced from org.jetbrains.kotlinx:kotlinx-serialization-json's changelog.

1.8.0 / 2025-01-06

This release contains all of the changes from 1.8.0-RC. Kotlin 2.1.0 is used as a default, while upcoming 2.1.10 is also supported. Also added small bugfixes, including speedup of ProtoWireType.from (#2879).

1.8.0-RC / 2024-12-10

This is a release candidate for the next version. It is based on Kotlin 2.1.0 and includes a few new features, as well as bugfixes and improvements:

@JsonIgnoreUnknownKeys annotation

Previously, only global setting JsonBuilder.ignoreUnknownKeys controlled whether Json parser would throw exception if input contained a property that was not declared in a @Serializable class. There were a lot of complaints that this setting is not flexible enough. To address them, we added new @JsonIgnoreUnknownKeys annotation that can be applied on a per-class basis. With this annotation, it is possible to allow unknown properties for annotated classes, while general decoding methods (such as Json.decodeFromString and others) would still reject them for everything else. See details in the corresponding PR.

Stabilization of SerialDescriptor API and @SealedSerializationApi annotation

SerialDescriptor, SerialKind, and related API has been around for a long time and has proven itself useful. The main reason @ExperimentalSerializationApi was on SerialDescriptor's properties is that we wanted to discourage people from subclassing it. Fortunately, Kotlin 2.1 provides a special mechanism for such a case — SubclassOptInRequired. New kotlinx.serialization.SealedSerializationApi annotation designates APIs as public for use, but closed for implementation — the case for SerialDescriptor, which is a non-sealed interface for technical reasons. Now you can use most of SerialDescriptor and its builders API without the need to opt-in into experimental serialization API. See the PR for more details.

Note: All SerialKinds are stable API now, except PolymorphicKind — we may want to expand it in the future.

Generate Java 8's default method implementations in interfaces

TL;DR This change ensures better binary compatibility in the future for library. You should not experience any difference from it.

kotlinx.serialization library contains a lot of interfaces with default method implementations. Historically, Kotlin compiled a synthetic DefaultImpls class for them. Starting from Kotlin 1.4, it was possible to compile them using as Java 8's default methods to ensure that new methods can still be added to interfaces without the need for implementors to recompile. To preserve binary compatibility with existing clients, a special all-compatbility mode is supported in compiler

... (truncated)

Commits

Dependabot commands
You can trigger Dependabot actions by commenting on this MR
  • $dependabot recreate will recreate this MR rewriting all the manual changes and resolving conflicts

Merge request reports