> I have no problem with annotations in general. Here are my concerns: > - don't want code to depend on guice; jsr would be better here, for > the @Inject; but this issue is minor compared to the others
They are annotations, not interfaces. > - 3rd party code (or any code which I can't or shouldn't touch), can't > be annotated; I see there's ways around this with @Provider; seems a > bit verbose though. Verbose compared to what? XML? I find @Provider methods very compact for what they do. > - don't want interfaces coupled to implementations (referring to some > of the apparently optional annotations which I wouldn't use) You couple it to a default, which you can override in your modules. That means that you can avoid a lot of configuration when part of your infrastructure runs fine with defaults. Great future, but still something that people seem to misinterpret. > - don't want to comingle implementation with configuration; so, rather > have definition of wirings be in a Module, than as metadata > (annotations or whatever) directly in an implementation class > Yeah, I don't want xml either. :) I want Java code, I just want a > clear separation of configuration. Which Guice is perfectly capable of. I found that - besides the WIKI - browsing through unit tests was a good way to get an idea of what Guice can do and how. Eelco -- 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.
