I don't find anything Jersey does to be a compelling argument - indeed I find their packaging into a million tiny fragments a significant PITA (as well as their seemingly never-ending NIH syndrome - I suspect their isolation of has more to do with that than other concerns). Producing a jersey-guava.jar (or indeed a docker-guava.jar) is potentially a good option, but repackaging guava inside that is a bad one.

So - provided that it' can be agreed that guava is a 'good' library, then I think doing this kind of (static) repackaging is an anti-pattern, and there's better ways of achieving the same goal. Guava use should be encouraged - it has many other good parts, in particular things like string splitting, immutability, functional iterators, and (the one I was using and this patch nixed) optional.

So the only downside is - it's a 2.2Mb Jar. To which my initial reaction is somewhat along the lines of 'really? 2.2Mb is an issue for you? In 2015?'. Secondly, for large numbers of users, it's actually zero-cost, because guava is used a lot (the dependency should probably declare a wide range of acceptable versions rather than '18.0').

But assuming I think it's a worthwhile usecase to be running docker-java on wristwatch, or whatever other usecase it is that 2.2Mb of diskspace is an issue for - there's 3 other options :

Run proguard or any static analysis tool on your output binary. This will 'strip' it down to the bare minimum (and not just guava, it'll minify everything). Disk constrained clients should probably be doing this as a matter of course anyway.
Produce a separate docker-guava.jar, containing just the guava classes you'd like. That allows clients to specify a maven stanza that excludes the default transitive guava, and includes your docker-guava stripped edition. With some work you could likely automate this.
Produce a separate, additional docker-java-xxx-nodeps.jar, but utilising maven to build you an uberjar, and shading (maven-shade-plugin) the dependencies. That'd satisfy the 'java on my wristwatch' brigade who are scared of static analysis tools like proguard.

Set against this, by repackaging classes inside docker-java:

You sacrifice disk space (which I don't care about) for memory footprint (that I do). I'll now have 3 separate implementations of Preconditions floating around by JVM.
Relying on Jersey's Preconditions is arguably worse, as that's now coupling any classes in docker-java that use it directly to jersey. What happens when a point release removes it altogether?
It's bad news for other constructs like Optional - because of methods like

abstract Optional or(Optional<? extends T> secondChoice);

(I.E: your client code is going to be awful if you have multiple Optional<> type definitions around)

You create a barrier to using other library features (I must Cut&Paste)
You create a maintenance headache (what if bugs are found in the initial library?)
You can find yourself having accidentally forked a library (new feature gets added or bug gets fixed in code that originally came from guava). Even supposing the licenses are compatible (the same, in this instance), you find one or more author unwilling to sign the google CLA.

Please revert ad7881a #140

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions