+1 Sam (use proguard to hide implementation details) -- TJ
On Wed, Jul 6, 2011 at 9:41 AM, Tim Peierls <[email protected]> wrote: > I'm with Sam and Alen. > I use Guice and Guava in everything. To program otherwise, imho, is to tie > your hands behind your back. So you'd think I wouldn't mind having one > depend on the other, but I persist in seeing them as completely independent > tools. The fact that one uses bits of the other internally doesn't matter to > me, as long as it can be arranged that it doesn't contribute greatly to the > jar size. > --tim > > > On Wed, Jul 6, 2011 at 10:12 AM, Sam Berlin <[email protected]> wrote: >> >> 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. > > -- > 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.
