On Sun, Mar 23, 2008 at 8:30 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 22, 2008 at 11:28 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > If anyone has strong objections to Guice, feel free to speak up -- I've > > personally never used it myself, but I've heard good things from other > > people about it, and it seems to me to be a bit easier than Spring. > > What problem is Guice going to solve? The only real problem that Guice can solve -- inversion of control (including dependency injection). CrossServletState does this now, but Guice normalizes it and makes it quite a bit simpler. Adding support for it has so far overall definitely improved the cleanliness of the code. I'll be sending a patch around tomorrow to let everyone else judge for themselves whether they prefer what we're doing with CrossServletState now to what we can do with Guice. What will the process for adding a new external dependency look like > once we are using Guice? Not much different at all. Mostly we'll just have to add the appropriate binding to the Guice module. In most cases this will be as simple as a single line (in addition to the actual code changes necessary to support the new feature): bind(SomeInterface.class).to(SomeImplementation.class) I don't have strong objections to Guice, never having used it. But > I'm slightly suspicious of plans to replace a single java class with > an entire framework. CrossServletState is an ugly hack, but it's a > *simple* ugly hack. > The bright side is that Guice isn't really much of a "framework" (at least not in the Spring / Struts / Tapestry sense of the term). The total amount of Guice specific code consists of: - Two new classes (one of which will disappear when Guice 2.0 becomes available) -- these replace 3 existing classes in shindig, so that's a net win. - Adding a single annotation to constructors - Adding a new method to the servlets -- we also get to remove one method, so this is a net win as well. I share your concerns as well, having been burned all too often by heavyweight "frameworks" that just make writing code more difficult than it needs to be, and I was initially opposed to Guice, but having tried it first hand I feel that it's a very elegant way to solve the problem, and it looks like a variant of the same technique is going to wind up in JSR-299, so it's a pretty sound decision going forward. I'm sure other people who've worked with Guice directly (I believe both John H and Cassie have) will have more insight. Initial impressions from my standpoint are pretty high. -- ~Kevin
