转:Oracle弃用sun.reflect.Reflection.getCallerClass

http://www.infoq.com/cn/news/2013/07/Oracle-Removes-getCallerClass

作为Java开发者,我们经常忽略@Deprecated注释,继续使用这些功能,即使我们很清楚Oracle会在某个时间拿到这一标签,但仍然幻想着这些标签像刻在石头上那样不可磨灭。

jdk 7u40开始,Oracle已经弃用了sun.reflect.package包里不易理解的Reflection.getCallerClass(int)方法。在Java 7中,通过设置Java命令行选项Djdk.reflect.allowGetCallerClass,可以继续使用该方法。但在Java 8及以后的版本中,该方法将被彻底删除,调用它会导致UnsupportedOperationException异常。

根据Java文档,Reflection类位于调用栈中的0帧位置,该方法返回调用栈中从0帧开始的第x帧中的类。总之,getCallerClass方法提供的机制可用于确定调用者,从而实现“感知调用者(Caller Sensitive)”的行为,即根据调用类或调用栈中的其它类来调整其自身的行为。

JDK团队希望知道getCallerClass方法在应用程序中是如何使用的,能否修改这些代码使之不再依赖任何sun.* API。你可以加入OpenJDK core-dev-libs邮件列表来反馈意见。

多年来,Oracle一直在提醒开发者,调用sun.*包里面的方法是危险的。关于这点,读者可以阅读Oracle博客上的说明文章“为什么开发人员不应该调用‘sun’包”。总之,使用这些已弃用的特性很容易出问题。随着平台的变化,它们可能随时被转移、删除或者更改语义。

然而,如果你使用了感知调用者的行为,也无需失去信心。JDK增强提案(JEP176)呼吁提高JDK方法处理的实现的安全性,使用可以可靠地识别的感知调用者方法的机制代替现有的人工维护的方法列表。

继续关注该问题,可以访问Oracle Bug数据库

参考英文原文:Oracle Discontinuing sun.reflect.Reflection.getCallerClass



感谢马国耀对本文的审校。

时间: 2024-08-11 07:47:40

转:Oracle弃用sun.reflect.Reflection.getCallerClass的相关文章

sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to java.lang.Class异常解决方法

package com.wzs; import java.lang.reflect.ParameterizedType; public class T1<T> {     private Class classt;     public T1() {         ParameterizedType type = (ParameterizedType) this.getClass().getGenericSuperclass();         this.classt = (Class)

java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy

java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:724) at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:531)

sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

在使用Hibernate的J2EE项目中,莫名其妙出现如上错误,既不报错,也不运行不论什么输出測试代码,更不返回结果. 经过排查,在方法里面引用的实体类和其映射文件属性个数不一致. 改动一致后,即解决.

Java Magic. Part 4: sun.misc.Unsafe

原文地址 译文地址 译者:许巧辉 校对:梁海舰 Java是一门安全的编程语言,防止程序员犯很多愚蠢的错误,它们大部分是基于内存管理的.但是,有一种方式可以有意的执行一些不安全.容易犯错的操作,那就是使用Unsafe类. 本文是sun.misc.Unsafe公共API的简要概述,及其一些有趣的用法. Unsafe 实例 在使用Unsafe之前,我们需要创建Unsafe对象的实例.这并不像Unsafe unsafe = new Unsafe()这么简单,因为Unsafe的构造器是私有的.它也有一个静

Understanding sun.misc.Unsafe

转自: https://dzone.com/articles/understanding-sunmiscunsafe The biggest competitor to the Java virtual machine might be Microsoft's CLR that hosts languages such as C#. The CLR allows to write unsafe code as an entry gate for low level programming, so

Java并发框架——AQS之原子性如何保证?

在研究AQS框架时,会发现这个类很多地方都使用了CAS操作,在并发实现中CAS操作必须具备原子性,而且是硬件级别的原子性,java被隔离在硬件之上,明显力不从心,这时为了能直接操作操作系统层面,肯定要通过用C++编写的native本地方法来扩展实现.JDK提供了一个类来满足CAS的要求,sun.misc.Unsafe,从名字上可以大概知道它用于执行低级别.不安全的操作,AQS就是使用此类完成硬件级别的原子操作. Unsafe是一个很强大的类,它可以分配内存.释放内存.可以定位对象某字段的位置.可

并行编程(1) - sum.msic.Unsafe 一

相信看过java源代码的同学.对 sum.msic.Unsafe 这个类并不陌生,特别是在java.util.concurrent包有非常多的使用. sum.msic.Unsafe源代码:      http://www.docjar.com/html/api/sun/misc/Unsafe.java.html javadoc:      http://www.docjar.com/docs/api/sun/misc/Unsafe.html sum.msic.Unsafe是一个运行低级别(硬件级

从JDK源码角度看java并发的原子性如何保证

JDK源码中,在研究AQS框架时,会发现很多地方都使用了CAS操作,在并发实现中CAS操作必须具备原子性,而且是硬件级别的原子性,java被隔离在硬件之上,明显力不从心,这时为了能直接操作操作系统层面,肯定要通过用C++编写的native本地方法来扩展实现.JDK提供了一个类来满足CAS的要求,sun.misc.Unsafe,从名字上可以大概知道它用于执行低级别.不安全的操作,AQS就是使用此类完成硬件级别的原子操作. Unsafe是一个很强大的类,它可以分配内存.释放内存.可以定位对象某字段的

sun.misc.Unsafe的理解

以下sun.misc.Unsafe源码和demo基于jdk1.7: 最近在看J.U.C里的源码,很多都用到了sun.misc.Unsafe这个类,一知半解,看起来总感觉有点不尽兴,所以打算对Unsafe的源码及使用做个分析: 另外,网上找了份c++的源代码natUnsafe.cc(可惜比较老,Copyright (C) 2006, 2007年的,没找到新的),也就是sun.misc.Unsafe的C++实现,跟Unsafe类中的native方法对照起来看更加容易理解: Unsafe类的作用 可以