Yes, this is correct. The vote is IMHO still out whether using @Named and Strings or specific annotations are the better way to use; at $DAYJOB, engineering is almost evenly split. I would feel uncomfortable about the huge number of classes required but it certainly is an option to do it this way.
-h On Wed, May 26, 2010 at 11:08, Brian Eaton <[email protected]> wrote: > Guice binding annotations are another good option for some use cases: > > �...@retention(RetentionPolicy.RUNTIME) > �...@bindingannotation > public @interface SomeNewAnnotation {} > > Then later: > > �...@somenewannotation String foo; > > Cheers, > Brian > On Wed, May 26, 2010 at 11:00 AM, John Hjelmstad <[email protected]> wrote: >> Seems like a reasonable idea to me. >> >> On Wed, May 26, 2010 at 9:51 AM, Henning Schmiedehausen < >> [email protected]> wrote: >> >>> Hi, >>> >>> while working on our headless implementation of the RESTy part of >>> Opensocial, it took me quite some time to find all the @Named >>> annotations that I have to supply information for. I was wondering if >>> we could benefit from replacing all the >>> @Named("shindig.something.or.other") with constants. @ $WORKPLACE we >>> use something like this: >>> >>> >>> public abstract class NamedConstants >>> { >>> private NamedConstants() { >>> } >>> >>> public static final String REQUIRED_CONSTANT_NAME = "required.constant"; >>> public static final Named REQUIRED_CONSTANT_NAMED = >>> Names.named(REQUIRED_CONSTANT_NAME); >>> >>> } >>> >>> and in the code you would use >>> >>> >>> bind(Foo.class).annotatedWith(NamedConstants.REQUIRED_CONSTANT_NAMED).to(FooImpl.class); >>> >>> and >>> >>> public Baz(@Named(NamedConstants.REQUIRED.CONSTANT.NAME) Foo foo) { >>> ... } >>> >>> The advantage is that it is possible to figure out which constants are >>> in use in the code base, and (by adding meaningful comments to the >>> class above :-) ) figure out what they do. Also, the compiler will >>> catch possible typos in @Named and annotatedWith usage. >>> >>> The process of putting this in is pretty much mechanical but some >>> work. I can do that if no one objects strongly. >>> >>> -h >>> >> >
