Plans for upcoming version

[alipov]

Hi there! :)
Hopefully this is a suitable place to ask.
I'd be grateful if you could share plans for upcoming version release (it's been over a year since the last one). For what it's worth, I'm specifically waiting for #1945 and #2401 to be part of an official build.
Thanks!

[eamonnmcmanus]

Hi, we have indeed discussed making a new release. I think @Marcono1234 had a short list of things that should ideally be included, and perhaps can comment on whether any of them are still missing.

[Marcono1234]

@eamonnmcmanus, is there something I or others can do to help you prepare the release?

For example, would it help if I go through the commits since the last release and try to prepare release notes for the upcoming release, so that you can take them over?

[eamonnmcmanus]

The main thing that has been holding me back has been #2588. Based on the internal test I mentioned, I'm uncertain that this is entirely safe to include as-is. I think the best thing is probably to make a release without it, and then revisit the question. I'll look into doing that.

[eamonnmcmanus]

I have released 2.11.0 now, but I haven't yet had time to condense 16 months of changes into release notes. @Marcono1234 if you want to have a look at that, I would not object. Otherwise I will try to do it tomorrow.

[Marcono1234]

Thanks a lot!

I would propose these following release notes. Hopefully they are useful. I think you can just copy & paste them into the GitHub editor; GitHub will automatically add the links and mention the listed users as contributors.
But feel free to adjust the formatting and text, and if you want also double-check that I did not overlook something.

Proposed release notes (click to expand)

# Most important changes

- Added default ProGuard / R8 rules (@Marcono1234, #2397, #2420; @sgjesse, #2448; @sfreilich)\
If you are using ProGuard or R8 (for example for Android projects) you might not need any special Gson configuration anymore if your classes have a no-args constructor and use `@SerializedName` for their fields.
- On Android Gson now requires API level 21 or newer
- New `Strictness` API (@marten-voorberg & fellow students, #2437)\
Some of Gson's API is still lenient by default, but you can now use the newly added methods `GsonBuilder#setStrictness`, `JsonReader#setStrictness` and `JsonWriter#setStrictness` with `Strictness.STRICT` to override this behavior and to instead strictly adhere to the JSON specification.
- New `FormattingStyle` class to allow configuring line breaks in JSON output (@mihnita, #2231)\
Can be set using `GsonBuilder#setFormattingStyle` and `JsonWriter#setFormattingStyle`.
- `TypeToken` can no longer capture type variables by default (@Marcono1234, #2376)\
This was previously a common source of issues. The newly thrown exception refers to a [Troubleshooting Guide article](https://github.com/google/gson/blob/main/Troubleshooting.md#typetoken-type-variable) which explains this in more detail and provides suggestions for updating affected code.
- Added serialization support for anonymous and local classes with a custom adapter (@Marcono1234, #2498)\
This affects for example `List` implementations returned by libraries such as Guava which are implemented as anonymous class, which were previously serialized as `null`. Anonymous and local classes without custom adapter will still be serialized as `null`.
- Added dependency on `com.google.errorprone:error_prone_annotations`\
This dependency can be considered optional, but if missing it might lead to compiler warnings. Therefore Gson does not declare it as optional.
- Many exception messages now refer to the [Troubleshooting Guide](https://github.com/google/gson/blob/main/Troubleshooting.md) (@Marcono1234, #2357)\
Feedback regarding the Troubleshooting Guide is appreciated!
- Documented that JVM languages other than Java might not be fully supported, see the README
- Guarantee that `JsonElement#toString` produces JSON output (@Marcono1234, #2659)

# Other changes

## Bug fixes

- Fixed incorrect `JsonPrimitive#equals` results for large `BigInteger` values (@MaicolAntali, #2311)
- Fixed incorrect `JsonPrimitive#equals` results for large `BigDecimal` values (@MaicolAntali, #2364)
- Fixed `JsonReader` throwing `NumberFormatException` instead of `MalformedJsonException` for malformed Unicode escape sequences (@MaicolAntali, #2337)
- Fixed `TypeToken#getParameterized` returning bogus `ParameterizedType` for non-generic types (@Marcono1234, #2447)
- Fixed Java Record adapter not working for GraalVM Native Image (@eamonnmcmanus, #2465)
- Fixed `JsonWriter#name` not throwing exception when no JSON object is currently being written (@shivam-sehgal, #2475; @Marcono1234, #2476)
- Fixed `Gson#getDelegateAdapter` not working properly for `@JsonAdapter` (@Marcono1234, #2435)\
Note that `null` is now not allowed as `skipPast` value anymore, which was previously allowed but undocumented.
- Fixed `GsonBuilder` not rejecting type adapters for `Object` and `JsonElement`, whose default adapters cannot be overridden (@sachinp97; #2479)
- Fixed no limits being enforced when deserializing `BigDecimal` and `BigInteger` (@Marcono1234, #2510)\
The new limits prevent potential performance problems when user code uses the deserialized numbers. Gson itself was and is not affected by these performance problems. The limits should be high enough to not cause issues for most use cases, but feedback is appreciated.
- Fixed `GsonBuilder#setDateFormat` not rejecting invalid date formats (@Carpe-Wang, #2538)
- Fixed `GsonBuilder#setDateFormat` not rejecting invalid date styles (@Marcono1234, #2545)
- Fixed `GsonBuilder#setDateFormat` ignoring partial DEFAULT style (@Marcono1234, #2556)
- Fixed `TypeToken#isAssignableFrom` throwing `AssertionError` in some cases (@Marcono1234, #2544)
- Fixed date adapters not restoring time zone after parsing (@Carpe-Wang, #2549)
- Fixed `TypeToken#equals` erroneously returning `false` for equal generic type parameters in some cases (@d-william, #2599)
- Fixed incorrect inherited URLs in `pom.xml` (@Marcono1234, #2351)

## Performance improvements

- Slightly reduce memory usage for reflection-based adapter (@sembseth, #2325; @Marcono1234, #2440)
- Improved parsing speed of `ToNumberPolicy#LONG_OR_DOUBLE` (@ctasada, #2674)

## Gson maintenance

- Changed many unit tests to use Truth instead of JUnit for assertions (@MaicolAntali, #2299, #2304)
- Configured Error Prone to automatically check for bugs when compiling (@MaicolAntali, #2308)
- Simplified expected exception handling in tests (@elevne, #2454)
- Added integration test for GraalVM Native Image (@Marcono1234, #2466)
- Formatted the code according to the Google Style Guide & configured Spotless (@MaicolAntali, #2531, #2537)
- Made Maven build reproducible (@Marcono1234, #2543)
- Removed internal `DateTypeAdapter` class to reduce code duplication (@Marcono1234, #2546)
- Dependencies and plugins updated by Dependabot

## GitHub repository

- Renamed default branch from `master` to `main`
- [GitHub Discussions](https://github.com/google/gson/discussions) have been enabled\
For questions, ideas, tips...
- Added GitHub pull request template (@Marcono1234, #2326)
- Added check for Android API compatibility (@Marcono1234, #2431)

## Other

- Added `@CanIgnoreReturnValue` as appropriate to Gson methods (@eamonnmcmanus, #2369)\
This is useful if you enable Error Prone's `CheckReturnValue` in your project when compiling, however Gson itself does not enable this by default.
- Various documentation and test improvements and typo fixes (@False-Mask; @avimathur009; @elevne; @0o001; @Codegass; @33nya)

[eamonnmcmanus]

That's absolutely fantastic! Many thanks for putting these really thorough release notes together.

[Reginer]

I'm specifically waiting for #2401 to be part of an official build.
Thanks!

[muhammadzkralla]

I wonder if there's any plans for GSON to support KMP ( kotlin Multiplatform ) in the near future or not?

Thanks in advance.

[eamonnmcmanus]

No, there are no such plans. See the recently-added text from the README:

Gson's main focus is on Java. Using it with other JVM languages such as Kotlin or Scala might work fine in many cases, but language-specific features such as Kotlin's non-null types or constructors with default arguments are not supported. This can lead to confusing and incorrect behavior.
When using languages other than Java, prefer a JSON library with explicit support for that language.

For KMP specifically, it's hard to see how Gson could work given that reflecting over fields is not supported by Kotlin/Native. You might have more luck with kotlinx.serialization.

[muhammadzkralla]

I was also thinking about #2645 as I need to do some workarounds to deal with String (de)serialization like this : Code

package com.zkrallah.zhttp

import android.util.Log
import com.google.gson.Gson
import com.google.gson.JsonParseException
import com.google.gson.reflect.TypeToken

/**
 * Helper function for calling the callback on the main thread.
 */
object Helper {

    /**
     * Deserializes the specified JSON string into an object of the specified type [T].
     *
     * @param json The JSON string to deserialize.
     * @return The deserialized object of type [T], or `null` if the JSON string is `null`.
     */
    inline fun <reified T> Gson.fromJson(json: String?): T? {
        return json?.let {
            val type = object : TypeToken<T>() {}.type
            this.fromJson(json, type)
        } ?: run {
            null
        }
    }

    /**
     * Deserializes the specified JSON string into an object of the specified type [T].
     *
     * @param body The JSON string to deserialize.
     * @return The deserialized object of type [T], or `null` if an error occurs during deserialization.
     */
    inline fun <reified T> Gson.deserializeBody(body: String?): T? {
        return try {
            this.fromJson<T>(body)
        } catch (e: JsonParseException) {
            if (T::class.java == String::class.java) body as T /** HERE **/
            else null
        } catch (e: Exception) {
            Log.e("ZHttp", "deserializeBody: $e", e)
            null
        }
    }
}

[eamonnmcmanus]

I'm not sure I see how this is related to #2645, which is about avoiding buffer resizing while deserializing strings. From the code, it looks as if you want to be able to parse a string into an object of type T, and as a fallback when parsing fails, if T is String then return the input string intact. I don't believe there is a substantially better way to do that than what you have.

[eamonnmcmanus]

2.11.0 has been released now, so I'm going to close this.