Repository navigation
Feature request: without gson #24
Description
Hi maintainers,
would it be possible to get a version of this library without gson? My current application has no reference to this and I don't want to bloat it. Why not just using pure json.org.
If you would be fine with this, I also could create a PR with these changes.
Best
Hasan
Activity
[-]without gson[/-][+]Feature request: without gson[/+]lbalmaceda commentedon Jun 28, 2018
Hey @alosdev! I missed this one.
We decided to use Gson since it's a wide used JSON library in the Android environment and compared to Jackson it provides less friction and better performance for simple JSON payloads. For this SDK in particular it only needs to deserialize simple JWTs body's.
If I understand your concern correctly, you suggest we parse the input manually instead of requiring an extra dependency. This is doable because the public API does not expose any Gson class. However, it was easier to go with the well-known trusted JSON library that most of the Android apps use. Because this library is made specifically for Android in mind (in opposition to https://github.com/auth0/java-jwt/), we find that using Gson is fine. If the size of your application is important to you, running Proguard before preparing the package is a standard practice all developers should follow. With the right set of ignore rules only the classes used by this library would be included in the final APK, thus the size would be lower.
That said, I'm curious about what you have in mind and how that improves this library in terms of performance.
alosdev commentedon Jul 2, 2018
Hi @lbalmaceda,
thanks for your response. You can always have a discussion regarding different libraries. I didn't want to start this one here, btw. we are using Moshi. So having a different one mocks me. As you already wrote yourself, that you have simple JWT body, which is not large. Therefore giving the burden of a not visible dependency for your users is quite high. The performance gain, in this case, is really neglectable. Also, you don't do it with every request. So my dream would be one without gson or have a pluggable architecture like retrofit. :)
Best
Hasan
lbalmaceda commentedon Jul 2, 2018
Opening the JSON deserializer to the user looks like overkill for such a simple library to me today, but we might consider it when we add signature verification in the near future. I'll leave this in our backlog to discuss with the team.
When you say "one without Gson", do you have an implementation in mind that doesn't use any dependency or you mean use Moshy? 😆
Cheers
alosdev commentedon Jul 2, 2018
json deserializer wouldn't be a big issue, I hope ;)
Moshi would be nice, but I think, that several other people will complain. so it would be best to go to plain json.org
lbalmaceda commentedon Jul 31, 2019
We decided against using a different JSON serialization dependency. As mentioned in the second comment, out intent is to make a simple android-focused library to decode JWTs. Gson has good performance on Android contexts for this case. Running Proguard would remove any unused code from your library's dependencies (including this one) if size is an issue. Every production build should run Proguard as recommended by Google.
renaudcerrato commentedon Sep 3, 2020
I'm bumping this one: GSON is considered as deprecated by 2 of 3 maintainers. See also here.
emartynov commentedon Aug 8, 2023
Found this and would suggest a modular SDK - where the core would have an interface to decode and json and there will be a couple of default additional sdks that would use popular json libraries to implement it.
arekolek commentedon Jan 29, 2026
I'll just leave this here: