30

In java8 it was possible to access fields of class java.lang.reflect.Fields using e.g.

Field.class.getDeclaredFields();

In java12 (starting with java9 ?) this returns only a empty array. This doesn't change even with

--add-opens java.base/java.lang.reflect=ALL-UNNAMED

set.

Any ideas how to achieve this? (Appart from the fact that this might be a bad idea, i want to be able to change a "static final" field in my code during junit testing via reflection. This has been possible with java8 by changing the "modifiers"

Field modifiersField = Field.class.getDeclaredField("modifiers");
modifiersField.setAccessible(true);
modifiersField.setInt(myfield, myfield.getModifiers() & ~Modifier.FINAL);

)

Jorn Vernee
  • 28,972
  • 3
  • 72
  • 84
Henning
  • 1,121
  • 2
  • 10
  • 20
  • 2
    I suggest taking a step back and overthinking your whole setup. Why do you want to mutate a `static` field in the first place? – Lino May 08 '19 at 11:08
  • 1
    @Lino This is because i need to replace a logger by a "testable" Logger implementation. I am quite sure that there are a other approaches to solve this, but i want to understand what has changed, why and where it might be documented... – Henning May 08 '19 at 11:22
  • 2
    IMO you should not test a logger. But the real question is still valid. – Lino May 08 '19 at 11:28
  • 10
    This seems to be the change: https://bugs.openjdk.java.net/browse/JDK-8210496 Came in JDK 12 – Jorn Vernee May 08 '19 at 11:29
  • 2
    You can still modify final fields via `sun.misc.Unsafe`, but as the name implies, it may or not break everything. – Benjamin Urquhart May 08 '19 at 12:50

4 Answers4

42

The reason this no longer works in Java 12 is due to JDK-8210522. This CSR says:

Summary

Core reflection has a filtering mechanism to hide security and integrity sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s). The filtering mechanism has been used for several releases to hide security sensitive fields such as System.security and Class.classLoader.

This CSR proposes to extend the filters to hide fields from a number of highly security sensitive classes in java.lang.reflect and java.lang.invoke.

Problem

Many of classes in java.lang.reflect and java.lang.invoke packages have private fields that, if accessed directly, will compromise the runtime or crash the VM. Ideally all non-public/non-protected fields of classes in java.base would be filtered by core reflection and not be readable/writable via the Unsafe API but we are no where near this at this time. In the mean-time the filtering mechanism is used as a band aid.

Solution

Extend the filter to all fields in the following classes:

java.lang.ClassLoader
java.lang.reflect.AccessibleObject
java.lang.reflect.Constructor
java.lang.reflect.Field
java.lang.reflect.Method

and the private fields in java.lang.invoke.MethodHandles.Lookup that are used for the lookup class and access mode.

Specification

There are no specification changes, this is filtering of non-public/non-protected fields that nothing outside of java.base should rely on. None of the classes are serializable.

Basically, they filter out the fields of java.lang.reflect.Field so you can't abuse them—as you're currently trying to do. You should find another way to do what you need; the answer by Eugene appears to provide at least one option.


Note: The above CSR indicates the ultimate goal is to prevent all reflective access to internal code within the java.base module. This filtering mechanism seems to only affect the Core Reflection API, however, and can be worked around by using the Invoke API. I'm not exactly sure how the two APIs are related, so if this isn't desired behavior—beyond the dubiousness of changing a static final field—someone should submit a bug report (check for an existing one first). In other words, use the below hack at your own risk; try to find another way to do what you need first.


That said, it looks like you can still hack into the modifiers field, at least in OpenJDK 12.0.1, using java.lang.invoke.VarHandle.

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;

public final class FieldHelper {

    private static final VarHandle MODIFIERS;

    static {
        try {
            var lookup = MethodHandles.privateLookupIn(Field.class, MethodHandles.lookup());
            MODIFIERS = lookup.findVarHandle(Field.class, "modifiers", int.class);
        } catch (IllegalAccessException | NoSuchFieldException ex) {
            throw new RuntimeException(ex);
        }
    }

    public static void makeNonFinal(Field field) {
        int mods = field.getModifiers();
        if (Modifier.isFinal(mods)) {
            MODIFIERS.set(field, mods & ~Modifier.FINAL);
        }
    }

}

The following uses the above to change the static final EMPTY_ELEMENTDATA field inside ArrayList. This field is used when an ArrayList is initialized with a capacity of 0. The end result is the created ArrayList contains elements without having actually added any elements.

import java.util.ArrayList;

public class Main {

    public static void main(String[] args) throws Exception {
        var newEmptyElementData = new Object[]{"Hello", "World!"};
        updateEmptyElementDataField(newEmptyElementData);

        var list = new ArrayList<>(0);

        // toString() relies on iterator() which relies on size
        var sizeField = list.getClass().getDeclaredField("size");
        sizeField.setAccessible(true);
        sizeField.set(list, newEmptyElementData.length);

        System.out.println(list);
    }

    private static void updateEmptyElementDataField(Object[] array) throws Exception {
        var field = ArrayList.class.getDeclaredField("EMPTY_ELEMENTDATA");
        FieldHelper.makeNonFinal(field);
        field.setAccessible(true);
        field.set(null, array);
    }

}

Output:

[Hello, World!]

Use --add-opens as necessary.

Community
  • 1
  • 1
Slaw
  • 30,631
  • 6
  • 43
  • 69
  • 7
    This approach may break at any time so best not to rely on it. In general, nobody should expect to be able to change a static final field. The long standing recommendation for mocking and other testing tools is to use an agent and drop the final modifier of fields that you want to mock. – Alan Bateman May 09 '19 at 12:36
  • So... as a non Java developer: "How does one 'Extend the filter to all fields' of the classes listed in this super popular answer?". How and where? What should I do with the provided list of classes to get to the promised land? I was just handed a legacy library where I was supposed to change a string and build a new jar file. All the tests seems to fail because of this issue. "java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers" – MrMambo007 Jun 09 '20 at 10:29
  • @MrMambo007 My answer is only meant to show that `VarHandle` can, at least for the moment, be used in place of reflection to access "forbidden" internals. How one integrates this into their application is highly dependent on the application. I can only suggest you follow the stack trace to where your library uses reflection and see if you can switch over to `VarHandle` with minimal disruption to the rest of the code. Assuming there's little to no code duplication and adequate abstraction the change shouldn't be too hard. If you need more specific help consider asking a new question. – Slaw Jun 09 '20 at 14:15
  • 4
    There seems to be general pattern of the invoke package not performing the same checks as reflect, e.g. you can instantiate new enum constants without a problem. By the way, as long as your code belongs to the unnamed module, you can even eliminate the warning programmatically via inserting `Module java_base = Field.class.getModule(), unnamed = FieldHelper.class.getModule(); java_base.addOpens("java.lang.reflect", unnamed); java_base.addOpens("java.util", unnamed);` at the beginning of `FieldHelper`’s initializer. – Holger Jun 12 '20 at 07:07
12

You can't. This was a change done on purpose.

For example, you could use PowerMock and it's @PrepareForTest - under the hood it uses javassist (bytecode manipulation) if you want to use that for testing purposes. This is exactly what that bug in the comments suggests to do.

In other words, since java-12 - there is no way to access that via vanilla java.

Eugene
  • 110,516
  • 12
  • 173
  • 277
8

I found a way and it worked on JDK 8, 11, 17.

Method getDeclaredFields0 = Class.class.getDeclaredMethod("getDeclaredFields0", boolean.class);
getDeclaredFields0.setAccessible(true);
Field[] fields = (Field[]) getDeclaredFields0.invoke(Field.class, false);
Field modifiers = null;
for (Field each : fields) {
    if ("modifiers".equals(each.getName())) {
        modifiers = each;
        break;
    }
}
assertNotNull(modifiers);

Don't forget to set the following args when using JDK 11 or higher:

--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED
Wu Weijie
  • 111
  • 1
  • 5
  • 1
    Nice, this indeed works with JDK17! This allows us to upgrade a project to JDK17, and workaround a bug - until our fix is officially integrated into the JDK. – Florian Kirmaier Nov 04 '21 at 13:23
4

This works in JDK 17.

import java.lang.reflect.Field;
import sun.misc.Unsafe;

/**
 * @author Arnah
 * @since Feb 21, 2021
 **/
public class FieldUtil{

    private static Unsafe unsafe;

    static{
        try{
            final Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
            unsafeField.setAccessible(true);
            unsafe = (Unsafe) unsafeField.get(null);
        }catch(Exception ex){
            ex.printStackTrace();
        }
    }

    public static void setFinalStatic(Field field, Object value) throws Exception{
        Object fieldBase = unsafe.staticFieldBase(field);
        long fieldOffset = unsafe.staticFieldOffset(field);

        unsafe.putObject(fieldBase, fieldOffset, value);
    }
}
public class YourClass{
    public static final int MAX_ITEM_ROWS = 35_000;
}

FieldUtil.setFinalStatic(YourClass.class.getDeclaredField("MAX_ITEM_ROWS"), 1);
kyakya
  • 1,854
  • 1
  • 20
  • 23
  • 3
    1) `public static final int MAX_ITEM_ROWS = 35_000;` is a compile-time constant. At each place where `MAX_ITEM_ROWS` is read, the constant value `35_000` is already inserted at compile-time. 2) Of course, you won’t notice when your example is trying to set the field’s value to `35_000`, the same value it already has. Of course, when “no change” is considered a success, it will look like a success everywhere. 3) if you were able to read the value you’ve written, you’d notice that this code failed badly. You are setting an *object reference* to an *int* variable. Only `Unsafe` makes it possible… – Holger Apr 06 '22 at 09:12