Differences in reflection between JDK 1.8 and JDK 16

Question

The following statement was executed in both Oracle JDK1.8 and OpenJDK 16, but the different results returned. Founded during daily developping, the confusing issue is whether the difference are intended to be so or just an obscure bug? I've already done searching the similary questions but no expected ones was founded.

Examples,

Field[] declaredFields = Field.class.getDeclaredFields();
// Field[12] with all private fields which are expected. (JDK 1.8)
// Empty field array. (JDK 16)

Through debug mode, the critical statements are located: line 293, 309 in jdk.internal.reflect.Reflections. Those methods left without javadoc.

// line 293
return (Field[])filter(fields, fieldFilterMap.get(containingClass));

// line 309
if (filteredNames.contains(WILDCARD)) {
    return (Member[]) Array.newInstance(memberType, 0);
}

Answer 1

This is not an obscure bug but by intention.

Although the filterFields() method doesn't have a JavaDoc comment, the referenced fieldFilterMap field has ( https://github.com/openjdk/jdk9/blob/master/jdk/src/java.base/share/classes/jdk/internal/reflect/Reflection.java#L42 )

Used to filter out fields and methods from certain classes from public view, where they are sensitive or they may contain VM-internal objects.

As the referenced source is from Java 9 it was introduced intentionally and a comparison with the Java 16 source shows that the number of excluded fields has increased since that time.

---

Is there a way around this restriction? I don't think so.

According to the issue tracker: Improve filtering for classes with security sensitive fields :

The filters maintained by core reflection are a useful band aid to avoid leaking Field or Method objects to untrusted code. The filtering mechanism can be improved to filter out all fields from highly security sensitive classes such as Class, ClassLoader and some of the java.lang.reflect classes.

Every way around this restriction will probably be considered a security issue and will be closed in the next security update.

---

Unfortunately you don't state why you need this access. You need to change your code to not rely on access to these fields.

Please also note that most of the fields are accessible through getter methods.