JDK注解详解

落日映苍穹つ 2024-04-19 12:41 39阅读 0赞

**1.JDK：@SuppressWarnings**

告诉编译器忽略指定警告，不用在编译完成后出现警告信息

*  @SuppressWarnings("unchecked")
    
     *  告诉编译器忽略 unchecked 警告信息，如使用List，ArrayList等未进行参数化产生的警告信息。
 *  @SuppressWarnings("serial")
    
     *  如果编译器出现这样的警告信息：The serializable class WmailCalendar does notdeclare a static final serialVersionUID field of type long使用这个注释将警告信息去掉。
 *  @SuppressWarnings("deprecation")
    
     *  如果使用了使用@Deprecated注释的方法，编译器将出现警告信息。使用这个注释将警告信息去掉。
 *  @SuppressWarnings("unchecked", "deprecation")
    
     *  告诉编译器同时忽略unchecked和deprecation的警告信息。
 *  @SuppressWarnings(value = \{"unchecked", "deprecation"\})
    
     *  等同于@SuppressWarnings("unchecked", "deprecation")

**2.JDK：@CallSensitive（sensitive：敏感的）**

*  [https://blog.csdn.net/HEL\_WOR/article/details/50199797][https_blog.csdn.net_HEL_WOR_article_details_50199797]
 *  JVM专用的注解，类加载过程中常常可以看见这个注解的身影
 *  StackOverFlow里的回答，答案提到了@CallSensitive用来找到真正发起反射请求的类。
 *  这个注解是为了堵住漏洞用的。曾经有黑客通过构造双重反射来提升权限，原理是当时反射只检查固定深度的调用者的类，看它有没有特权，例如固定看两层的调用者（getCallerClass(2)）。如果我的类本来没足够权限群访问某些信息，那我就可以通过双重反射去达到目的：反射相关的类是有很高权限的，而在 我->反射1->反射2 这样的调用链上，反射2检查权限时看到的是反射1的类，这就被欺骗了，导致安全漏洞。使用CallerSensitive后，getCallerClass不再用固定深度去寻找actual caller（“我”），而是把所有跟反射相关的接口方法都标注上CallerSensitive，搜索时凡看到该注解都直接跳过，这样就有效解决了前面举例的问题。

[https_blog.csdn.net_HEL_WOR_article_details_50199797]: https://blog.csdn.net/HEL_WOR/article/details/50199797