Use driver 4.x without shaded Guava

[Marco Scoppetta]

Hi All!

I was wondering if you are planning to release a version of the driver that does not depend on the shaded version of Guava? As it seems to only be version 25.1-jre, not a custom version.

I am asking this because Guava is a pretty common library used by many projects, 

and in trying to reduce the number of jars on which we depend on we wanted to get rid of your duplicate shaded version of Guava (which is almost 3MB).

Also I am asking this because I noticed you offer a version of the driver with shaded Netty,

so maybe eventually it will be possible to have a driver without any shaded dependency at all?

Thanks in advance,

Marco

[Olivier Michallat]

Hi,

No, we have no plans to do that.

We did it that way to avoid the dependency hell issues encountered in previous driver versions (see JAVA-1328). It's packaged separately so that those 3MB don't get added to every driver artifact. We should rarely, if ever, upgrade it. Once it's in your local repo, future driver artifacts will reuse it.

You might also wonder why we depend on Guava at all. The main reason is the TypeToken API: it's used internally to implement our own GenericType, used in cases such as this. It's pretty complex and I didn't want to reimplement it completely in the driver.

Frankly I don't think 3MB is a big deal in this day and age. But if there's high demand, we could look at alternative solutions, like extracting TypeToken to our own codebase (provided there are no licensing issues), or shrinking the shaded Guava artifact with Proguard.

--

Olivier Michallat

Driver & tools engineer, DataStax

--
To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.

[Marco Scoppetta]

Hi,

thanks for the explanation.

I guess my line of reasoning is based on a few factors:

- you're already providing the shaded and unshaded version for Netty, so maybe Guava was also in the roadmap

- ideally you're building a driver which is a pretty low level component in someone's app, so you should probably have as few dependencies as possible I believe, 

  so that's why I think packaging the full Guava (which is not shareable with other libraries because shaded) just to use a small subset of its classes is not potentially optimal

And as you said, there are many alternatives to the current approach.

If it's ok in terms of license maybe I can try to copy the classes inside the driver that depend on Guava in my own app, 

so that the driver can use those at runtime.

But anyway I understand your reasoning and I thank you again for the detailed reply, 

Marco

To unsubscribe from this group and stop receiving emails from it, send an email to java-dri...@lists.datastax.com.

[Stéphane LANDELLE]

Hi there,

I was thinking the same thing: why shade the full 2.9MB library while you only need the small subset related to TypeToken?

Or are Guava packages so interdependent it's hard to not pull the whole thing?

Regards,

Stéphane

To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.

[Michaël Figuière]

Hi,

Some fair points on both side. I'd just want to point that if you want this thinner package you can build it easily on your own by checking out the Git tag you're interested in and running:

mvn clean package -DskipTests=true

This will produce both the normal and shaded jars that you can then publish on your private maven repo according to your needs. If you build from a tag the resulting jar is safe to use and reproducible. Not as smooth as one would want but not too expensive either.

Best,

Michaël

[Alexandre Dutra]

Hi, 

I created JAVA-2540 to capture this discussion. Feel free to chime in and/or to vote for this issue if you think it would be helpful for you.

Thanks,

Alex

Alexandre Dutra  |  Technical Manager, Drivers

alexand...@datastax.com  |  datastax.com

[adrian...@gmail.com]

Sadly my email is still locked from JIRA, and I don't yet feel strong enough to make another account to access it.

Consider my not noticing this thread and creating a redundant one a major +1 on this. Zipkin gets grief constantly for its larger image size. 2.8M is a significant amount more.. we've rewritten things out for less. I was really surprised as one reason for taking the tall effort for redoing everything from 3x->4.x was to get a smaller image. Now, it is larger only because of this.

https://groups.google.com/u/1/a/lists.datastax.com/g/java-driver-user/c/aN7NkxX_yQk/m/04Ws7UkwAgAJ

Good luck and really hope this gets solved.

[Alexandre Dutra]

Hi Adrian,

We are very sorry to hear that all your efforts to migrate Zipkin to driver 4 have been thwarted by this issue with the shaded Guava artifact size.

Unfortunately the whole team is currently affected on other projects at DataStax and we won't have the bandwidth to fix this issue in a timely manner for you.

Would it be possible for you or someone in your team to tackle JAVA-2540 and open a PR for it against the java-driver-shaded-guava repo ? Just a tweak to the Maven pom to reduce the artifact final size would be enough for now. If so, then we would make sure to merge it, release it and then test it against the current driver 4.x branch. And if all this passes, we would take care of releasing driver 4.10 asap for you.

Apologies for not being as helpful as we wish we could be.

Good luck,

Alex Dutra

--

Alexandre Dutra

e. alexand...@datastax.com
w. www.datastax.com

[Adrian Cole]

To be fair, the whole effort wasn't lost, it is just a surprise that a reduction in dependencies (driver 4 was initially marketed as guava free) ends up in just another larger flavor of the same.

There's no team per se I can dispatch to. I'm an unpaid volunteer as are others. Almost no one is working on the cassandra code, which is the only reason I took it up as it was starting to become a liability to the project. It felt like if I didn't spend the human month updating no one would, so I just did it for the team. That said, I've really spent dramatically more time on this than can justify digging deeper personally.