Comment #32 on issue 258 by bileblog: [Patch] custom annotation based injection points http://code.google.com/p/google-guice/issues/detail?id=258
I agree 100% with James' comments, but have far far less patience than he does. I'v jumped off the guice ship months ago, and whenever asked, I recommend that people avoid it. The reasoning is exactly the same as James'. The constant refusal to add support for annotations that are in use by everyone, require no new knowledge, that have become commonplace everywhere else is perplexing, to say the least. The argument that javax.* is bad code and com.* is good code is....and I'm putting this in the most polite way I know...idiotic, moronic, and ignorant. Have you any idea how much bad com.* code is out there? However, I won't get sidetracked by addressed such a silly claim, and will stick to the point at hand. It's perplexing to me that after being assured a year or two ago that Guice will provide infrastructure to support these common annotations, the solution now has gone to 'sorry, we don't trust them'. Even the Guice BOF at JavaOne last year made comforting noises about the ability to support custom annotations via listeners. In fact, I'm fairly sure that I've filed an issue more or less after the first first Guice public preview stating the need for these annotations. It's become abundantly clear that Guice's priorities are much the same as Google's priorities when it comes to open source that it uses in house, Google first, and if that happens to benefit the community incidentally, then that's great, if not, then that's great too. You keep wondering why people care, and the answer is simple. It's less to learn, it lowers the barrier to entry, and saves you a few extra seconds of thinking 'now how do I do the thing I've been doing for months elsewhere...' I work with a lot of developers, and now they're all comfortable with things like @PreConstruct @Resource, @TranasactionAttribute, and so on. There's no sane reason why they should now have to learn another set of annotations that perform the exact same role if they ever want to use Guice, or even worse, being told that 'sorry, that model is not even possible, you need to think differently and pretend like Guice has it all figured out'. It reminds me of when the picocontainer guys refused to do setter injection, claiming constructor injection is the only way to go. Look at where pico is now. See, the community is perfectly happy for you to maintain your elitist selfish attitude to the codebase, and your refusal to add features that don't personally benefit you. It's the Guice way, and that's totally fine. What's infinitely more frustrating is your refusal to add extensions to enable other people to do what they need to do. Fine, don't add support for standard annotations if they insult your purist insular view of the world, but give us annotation listeners or whatever other infrastructure so that the rest of us who work in the real world can deal with such dirty concepts as javax.* code. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice-dev" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
