Java sun.reflect.CallerSensitive 注释是什么意思？

What does the sun.reflect.CallerSensitive annotation mean?

提问by Kumar Abhinav

What is implied by @CallerSensitiveannotation above methods?

@CallerSensitive上述方法的注释暗示了什么？

For example,the annotation is present in getClassLoader method of Class

例如，该注解存在于 Class 的 getClassLoader 方法中

 @CallerSensitive
    public ClassLoader getClassLoader() {
    //
    }

采纳答案by Sotirios Delimanolis

According to the JEP I linked to in the comments (also here),

根据我在评论中链接的 JEP（也在这里），

A caller-sensitive method varies its behavior according to the class of its immediate caller. It discovers its caller's class by invoking the sun.reflect.Reflection.getCallerClassmethod.

调用者敏感方法根据其直接调用者的类改变其行为。它通过调用sun.reflect.Reflection.getCallerClass方法发现其调用者的类。

If you look at the implementation of Class#forName(String)

如果你看一下实现 Class#forName(String)

@CallerSensitive
public static Class<?> forName(String className)
            throws ClassNotFoundException {
    return forName0(className, true,
                    ClassLoader.getClassLoader(Reflection.getCallerClass()));
}

, you notice that it is using Reflection.getCallerClass(). If we look at that method

，您注意到它正在使用Reflection.getCallerClass(). 如果我们看看那个方法

Returns the class of the caller of the method calling this method, ignoring frames associated with java.lang.reflect.Method.invoke()and its implementation.

返回调用此方法的方法的调用者的类，忽略与其关联的帧java.lang.reflect.Method.invoke()及其实现。

@CallerSensitive
public static native Class getCallerClass();

The problem, it seems, before this JEP, was that if the caller sensitive method was called through reflection instead of directly, there had to be a complex process to identify what the actual calling class was. This was problematic if the method was invoked through reflection. A simpler process was proposed (and introduced) with @CallerSensitive.

在此 JEP 之前，问题似乎在于，如果调用者敏感方法是通过反射而不是直接调用，则必须有一个复杂的过程来识别实际调用类是什么。如果该方法是通过反射调用的，则这是有问题的。提出（并引入）了一个更简单的过程@CallerSensitive。

Basically, the @CallerSensitiveannotation is used by the JVM

基本上，@CallerSensitive注解被JVM使用

The JVM will track this annotation and, optionally, enforce the invariant that the sun.reflect.Reflection.getCallerClassmethod can only report the caller of a method when that method is marked with this annotation.

JVM 将跟踪此批注，并可选择强制执行不变式，即该sun.reflect.Reflection.getCallerClass方法只能在使用此批注标记该方法时报告该方法的调用者。

回答by Tom Hawtin - tackline

From jdk.internal.reflect.CallerSensitive

从 jdk.internal.reflect.CallerSensitive

A method annotated @CallerSensitive is sensitive to its calling class, via Reflection.getCallerClass or via some equivalent.

带有 @CallerSensitive 注释的方法对其调用类很敏感，通过 Reflection.getCallerClass 或通过一些等价物。

The equivalent would be java.lang.StackWalker.getCallerClasssince Java SE 9.

等价的是java.lang.StackWalker.getCallerClass自 Java SE 9 以来。

This is effectively the security model of Java versions 1.0 and 1.1, which implemented a sort of pauper's linker checking. It's a coherent approach except for anything related to reflection but is exteremely fragile. The more restrictive Java 2 security model, on the other hand, is magic and doesn't show its workings.

这实际上是 Java 1.0 和 1.1 版的安全模型，它实现了一种贫乏的链接器检查。除了与反射相关的任何内容外，这是一种连贯的方法，但非常脆弱。另一方面，限制性更强的 Java 2 安全模型是神奇的，并没有显示其工作原理。

@CallerSensitivemethods alter behaviour depending upon the class that called them. This is always surprising, but then so is the Java 2 stack-inspection security model. To make matters worse, these method calls are particularly useful for classes that are working on behalf of their caller, so the context is wrong anyway.

@CallerSensitive方法根据调用它们的类改变行为。这总是令人惊讶，但 Java 2 堆栈检查安全模型也是如此。更糟糕的是，这些方法调用对于代表调用者工作的类特别有用，因此上下文无论如何都是错误的。

The Secure Coding Guidelines for Java SEcovers this area.

Java SE的安全编码指南涵盖了这一领域。

• Guideline 9-8 / ACCESS-8: Safely invoke standard APIs that bypass SecurityManager checks depending on the immediate caller's class loader
• Guideline 9-9 / ACCESS-9: Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance
• Guideline 9-10 / ACCESS-10: Be aware of standard APIs that perform Java language access checks against the immediate caller
• Guideline 9-11 / ACCESS-11: Be aware java.lang.reflect.Method.invoke is ignored for checking the immediate caller
• Guideline 9-12 / ACCESS-12: Avoid using caller-sensitive method names in interface classes

• 准则 9-8 / ACCESS-8：根据直接调用者的类加载器，安全地调用绕过 SecurityManager 检查的标准 API
• 准则 9-9 / ACCESS-9：使用直接调用者的类加载器实例安全调用执行任务的标准 API
• 准则 9-10 / ACCESS-10：注意针对直接调用者执行 Java 语言访问检查的标准 API
• 准则 9-11 / ACCESS-11：注意 java.lang.reflect.Method.invoke 在检查直接调用者时被忽略
• 准则 9-12 / ACCESS-12：避免在接口类中使用调用者敏感的方法名称

The introduction of modules in Java SE 9 has meant that some of the details have changed.

Java SE 9 中模块的引入意味着一些细节发生了变化。

Additionally if the @CallerSensitivemethod is called with Method.invokesome of the stack frames are ignored by getCallerClass. Internally the JDK uses a "trampoline" ClassLoaderto act as a benign dummy caller. java.lang.invoke.MethodHandlecopies problems of Method.invoke. The AccessController.doPrivilegedmethods are also problematic with the consequences of the specification being surprising.

此外，如果@CallerSensitive使用Method.invoke某些堆栈帧调用该方法，则getCallerClass. 在内部，JDK 使用“蹦床”ClassLoader来充当良性虚拟调用者。java.lang.invoke.MethodHandle的副本问题Method.invoke。这些AccessController.doPrivileged方法也有问题，规范的结果令人惊讶。

JEP 176: Mechanical Checking of Caller-Sensitive Methodsdeals with the particular @CallerSensitivejdk-internal annotation. The method lists in the Guidelines were generated by a FindBugs plug-in but then manually updated.

JEP 176：调用者敏感方法的机械检查处理特定的@CallerSensitivejdk 内部注释。指南中的方法列表由 FindBugs 插件生成，但随后手动更新。