Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump kotlinx-serialization-json from 1.3.3 to 1.4.0 #27392

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Aug 19, 2022

Bumps kotlinx-serialization-json from 1.3.3 to 1.4.0.

Release notes

Sourced from kotlinx-serialization-json's releases.

1.4.0

This release contains all features and bugfixes from 1.4.0-RC plus some bugfixes on its own (see below). Kotlin 1.7.10 is used as a default.

Bugfixes

  • Fixed decoding of huge JSON data for okio streams (#2006)

1.4.0-RC

This is a candidate for the next big release with many new exciting features to try. It uses Kotlin 1.7.10 by default.

Integration with Okio's BufferedSource and BufferedSink

Okio library by Square is a popular solution for fast and efficient IO operations on JVM, K/N and K/JS. In this version, we have added functions that parse/write JSON directly to Okio's input/output classes, saving you the overhead of copying data to String beforehand. These functions are called Json.decodeFromBufferedSource and Json.encodeToBufferedSink, respectively. There's also decodeBufferedSourceToSequence that behaves similarly to decodeToSequence from Java streams integration, so you can lazily decode multiple objects the same way as before.

Note that these functions are located in a separate new artifact, so users who don't need them wouldn't find themselves dependent on Okio. To include this artifact in your project, use the same group id org.jetbrains.kotlinx and artifact id kotlinx-serialization-json-okio. To find out more about this integration, check new functions' documentation and corresponding pull requests: #1901 and #1982.

Inline classes and unsigned numbers do not require experimental annotations anymore

Inline classes and unsigned number types have been promoted to a Stable feature in Kotlin 1.5, and now we are promoting support for them in kotlinx.serialization to Stable status, too. To be precise, we've removed all @ExperimentalSerializationApi annotations from functions related to inline classes encoding and decoding, namely SerialDescriptor.isInline, Encoder.encodeInline, and some others. We've also updated related documentation article.

Additionally, all @ExperimentalUnsignedTypes annotations were removed completely, so you can freely use types such as UInt and their respective serializers as a stable feature without opt-in requirement.

Part of SerializationException's hierarchy is public now

When kotlinx.serialization 1.0 was released, all subclasses of SerializationException were made internal, since they didn't provide helpful information besides the standard message. Since then, we've received a lot of feature requests with compelling use-cases for exposing some of these internal types to the public. In this release, we are starting to fulfilling these requests by making MissingFieldException public. One can use it in the catch clause to better understand the reasons of failure — for example, to return 400 instead of 500 from an HTTP server — and then use its fields property to communicate the message better. See the details in the corresponding PR.

In future releases, we'll continue work in this direction, and we aim to provide more useful public exception types & properties. In the meantime, we've revamped KDoc for some methods regarding the exceptions — all of them now properly declare which exception types are allowed to be thrown. For example, KSerializer.deserialize is documented to throw IllegalStateException to indicate problems unrelated to serialization, such as data validation in classes' constructors.

@​MetaSerializable annotation

This release introduces a new @MetaSerializable annotation that adds @Serializable behavior to user-defined annotations — i.e., those annotations would also instruct the compiler plugin to generate a serializer for class. In addition, all annotations marked with @MetaSerializable are saved in the generated @SerialDescriptor

... (truncated)

Changelog

Sourced from kotlinx-serialization-json's changelog.

1.4.0 / 2022-08-18

This release contains all features and bugfixes from 1.4.0-RC plus some bugfixes on its own (see below). Kotlin 1.7.10 is used as a default.

Bugfixes

  • Fixed decoding of huge JSON data for okio streams (#2006)

1.4.0-RC / 2022-07-20

This is a candidate for the next big release with many new exciting features to try. It uses Kotlin 1.7.10 by default.

Integration with Okio's BufferedSource and BufferedSink

Okio library by Square is a popular solution for fast and efficient IO operations on JVM, K/N and K/JS. In this version, we have added functions that parse/write JSON directly to Okio's input/output classes, saving you the overhead of copying data to String beforehand. These functions are called Json.decodeFromBufferedSource and Json.encodeToBufferedSink, respectively. There's also decodeBufferedSourceToSequence that behaves similarly to decodeToSequence from Java streams integration, so you can lazily decode multiple objects the same way as before.

Note that these functions are located in a separate new artifact, so users who don't need them wouldn't find themselves dependent on Okio. To include this artifact in your project, use the same group id org.jetbrains.kotlinx and artifact id kotlinx-serialization-json-okio. To find out more about this integration, check new functions' documentation and corresponding pull requests: #1901 and #1982.

Inline classes and unsigned numbers do not require experimental annotations anymore

Inline classes and unsigned number types have been promoted to a Stable feature in Kotlin 1.5, and now we are promoting support for them in kotlinx.serialization to Stable status, too. To be precise, we've removed all @ExperimentalSerializationApi annotations from functions related to inline classes encoding and decoding, namely SerialDescriptor.isInline, Encoder.encodeInline, and some others. We've also updated related documentation article.

Additionally, all @ExperimentalUnsignedTypes annotations were removed completely, so you can freely use types such as UInt and their respective serializers as a stable feature without opt-in requirement.

Part of SerializationException's hierarchy is public now

When kotlinx.serialization 1.0 was released, all subclasses of SerializationException were made internal, since they didn't provide helpful information besides the standard message. Since then, we've received a lot of feature requests with compelling use-cases for exposing some of these internal types to the public. In this release, we are starting to fulfilling these requests by making MissingFieldException public. One can use it in the catch clause to better understand the reasons of failure — for example, to return 400 instead of 500 from an HTTP server — and then use its fields property to communicate the message better. See the details in the corresponding PR.

In future releases, we'll continue work in this direction, and we aim to provide more useful public exception types & properties.

... (truncated)

Commits

Dependabot compatibility score

You can trigger a rebase of this PR by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [kotlinx-serialization-json](https://github.com/Kotlin/kotlinx.serialization) from 1.3.3 to 1.4.0.
- [Release notes](https://github.com/Kotlin/kotlinx.serialization/releases)
- [Changelog](https://github.com/Kotlin/kotlinx.serialization/blob/master/CHANGELOG.md)
- [Commits](Kotlin/kotlinx.serialization@v1.3.3...v1.4.0)

---
updated-dependencies:
- dependency-name: org.jetbrains.kotlinx:kotlinx-serialization-json
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added the area/dependencies Pull requests that update a dependency file label Aug 19, 2022
@gsmet gsmet requested a review from evanchooly August 19, 2022 22:01
@geoand
Copy link
Contributor

geoand commented Aug 22, 2022

Seems like this uses Kotlin 1.7 which we have updated to, so I assume this is safe

@gsmet gsmet merged commit daa94ac into main Aug 22, 2022
@quarkus-bot quarkus-bot bot added this to the 2.13 - main milestone Aug 22, 2022
@dependabot dependabot bot deleted the dependabot/maven/org.jetbrains.kotlinx-kotlinx-serialization-json-1.4.0 branch August 22, 2022 14:48
@gsmet gsmet modified the milestones: 2.13 - main, 2.12.0.Final Aug 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/dependencies Pull requests that update a dependency file area/kotlin kind/component-upgrade
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants