So it does look like a tidal wave of support for making it a public
dependency, with a few lone dissenters. I'll try to lay out the reasons I
think making it a public dependency isn't as great as it sounds, but that
said -- I won't stand in the way of doing it.
First, the only reasons why a public dependency is good: It reduces code
duplication.
To me, that's the only reason I understand. I frankly don't understand any
of the other reasons. Here's a few that were listed:
a) *Wanting to upgrade the packaged dependencies.*
In my head, this is equivalent to saying, "I'd like to take the Guice
source and modify it a bit." The fact it uses Guava is entirely, 100% an
implementation detail. Why would you ever need to upgrade the packaged
dependency? It's not something that should matter to a user.
b) *A reason for wanting to upgrade dependencies: security/performance.*
Again, this seems like it applies equally true to the core Guice code
itself. If you're going to be inspecting implementation details of a
library, you may as well go into the source & build your own distribution of
it.
c) *Not trusting Jarjar. *
Sorry, this just isn't a valid reason to me. JarJar works. It does
exactly what you're saying: recursive dependency analysis. It reads the
bytecode for classes you're asking to move and makes sure that any
referenced classes are found in the right place. Of course it fails on
reflection, but you just don't use it for things that need reflection. I
haven't worked with ProGuard much, but AFAIK, a whole ton of apps use it,
and it works fine.
d) *A complete copy of Guava is inside Guice
*If this were the case, I'd be inclined to go along with the prevailing
sentiment.. but it's not true. Guava itself is 1.1mb. Guice after the
change to use JarJar'd Guava is ~1mb. That's clearly not the whole of
Guava. In fact, it's just bits of two packages:
com.google.common.{base,collect} and two classes from com.google.common.io.
A tiny fraction of Guava.
The reasons why I think exposing the dependency is a bad idea:
1) Where do we stop? Should we expose cglib & asm as real dependencies that
can be upgraded too (real question)? That exposes the means by which Guice
is doing its bytecode manipulation for grabbing line numbers & for AOP. If
Guice decides to change how it does it, then people may have a false
dependency/requirement on cglib & asm.
2) It's as if com.google.inject.internal APIs were exposed -- its something
that Guice should be free to change without any user having to take any
action at all, but now we're forcing them to think & act on it.
3) Guice has averaged 2 year releases (for better or worse). Guava gives
~1.5 year leeway before removing any APIs Should we be forced to release a
new version of Guice because a dependency changed its API? If we don't
release a new one, that gets into some severe versioning hell.
sam
On Tue, Jul 5, 2011 at 9:30 PM, Bob Lee <[email protected]> wrote:
> +1 to making Guava a public dependency! It sounds like we're almost all in
> agreement.
>
> Bob
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
