中了annotation的毒了

在1.4上，我最喜欢玩的是dynamic proxy。以前的那个Sum的“奇技淫巧”就人人喊打来着。自打不用担心对1.3, 1.4的兼容问题后，我发现我越来越爱拿着annotation的锤子到处乱砸了，而且是用reflection而不是apt。

给Guice加了一个@Provide的外壳：

class MyModule extends AbstractModule {
  @Provide @Singleton
  public Foo foo(FooImpl impl) {
    return impl;
  }

  @Provide @LittleStrong
  public Bar bar(A a, B b) {
    return new BarImpl(a, b);
  }
}

// 用来代替
bind(Foo.class).to(FooImpl.class).in(Singleton.class);
bind(Bar.class).annotatedWith(LittleStrong.class).toProvider(new Provider<Bar>() {
  @Inject A a;
  @Inject B b;
  public Bar get() {
    return new BarImpl(a, b);
  }
});

又给EasyMock加了@Mock的外壳：

public class FooTest extends PorkTest {
  @Mock private Foo foo;
  @Mock private Bar bar;
}

当考虑怎么样生成一个url字符串时，也是想用annotation:

public class User {
  @Param("username") String name;
  @Param("id") int id;
}
String queryString = QueryStringBuilder.build(new User("ajoo", 1));

绳啊，救～救我吧，一把年纪啦，该稳重一点，“企业”一点啦。我本来是讨厌@UglyRetardedWackyEwEwEwAnnotation来的。

XML正是被滥用后，人们才发现他的不足。
历史总是惊人的相似。

强烈bs在代码里加非功能性的annotation

你这个起码@Mock 还是在test里，
@Provide @Singleton  还是有点用的(尽管我觉得这种配置型的放到外面更好一点点)

居然有在代码里加混淆策略的annotation，请自己查看 proguard
让人觉得脑子发烧了
拜托，这些只是开发用的,不要污染了运行环境好不

同样的还有codegen型的,
例如hibernate 生成表结构的那些 length=10 ... (真有人用这个吗?)

总之,我的观点是:除非是运行时必要的东西,否则都不要放到代码里或配置文件里
如果要加,请另放一个地方,部署的时候剥离出去

不同意你的观点，length=10或许能帮助调用者获取验证条件。再说，javadoc是运行时必要的东西么？@Override也不是但很有用。annotation无非是个meta数据而已，他什么时候有用，通过RetentionPolicy来决定不就行了吗？

annotation除了用来压制一些编译警告，其他地方还从来没有觉得有用

所以说，要多学习呦，同学。

“混淆策略”？什么意思？

@Provide放到外面？你真的用过Guice?

   annotation是jdk新特性中最没有用的。可以用annotation搞出一些花样来，代码，配置，声明混在一起
不觉得有什么好，坚决不用。

proguard.sf.net

@KeepApplication
@KeepPublicGettersSetters
public class Application {
  @KeepClassMemberNames
  ....
 
  @Keep
  void xxx{}
 
}



Guice我没用过，和spring不一样？我印象中就是一个IOC，抱歉可能我想当然了

那我想说的是spring 的@Transactional @Autowired这种

好像前一阵这里提过说guice是针对spring用xml来配置，它是用annotation