Sentry-java: sentry-android dependency size

[friederbluemle]

I was just comparing the new official sentry-android library (group name io.sentry), and the older (now deprecated) one by @joshdholtz (group name: com.joshdholtz.sentry) using the Methods Count service.

In values below were obtained from the following libraries:

• com.joshdholtz.sentry:sentry-android:1.6.2
• io.sentry:sentry-android:1.2.2

library | dependencies | total methods | total size
--- | --- | --- | ---
com.joshdholtz.sentry | 0 | 283 | 34 kB
io.sentry | 3 | 4171 | 515 kB

It is quite surprising that two libraries doing something very similar show such a huge discrepancy in method count and total size. The method count in particular is quite alarming, as there is a hard limit of 65k for a single dex file on Android. If this number is exceeded, it will cause all kinds of trouble (especially for versions without native multidex support).

I completely understand the desire to have a common code base for Java projects (which also includes Android). For a server-side integration, the method count or 500kB of added dependencies does not matter that much. For Android, this is a much more sensitive topic.

Looking at the transitive dependencies in more detail, it seems that the Jackson library alone is adding almost 2400 new methods.

Opening this issue to discuss this issue and potential solutions.

[bretthoerner]

Thanks for looking into this.

For the record, it looks like slf4j-api adds 580 of those. Removing it might be possible but we'd have to add a facade to the facade...

I have definitely considered replacing Jackson. It looks like the Moshi JSON library adds 1493, which doesn't seem like a huge improvement, but if Moshi is very popular on Android then most users would already have the dependency -- so those methods wouldn't be "extra" for sentry-android. (That's actually true for Jackson also. I'm not sure how to evaluate the popularity on Android.)

I have also considered building a minified/shaded sentry dependency that includes only the Jackson dependencies it needs (#351).

I'm definitely open to ideas here. You are correct though that reusing the existing Java SDK was done on purpose so that we don't have to maintain two very active codebases. In addition sentry-android provides many more features.

[bretthoerner]

Oh, there's also gson which adds 1345. The number of JSON choices probably means the likelihood of one already being a dep is low for all users.

minimal-json adds 319: https://github.com/ralfstx/minimal-json

But mostly I wonder if #351 would help the most.

[friederbluemle]

Thanks for the replies!

Yes, replacing/abstracting away the JSON parsing library is also something that came to my mind. I am not sure how feasible a full decoupling is, but replacing Jackson with Gson as a first step would be a quick win, saving almost 1,000 methods, and slightly decreasing the dependency size as well. I've done it on several mobile projects in the past and most of it is just a drop-in replacement.

moshi and minimal-json also look interesting. I'll check them out over the weekend.

The way com.joshdholtz.sentry:sentry-android achieves zero dependencies is by only using the integrated JSON helper classes from org.json - of course they only provide very rudimentary serialization/parsing support.

[Hazer]

How much trouble would be making the facade and supporting Gson officially but making the facade open so anyone could extend and create a module for its own parsing library?

I don't know if replacing Jackson with Gson is the only way to go. I am using Gson, so for me this would be optimal, but there's a lot of people using moshi or jackson as well.

For me the best solution, would be a pluggable facade and let users choose their implementation, this is what square/retrofit does (look at the converters section).

And about using org.json, impossible or just not worth?

[bretthoerner]

I think using org.json would be great if it supports our needs.

The main issue is that it's only on Android (as far as I can tell?) and so we'd probably have to make a facade anyway, and then use Jackson or something on non-Android?

[Hazer]

@bretthoerner So making the facade and choosing only one or two lib to support looks the way to go?

Looks like org.json is pure Java, BUT the lib description itself says:

This is a reference implementation. There is a large number of JSON packages in Java. Perhaps someday the Java community will standardize on one. Until then, choose carefully.

I'd vote for Gson in this case.

I believe if the user can change the facade implementation, we can get user support for other implementations and let user itself choose what wants.

[bretthoerner]

Ah I didn't realize org.json could be downloaded for non-Android use. That's an option.

I still think we probably use a very small % of Jackson so I need to try shading and minifying it (if that's even a thing for published libraries -- seems like it should be?).

[Hazer]

Any update?

[bretthoerner]

Sorry, haven't had time to work on this one. Is the 4k method count preventing you from using sentry-android in your applications?

[Hazer]

@bretthoerner Not now, but I have some restrictions on size, for a project we will start next month and this would be helpful. In my current projects I am using proguard already and we don't have an ETA to reduce the size, yet. We are waiting for some changes, in the backend, to change our SDK, only then we will think about it again, but as it is one of the biggest libs, we will probably choose to help in this issue, use another implementation or remove it per build variant.

[bretthoerner]

Do you use a JSON dependency for your own code in that application? I'm curious which one.

[Hazer]

Yes, Gson right now, I want to try someday Moshi, but I am fine with Gson.

[marandaneto]

Closing the issue as a part of large repository cleanup, due to it being inactive and/or outdated.

https://github.com/getsentry/sentry-android which is sentry-android 2.0 uses GSON.

Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!