在编程中，一直强调的一点就是注释的编写，注释的规范等等。尤其是越是核心，程序越复杂，逻辑越多的清空下，注释的编写对我们以后的阅读代码，维护软件起着至关重要的作用。一款软件有着好的注释，相当于一个中国人阅读一篇带着汉语翻译的英文文章，其阅读速度是事半功倍的效果。但是今天想要总结的却不是代码中的注释需要注意的问题，而是JDK5.0以后提供的一种新特性。
一， Annotation(注解)，其实就是对类，方法，属性进行的一种标示，一种注释（注意，这个里注释不是为了让我们开发或维护人员阅读更方便，而是为JVM看呢），通过这些标示，Java虚拟机可以完成这些标示对应的功能。例如使用框架开发时，我们都是通过配置文件进行对象关系组合映射等功能，而通过注解我们可以完全代替配置文件的编写。
二，Annotation的作用：
编写文档：通过代码里标识的元数据生成文档。
代码分析：通过代码里标识的元数据对代码进行分析。
编译检查：通过代码里标识的元数据让编译器能实现基本的编译检查。
三，JDK内置的几个常用注解：
1，@Override:此注解能够实现编译时检查，当某方法前边添加此注解时，表示此方法为重写父类中的方法。如果此方法不是父类的方法，例如我们本来想重写toString呢，却写成了tostring，则编译无法通过，会提示错误。
2,@Deprecated:此注解是对不应该，或者将要淘汰的方法进行标识，当编程人员使用时就会给予提示。这个功能在一些基础jar包，规范，框架等的中我们经常可以看到，还保留这些方法是为了兼容前边的一些版本，有一过度的阶段。看下边的这种效果应该都见过：
3，@SuppressWanings:此注解表示去除一些警告，但是里边需要我们制定参数，我们来看一下一些常用的参数：
| 参数名称 |
参数解释 |
|
Unused |
没有被访问过的元素，去除警告 |
|
Unchecked |
执行了未检查的转换时的警告，例如当使用集合时没有用泛型来指定集合保存的类型 |
|
Fallthrough |
当Switch程序块直接通往下一种情况二没有Break时的警告 |
|
Path |
在类路径，源文件路径等中有不存在的路径时的警告 |
|
Serial |
当在可序列化的类上缺少serialVersionUID定义时的警告 |
|
Finally |
任何finally子句不能正常完成时的警告 |
|
All |
关于上边所有情况的警告 |
4, 当然我们也可以通过@interface进行自定义注解的定义，我们可以像@SuppressWanings一样向里边添加参数，利用@Target注解来指定其使用范围；@Documented表示此注解是否文档化，就是当我们生成文档时，是否生成进去；@Inherited标注继承，控制此注释是否会影响到子类等等。看一下自定注解的简单例子：
@Target({ElementType.METHOD,ElementType.CONSTRUCTOR})
@Documented
@Inherited
public@interfaceNewAnnotation {
String value();//在写注解的时候value参数中value=可以省略，其它参数名不能省
}
也就是说后边这几个注解是用来给注解做注解的，也就是注解的注解。当然了这些JDK为我们提供的一些常见的注解。而在实际开发中我们都是通过对类，对方法添加注解来代替配置文件的编程，从而从开发效率上大大提高了。
最后看一下通过注解开发和配置文件开发的对比吧：
|
配置文件的开发 |
注解方式开发 |
|
|
优点 |
1，遵循OCP开发原则，修改配置文件即可进行功能扩展 2，集中管理对象和对象之间的组合关系，易于阅读 |
1，开发速度快 2，编译期间容易发现错误的出处 |
|
缺点 |
1，开发速度相对较慢； 2，编译时很难检查出错误，运行中的错误很难定位，调试难度较大。 |
1，管理分散，基本每个类上都有； 2，扩展功能时，没有遵循OCP开发原则。 |
|
何时选择 |
如果客户需求进行发生变化，那么采用配置文件的方式会好一些。有利于扩展。 |
如果客户需求不会频繁发生变化。那么使用注解非常好，开发效率快 |
总而言之，注解开发是当今的一个开发趋势，因为它的开发效率高，谁都想着在最短的时间内创造最大的价值。但是使用还需慎重考虑，根据实际情况进行选择。这里简单介绍了注解的基础，下边主要将在使用框架开发中，如何利用注解帮助我们提高效率