[Question] : is gson still maintained?

[radityagumay]

Rationale behind this is, gson looks like not actively maintained. The last PR was on may. and looks like there's no roadmap on gson to provide new features and fix bugs.

Will appreciated if the maintainer able to put some thoughts on this.

Thank you!

[Marcono1234]

I am not a maintainer / member of this project and had the same question the last months as well and always thought about creating an issue too because activity here has sadly slowed down.

There are several critical issues (with corresponding pull requests) which have not been touched for a rather long time (subjective selection):

• Issues with generic parameter being used multiple times: Fix issue with recursive type variable protections to fix #1390 #1391
• ProGuard issues with enums: Make EnumTypeAdapter friendly with obfuscation #1495
• ISO8601UtilsTest being faulty (Specify timezone for GregorianCalender in testDateFormatString() #1665, Fix ISO8601UtilsTest failing on systems with UTC+X #1687, ISO8601UtilsTest.testDateFormatString: Create date instance with UTC #1781)
• Optional java.sql module dependency: Make dependency on java.sql optional #1707
• Problem with SecurityManager: Fix fallback behavior of UnsafeReflectionAllocator when AccessibleObject isn't so accessible #1712
• module-info.class not being in META-INF multi release folder (Illegal class file: Class module-info is missing a super type. #1627)
• Incorrect OSGi JRE requirement: GSON 2.8.6 does not support on lower JavaSE environment #1677 (has already been fixed by Fix OSGi metadata generation to work on JavaSE < 9 #1603, but has not been released)
• Serialization for some objects created by JDK classes fails because Gson tries to access private constructors using reflection: InaccessibleObjectException with JDK 16  #1875
• Records are not supported: Java 14/15 records can not set final field #1794

It appears @joel-leitch, one of the original maintainers, is not very active on GitHub anymore. @swankjesse and @JakeWharton are not active here either. I am not completely familiar with their biography, but if I understand it correctly they (or one of them) quit their job at Google and are now working at Square where they are working on https://github.com/square/moshi, a competitor of Gson. Maybe they do not even have the GitHub project roles and permissions anymore to directly work on Gson.
@inder123 is the one who made the most recent changes, but it looks like they are not that active at the moment either.

It is not my goal to blame them for the lack of activity, they put great efforts in this project in the past and are the reason for the popularity of it. It is completely understandable that after more than 10 years, the motivation of working on the same project decreases. Especially when (as it is likely the case for all projects) design flaws or decisions hindering future development become apparent over time. And as with all open source projects, enough free time might also not always be available.

However, because Gson is still widely used it is important that a clear decision is made about how Gson's future development (if any) will look like. Otherwise users will be forced to switch to other frameworks when bugs remain unfixed. While switching to other frameworks is not necessarily bad, being forced to do this creates extra stress and work for the users; it should ideally happen voluntarily.

Would it at least be possible to keep developing Gson in maintenance mode: Only bug fixes are implemented, but no major new features are added?

[xileftenurb]

I found this anwser on reddit written by @swankjesse

https://www.reddit.com/r/androiddev/comments/684flw/why_use_moshi_over_gson/dgx3gpm?utm_source=share&utm_medium=web2x&context=3

In short, it seem Gson is already in maintenance mode because it was mostly replaced by "moshi", a new project build by some of the same contributor with less short-comming than Gson

[mleonhard]

Moshi is a suitable alternative to Gson. I just switched my code over.

https://github.com/square/moshi

Moshi throws exceptions in cases where Gson silently returns null. I'm happy with this.

Moshi doesn't support Optional yet (square/moshi#1329).

[Marcono1234]

Thanks @eamonnmcmanus and @cgdecker for bringing some activity back into this project! What are the future plans for Gson?

[anandr781]

Is Gson actively maintained

[cgdecker]

We've taken ownership of this project so that we can do basic maintenance and such (for example the release we made last month) but we don't have any specific plans for it at the moment.

[kliakos]

We've taken ownership of this project so that we can do basic maintenance and such (for example the release we made last month) but we don't have any specific plans for it at the moment.

Please fix Java 16 related issues.

[eamonnmcmanus]

I am planning to spend some time this month studying open issues and PRs, consistent with the maintenance mode that @cgdecker mentioned. We are unlikely to add new features at this point but we can attempt to address some important issues. The list compiled by @Marcono1234 above will likely be very helpful in this regard.

I think we've addressed the question asked in this issue, so I'm going to close it.