Change private static final field using Java reflection
Asked Answered
L

16

573

I have a class with a private static final field that, unfortunately, I need to change it at run-time.

Using reflection I get this error: java.lang.IllegalAccessException: Can not set static final boolean field

Is there any way to change the value?

Field hack = WarpTransform2D.class.getDeclaredField("USE_HACK");
hack.setAccessible(true);
hack.set(null, true);
Liberec answered 21/7, 2010 at 16:35 Comment(6)
Such a bad idea. I'd try to get the source and recompile (or even decompile/recompile) instead.Butterflies
System.out is a public static final field, but it can be changed too.Entire
@Entire System.out/in/err are so "special" that the Java Memory Model has to make special mention of them. They are not examples which should be followed.Phototopography
well my point ws to find a hack in the between to have my app working until the lib responsible make the change at the next release so i don't need to hack anymore...Liberec
@Bill K from ten years ago: It would be GREAT to recompile it but it's on a deployed system and I just need to patch it until we can update the deployed app!Butterflies
For Java 17 Get declared fields of java.lang.reflect.Fields in jdk12Birl
I
1021

Assuming no SecurityManager is preventing you from doing this, you can use setAccessible to get around private and resetting the modifier to get rid of final, and actually modify a private static final field.

Here's an example:

import java.lang.reflect.*;

public class EverythingIsTrue {
   static void setFinalStatic(Field field, Object newValue) throws Exception {
      field.setAccessible(true);

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

      field.set(null, newValue);
   }
   public static void main(String args[]) throws Exception {      
      setFinalStatic(Boolean.class.getField("FALSE"), true);

      System.out.format("Everything is %s", false); // "Everything is true"
   }
}

Assuming no SecurityException is thrown, the above code prints "Everything is true".

What's actually done here is as follows:

  • The primitive boolean values true and false in main are autoboxed to reference type Boolean "constants" Boolean.TRUE and Boolean.FALSE
  • Reflection is used to change the public static final Boolean.FALSE to refer to the Boolean referred to by Boolean.TRUE
  • As a result, subsequently whenever a false is autoboxed to Boolean.FALSE, it refers to the same Boolean as the one refered to by Boolean.TRUE
  • Everything that was "false" now is "true"

Related questions


Caveats

Extreme care should be taken whenever you do something like this. It may not work because a SecurityManager may be present, but even if it doesn't, depending on usage pattern, it may or may not work.

JLS 17.5.3 Subsequent Modification of Final Fields

In some cases, such as deserialization, the system will need to change the final fields of an object after construction. final fields can be changed via reflection and other implementation dependent means. The only pattern in which this has reasonable semantics is one in which an object is constructed and then the final fields of the object are updated. The object should not be made visible to other threads, nor should the final fields be read, until all updates to the final fields of the object are complete. Freezes of a final field occur both at the end of the constructor in which the final field is set, and immediately after each modification of a final field via reflection or other special mechanism.

Even then, there are a number of complications. If a final field is initialized to a compile-time constant in the field declaration, changes to the final field may not be observed, since uses of that final field are replaced at compile time with the compile-time constant.

Another problem is that the specification allows aggressive optimization of final fields. Within a thread, it is permissible to reorder reads of a final field with those modifications of a final field that do not take place in the constructor.

See also

  • JLS 15.28 Constant Expression
    • It's unlikely that this technique works with a primitive private static final boolean, because it's inlineable as a compile-time constant and thus the "new" value may not be observable

Appendix: On the bitwise manipulation

Essentially,

field.getModifiers() & ~Modifier.FINAL

turns off the bit corresponding to Modifier.FINAL from field.getModifiers(). & is the bitwise-and, and ~ is the bitwise-complement.

See also


Remember Constant Expressions

Still not being able to solve this?, have fallen onto depression like I did for it? Does your code looks like this?

public class A {
    private final String myVar = "Some Value";
}

Reading the comments on this answer, specially the one by @Pshemo, it reminded me that Constant Expressions are handled different so it will be impossible to modify it. Hence you will need to change your code to look like this:

public class A {
    private final String myVar;

    private A() {
        myVar = "Some Value";
    }
}

if you are not the owner of the class... I feel you!

For more details about why this behavior read this?

Ivanivana answered 21/7, 2010 at 16:46 Comment(31)
When I saw this: System.out.format("Everything is %s", false); // "Everything is true" I thought you were screwing with us, then I read the rest of your code, but it brings up a readability question, some things your just accept as true (or in this case, false).Farcy
@thecoop, @HalfBrian: there is no doubt that this is EXTREMELY EVIL, but this example was chosen by design. My answer only shows how, in some circumstances, this is possible. The most disgusting example that I can think of is deliberate chosen with the hope that perhaps people would be instantly disgusted by instead of falling in love with the technique.Ivanivana
Yo, dawg. I heard you like reflection, so I reflected on field so you can reflect while you reflect.Connotation
I want to use this for testing by replacing a singleton with a mock object without compromising the singleton in production code.Overcrop
Note that Boolean.FALSE is not private.Does this really work with "private final static" members?Xenophon
@Xenophon it does, but you have to use getDeclaredField() instead of getField() for target classAgalloch
+1. For those who will try to change something like final String myConstant = "x"; and will fail: remember that compile time constants will be inlined by compiler so when you will write code like System.out.println(myConstant); it will be compiled as System.out.println("x"); because compiler knows value of constant at compile time. To get rid of this problem you need to initialize your constants at runtime like final String myConstant = new String("x");. Also in case of primitives like final int myField = 11 use final int myField = new Integer(11); or final Integer myField = 11;Viehmann
Note that you can check the SecurityManager beforehand to see if you're allowed to do this: final SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(new java.lang.reflect.ReflectPermission("suppressAccessChecks")); }Challah
Appears it does not work with static final fields of primitive types even if they are initialized with something that is not compile time constant (property access in my case).Superstratum
I tried to use your code one Android, but modifiers said NoSuchField.. Android uses Java 1.7 I believe.Marchal
Never mind, looking at the Android source, I found out, that the "modifiers" field is "accessFlags" on Android.Marchal
Why this business with modifying bitmasks?.setAccessible(true) turns of all language checks anyways right?Mcfadden
What is "modifiers"? Does it some kind of system field that is generated automatically by compiler? How this one is related to field method parameter (value of which we are trying to change)?Vanillic
@Vanillic modifiers is a private member of the Field class. It is set to the appropriate bit pattern for the modifiers of the field represented by that particular field instance.Leukorrhea
Great for having a program changing its own environment (or, at least, the return value of System.getenv()). Why the environment is immutable is a question I am not wise enough to know the answer to.Ideational
Note that JLS §17.5.3 is referring to non-static final fields. Subsequent modification of static final fields is not foreseen at all and hence, entirely off specification. Anything can happen, including no effect at all or a complete crash of the JVM…Printmaking
Another caveat is that you can't read the Field before removing the modifier or it gets cached: https://mcmap.net/q/24714/-why-i-can-t-use-method-get-java-lang-reflect-field-get-before-changing-field-s-modifiers/1553851Annulation
Doesnt make sense why u got 2 fieldsSalford
In Java 12 this is no longer allowed. See bug 8210496 bugs.java.com/bugdatabase/view_bug.do?bug_id=8210496 hg.openjdk.java.net/jdk-updates/jdk12u/rev/f55a4bc91ef4Everglades
Does this works for the final static field of a static class ? I try but looks like the field of the static class was not changed as expected.Already
Evil and working, thank you >:-D Unfortunately does not work on Java 13.Dramaturge
This worked for setting a static final logger to a mocked logger in a test. Thank you!Iene
Mind (again) that “JLS 17.5.3 Subsequent Modification of Final Fields” applies to instance fields only. It describes the problems which may happen when you “change the final fields of an object after construction” whereas changing a static final field after the class initialization is not even foreseen by the specification. That’s why for a non-static final field a simple setAccessible(true) is enough to change it whereas changing a static final field requires deeper hacks which the JDK developers try to disable. Even if you find another work-around, it’ll break the next version.Printmaking
As mentioned in Ans"Final field is initialized to a compile-time constant in the field declaration, changes to the final field may not be observed" -any way to work on this when the fields is inbuilt @PrintmakingLibya
@Everglades Yep, not working in Java 12 anymore, check this answer for the new trickSomething
java.lang.NoSuchFieldException: modifiersRas
I am using this solution in my testing and I want to tear down the changes done to the variable. How can I revert (put back final modifier back) setFinalStatic method changes once the testing is done ?Ameba
So if I wanted to make the field final again, would I just omit the tilde ~?Latish
I wonder how this could work on JDK 17. I think modifiers is not accessible anymore.Roberto
not working on 17Subcartilaginous
It doesn't work with java 17 :)Smyrna
T
69

If the value assigned to a static final boolean field is known at compile-time, it is a constant. Fields of primitive or String type can be compile-time constants. A constant will be inlined in any code that references the field. Since the field is not actually read at runtime, changing it then will have no effect.

The Java language specification says this:

If a field is a constant variable (§4.12.4), then deleting the keyword final or changing its value will not break compatibility with pre-existing binaries by causing them not to run, but they will not see any new value for the usage of the field unless they are recompiled. This is true even if the usage itself is not a compile-time constant expression (§15.28)

Here's an example:

class Flag {
  static final boolean FLAG = true;
}

class Checker {
  public static void main(String... argv) {
    System.out.println(Flag.FLAG);
  }
}

If you decompile Checker, you'll see that instead of referencing Flag.FLAG, the code simply pushes a value of 1 (true) onto the stack (instruction #3).

0:   getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3:   iconst_1
4:   invokevirtual   #3; //Method java/io/PrintStream.println:(Z)V
7:   return
Telescopium answered 21/7, 2010 at 16:57 Comment(4)
That was my first thought, but then I remembered Java compiled at runtime, if you were to reset the bit it would simply recompile with it as a variable instead of a constant.Butterflies
@Bill K - No, this doesn't refer to JIT compilation. The dependent class files will actually contain the inlined values, and no reference to the independent class. It's a pretty simple experiment to test; I will add an example.Telescopium
How does this jive with @Ivanivana 's answer where he redefines Boolean.false?--but you are correct, I've seen this behavior when things didn't recompile correctly.Butterflies
@Bill K - in polygenlubricants' answer, the field is not a compile time constant. It's public static final Boolean FALSE = new Boolean(false) not public static final boolean FALSE = falseTelescopium
D
20

A little curiosity from the Java Language Specification, chapter 17, section 17.5.4 "Write-protected Fields":

Normally, a field that is final and static may not be modified. However, System.in, System.out, and System.err are static final fields that, for legacy reasons, must be allowed to be changed by the methods System.setIn, System.setOut, and System.setErr. We refer to these fields as being write-protected to distinguish them from ordinary final fields.

Source: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.4

Dierdre answered 21/11, 2012 at 19:21 Comment(0)
O
10

I also integrated it with joor library

Just use

      Reflect.on(yourObject).set("finalFieldName", finalFieldValue);

Also I fixed an issue with override which the previous solutions seem to miss. However use this very carefully, only when there's no other good solution.

Osterhus answered 7/7, 2015 at 12:47 Comment(2)
When I try this (JDK12), I get an exception: "Can not set final ___ field".Fourway
@AaronIba It's no longer allowed in Java 12+.Angadreme
C
8

Along with top ranked answer you may use a bit simpliest approach. Apache commons FieldUtils class already has particular method that can do the stuff. Please, take a look at FieldUtils.removeFinalModifier method. You should specify target field instance and accessibility forcing flag (if you play with non-public fields). More info you can find here.

Criss answered 7/6, 2017 at 10:32 Comment(3)
This is a much simpler solution than the currently accepted answerJovita
Is it? Copying one method sounds like a simpler solution than importing an entire library (which is doing the same thing as the method you'd be copying).Gorge
Does not work in Java 12+: java.lang.UnsupportedOperationException: In java 12+ final cannot be removed.Ellery
C
7

Even in spite of being final a field can be modified outside of static initializer and (at least JVM HotSpot) will execute the bytecode perfectly fine.

The problem is that Java compiler does not allow this, but this can be easily bypassed using objectweb.asm. Here is p̶e̶r̶f̶e̶c̶t̶l̶y̶ ̶v̶a̶l̶i̶d̶ ̶c̶l̶a̶s̶s̶f̶i̶l̶e̶ an invalid classfile from the JVMS specification standpoint, but it passes bytecode verification and then is successfully loaded and initialized under JVM HotSpot OpenJDK12:

ClassWriter cw = new ClassWriter(0);
cw.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Cl", null, "java/lang/Object", null);
{
    FieldVisitor fv = cw.visitField(Opcodes.ACC_PRIVATE | Opcodes.ACC_STATIC | Opcodes.ACC_FINAL, "fld", "I", null, null);
    fv.visitEnd();
}
{
    // public void setFinalField1() { //... }
    MethodVisitor mv = cw.visitMethod(Opcodes.ACC_PUBLIC | Opcodes.ACC_STATIC, "setFinalField1", "()V", null, null);
    mv.visitMaxs(2, 1);
    mv.visitInsn(Opcodes.ICONST_5);
    mv.visitFieldInsn(Opcodes.PUTSTATIC, "Cl", "fld", "I");
    mv.visitInsn(Opcodes.RETURN);
    mv.visitEnd();
}
{
    // public void setFinalField2() { //... }
    MethodVisitor mv = cw.visitMethod(Opcodes.ACC_PUBLIC | Opcodes.ACC_STATIC, "setFinalField2", "()V", null, null);
    mv.visitMaxs(2, 1);
    mv.visitInsn(Opcodes.ICONST_2);
    mv.visitFieldInsn(Opcodes.PUTSTATIC, "Cl", "fld", "I");
    mv.visitInsn(Opcodes.RETURN);
    mv.visitEnd();
}
cw.visitEnd();

In Java, the class looks roughly speaking as follows:

public class Cl{
    private static final int fld;

    public static void setFinalField1(){
        fld = 5;
    }

    public static void setFinalField2(){
        fld = 2;
    }
}

which cannot be compiled with javac, but can be loaded and executed by JVM.

JVM HotSpot has special treatment of such classes in the sense that it prevents such "constants" from participating in constant folding. This check is done on the bytecode rewriting phase of class initialization:

// Check if any final field of the class given as parameter is modified
// outside of initializer methods of the class. Fields that are modified
// are marked with a flag. For marked fields, the compilers do not perform
// constant folding (as the field can be changed after initialization).
//
// The check is performed after verification and only if verification has
// succeeded. Therefore, the class is guaranteed to be well-formed.
InstanceKlass* klass = method->method_holder();
u2 bc_index = Bytes::get_Java_u2(bcp + prefix_length + 1);
constantPoolHandle cp(method->constants());
Symbol* ref_class_name = cp->klass_name_at(cp->klass_ref_index_at(bc_index));
if (klass->name() == ref_class_name) {
   Symbol* field_name = cp->name_ref_at(bc_index);
   Symbol* field_sig = cp->signature_ref_at(bc_index);

   fieldDescriptor fd;
   if (klass->find_field(field_name, field_sig, &fd) != NULL) {
      if (fd.access_flags().is_final()) {
         if (fd.access_flags().is_static()) {
            if (!method->is_static_initializer()) {
               fd.set_has_initialized_final_update(true);
            }
          } else {
            if (!method->is_object_initializer()) {
              fd.set_has_initialized_final_update(true);
            }
          }
        }
      }
    }
}

The only restriction that JVM HotSpot checks is that the final field should not be modified outside of the class that the final field is declared at.

Cilurzo answered 18/8, 2019 at 21:2 Comment(3)
this is just pure EVIL and beautiful.Meldon
I don’t agree with the “perfectly valid classfile”. The JVMS §6.5 clearly says: “Otherwise, if the resolved field is final, it must be declared in the current class or interface, and the instruction must occur in the class or interface initialization method of the current class or interface. Otherwise, an IllegalAccessError is thrown”. So this is just another case where the implementation blatantly violates the specification and has code spread over multiple places to handle what should have been rejectedPrintmaking
@Printmaking Thanks for the note. I made a correction according to your note to not confuse further readers.Cilurzo
C
6

In case of presence of a Security Manager, one can make use of AccessController.doPrivileged

Taking the same example from accepted answer above:

import java.lang.reflect.*;

public class EverythingIsTrue {
    static void setFinalStatic(Field field, Object newValue) throws Exception {
        field.setAccessible(true);
        Field modifiersField = Field.class.getDeclaredField("modifiers");

        // wrapping setAccessible 
        AccessController.doPrivileged(new PrivilegedAction() {
            @Override
            public Object run() {
                modifiersField.setAccessible(true);
                return null;
            }
        });

        modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
        field.set(null, newValue);
    }

    public static void main(String args[]) throws Exception {      
      setFinalStatic(Boolean.class.getField("FALSE"), true);
      System.out.format("Everything is %s", false); // "Everything is true"
    }
}

In lambda expression, AccessController.doPrivileged, can be simplified to:

AccessController.doPrivileged((PrivilegedAction) () -> {
    modifiersField.setAccessible(true);
    return null;
});
Chatterbox answered 25/3, 2017 at 6:6 Comment(1)
yes @dan1st, you are right! Please check this for a solution: https://mcmap.net/q/24710/-get-declared-fields-of-java-lang-reflect-fields-in-jdk12Chatterbox
P
5

Since Java 12 onwards, the answers given will not work.

Here is an example on how to modify a private static final field since Java 12 (based on this answer).

  private Object modifyField(Object newFieldValue, String fieldName, Object classInstance) throws NoSuchFieldException, IllegalAccessException {
    Field field = classInstance.getClass().getDeclaredField(fieldName);
    VarHandle MODIFIERS;

    field.setAccessible(true);

    var lookup = MethodHandles.privateLookupIn(Field.class, MethodHandles.lookup());
    MODIFIERS = lookup.findVarHandle(Field.class, "modifiers", int.class);
    int mods = field.getModifiers();

    if (Modifier.isFinal(mods)) {
      MODIFIERS.set(field, mods & ~Modifier.FINAL);
    }

    Object previousValue = field.get(classInstance);
    field.set(null, newFieldValue);

    return previousValue;
  }

See this thread for more details.

Polypody answered 28/9, 2021 at 12:54 Comment(9)
This does not work with Java 16+.Jeremiahjeremias
@JohannesKuhn works if you add --illegal-access=permitDemeter
--illegal-access=permit was removed in Java 17.Jeremiahjeremias
There is no way to make this work with Java 18 due to JEP 416Jeremiahjeremias
Even in Java 18, JLS 17.5.3 still says "final fields can be changed via reflection and other implementation-dependent means". So what is the reflection mechanism to satisfy the JLS?Egret
I managed to use lookup.findSetter(Field.class, "modifiers", int.class) successfully on both Java 16 and Java 17. However, it still fails on Java 18 because Field.modifiers has suddenly become a final field.Egret
@ChrisRankin The mechanism for non-static final fields is reflection with setAccessible.Jeremiahjeremias
OK, and what is the mechanism for static final fields? Because that's the case I'm actually interested in. Specifically - non-primitive static final fields, i.e. object references.Egret
You can't change static final fields. That never really worked. It may appear to work, but in the end - relying on that effect makes your code just non-portable.Jeremiahjeremias
C
4

With JDK 18 this won't be possible anymore due to the reimplementation of the core reflection over invokedynamic and MethodHandles as part of JEP-416 (PR).

Quote of Mandy Chung – who is the main author of this incredible work – in the following comment. Emphasis are mine.

If the underlying field is final, a Field object has write access if and only if

  • setAccessible(true) has succeeded for this Field object;
  • the field is non-static; and
  • the field's declaring class is not a hidden class; and
  • the field's declaring class is not a record class.
Centipede answered 30/11, 2021 at 9:56 Comment(0)
A
3

Many of the answers here are useful, but I've found none of them to work on Android, in particular. I'm even a pretty hefty user of Reflect by joor, and neither it nor apache's FieldUtils - both mentioned here in some of the answers, do the trick.

Problem with Android

The fundamental reason why this is so is because on Android there's no modifiers field in the Field class, which renders any suggestion involving this code (as in the marked answer), useless:

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

In fact, to quote from FieldUtils.removeFinalModifier():

// Do all JREs implement Field with a private ivar called "modifiers"?
final Field modifiersField = Field.class.getDeclaredField("modifiers");

So, the answer is no...

Solution

Pretty easy - instead of modifiers, the field name is accessFlags. This does the trick:

Field accessFlagsField = Field.class.getDeclaredField("accessFlags");
accessFlagsField.setAccessible(true);
accessFlagsField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

Side-note #1: this can work regardless of whether the field is static in the class, or not.

Side-note #2: Seeing that the field itself could be private, it's recommended to also enable access over the field itself, using field.setAccessible(true) (in addition to accessFlagsField.setAccessible(true).

Ariana answered 15/10, 2020 at 19:1 Comment(1)
When running the original code in Android, you will get the following error: java.lang.NoSuchFieldException: No field modifiers in class Ljava/lang/reflect/Field; (declaration of 'java.lang.reflect.Field' appears in /apex/com.android.runtime/javalib/core-oj.jar). The suggested solution works in my case. (This error currently has only one google result, so hopefully people will now find this page)Siliceous
I
2

Just saw that question on one of the interview question, if possible to change final variable with reflection or in runtime. Got really interested, so that what I became with:

 /**
 * @author Dmitrijs Lobanovskis
 * @since 03/03/2016.
 */
public class SomeClass {

    private final String str;

    SomeClass(){
        this.str = "This is the string that never changes!";
    }

    public String getStr() {
        return str;
    }

    @Override
    public String toString() {
        return "Class name: " + getClass() + " Value: " + getStr();
    }
}

Some simple class with final String variable. So in the main class import java.lang.reflect.Field;

/**
 * @author Dmitrijs Lobanovskis
 * @since 03/03/2016.
 */
public class Main {


    public static void main(String[] args) throws Exception{

        SomeClass someClass = new SomeClass();
        System.out.println(someClass);

        Field field = someClass.getClass().getDeclaredField("str");
        field.setAccessible(true);

        field.set(someClass, "There you are");

        System.out.println(someClass);
    }
}

The output will be as follows:

Class name: class SomeClass Value: This is the string that never changes!
Class name: class SomeClass Value: There you are

Process finished with exit code 0

According to documentation https://docs.oracle.com/javase/tutorial/reflect/member/fieldValues.html

Irrelievable answered 4/3, 2016 at 9:21 Comment(2)
Have you seen this post?Carver
This question asks about a static final field, so this code doesn't work. setAccessible(true) only works for setting final instance fields.Wivern
V
2

The accepted answer worked for me until deployed on JDK 1.8u91. Then I realized it failed at field.set(null, newValue); line when I had read the value via reflection before calling of setFinalStatic method.

Probably the read caused somehow different setup of Java reflection internals (namely sun.reflect.UnsafeQualifiedStaticObjectFieldAccessorImpl in failing case instead of sun.reflect.UnsafeStaticObjectFieldAccessorImpl in success case) but I didn't elaborate it further.

Since I needed to temporarily set new value based on old value and later set old value back, I changed signature little bit to provide computation function externally and also return old value:

public static <T> T assignFinalField(Object object, Class<?> clazz, String fieldName, UnaryOperator<T> newValueFunction) {
    Field f = null, ff = null;
    try {
        f = clazz.getDeclaredField(fieldName);
        final int oldM = f.getModifiers();
        final int newM = oldM & ~Modifier.FINAL;
        ff = Field.class.getDeclaredField("modifiers");
        ff.setAccessible(true);
        ff.setInt(f,newM);
        f.setAccessible(true);

        T result = (T)f.get(object);
        T newValue = newValueFunction.apply(result);

        f.set(object,newValue);
        ff.setInt(f,oldM);

        return result;
    } ...

However for general case this would not be sufficient.

Volar answered 10/5, 2017 at 12:45 Comment(0)
M
2

To make this worked with JDK 21 you can use option -Djdk.reflect.useDirectMethodHandle=false

Make accessable for JDK 11 - 17

    public static void setFieldAccessible(Field field) throws Exception {
    field.setAccessible(true);
    Method getDeclaredFields0 = Class.class.getDeclaredMethod("getDeclaredFields0", boolean.class);
    getDeclaredFields0.setAccessible(true);
    Field[] fields = (Field[]) getDeclaredFields0.invoke(Field.class, false);
    for (Field each : fields) {
        if ("modifiers".equals(each.getName())) {
            each.setAccessible(true);
            each.setInt(field, field.getModifiers() & ~Modifier.FINAL);
            break;
        }
    }
}
Melburn answered 27/9, 2023 at 11:3 Comment(2)
Enjoy while we can on Java 21 because bugs.openjdk.org/browse/JDK-8309635 removes it for Java 22Nette
Code works in Java 21. It's sad that stop works in 22 :( For complete support I need to pass the following VM options -Djdk.reflect.useDirectMethodHandle=false --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMEDAldaaldan
S
0

If your field is simply private you can do this:

MyClass myClass= new MyClass();
Field aField= myClass.getClass().getDeclaredField("someField");
aField.setAccessible(true);
aField.set(myClass, "newValueForAString");

and throw/handle NoSuchFieldException

Salford answered 23/1, 2019 at 16:34 Comment(0)
S
-2

The top rated answer does not work with the new Reflection implementation of JEP416 in e.g. Java 21 that uses MethodHandles and ignores the flags value on the Field abstraction object.

One solution is to use Unsafe, however with this JEP Unsafe and the important long objectFieldOffset(Field f) and long staticFieldOffset(Field f) methods are getting deprecated for removal so for example this will not work in the future:

final Unsafe unsafe = //..get Unsafe (...and add subsequent --add-opens statements for this to work)
final Field ourField = Example.class.getDeclaredField("changeThis");
final Object staticFieldBase = unsafe.staticFieldBase(ourField);
final long staticFieldOffset = unsafe.staticFieldOffset(ourField);
unsafe.putObject(staticFieldBase, staticFieldOffset, "it works");

I do not recommend this but it is possible in Java 21 with the new reflection implementation when making heavy use of the internal API if really needed.

Java 21+ solution without Unsafe

The gist of it is to use a MethodHandle that can write to a static final field by getting it from the internal getDirectFieldCommon(...) method of the Lookup by providing it with a ReferenceKind that is manipulated via Reflection to remove the Final flag from it.

MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(MyClassWithStaticFinalField.class, MethodHandles.lookup());

Method getDirectFieldCommonMethod = lookup.getClass().getDeclaredMethod("getDirectFieldCommon", byte.class, Class.class, memberNameClass, boolean.class);
        
getDirectFieldCommonMethod.setAccessible(true);
        
//Invoke last method to obtain the method handle
MethodHandle finalFieldHandle = (MethodHandle) getDirectFieldCommonMethod.invoke(lookup, manipulatedReferenceKind, myStaticFinalField.getDeclaringClass(), memberNameInstanceForField, false);
        
finalFieldHandle.invoke("new Value for static final field");

See my answer here for a full working example on how to leverage the internal API to set a final field in Java 21 without Unsafe.

Surpass answered 30/3 at 22:27 Comment(2)
You need to quote enough of your other answer to make this answer self-contained. Otherwise this isn’t an answer.Helbonia
@Helbonia edited to add the quoteSurpass
B
-5

The whole point of a final field is that it cannot be reassigned once set. The JVM uses this guarentee to maintain consistency in various places (eg inner classes referencing outer variables). So no. Being able to do so would break the JVM!

The solution is not to declare it final in the first place.

Buckboard answered 21/7, 2010 at 16:38 Comment(12)
Moreover, final has a special role in multithreaded execution - changing final values would break the Java memory model too.Biron
And a field not declared final should not be declared static.Phototopography
@Tom: In general that's probably true, but I wouldn't outlaw all static mutable variables.Ostraw
@Ostraw It's almost always wrong. You might get away with it for a cache (or you might not).Phototopography
@Tom what about a Singleton using a getInstance() method that assigns the instance to a static field? You'll also need to reassign a mutable static field when it's a WeakReference<T> and the original reference target has disappeared.Buckboard
@Buckboard It is well known that singletons (a.k.a. globaltons) are evil.Phototopography
@Tom: Did you ever read up why singletons are evil? I did! Now I know that they evil only in Java. And only because of the availabilty of a user defined class loader. And ever since I know all this and I don´t use user defined class loader I use singletons without regret. And so does Scala where singleton are a first class language feature — That singletons are evil is is a well known false myth.Pancreas
@Tom: I have 20 years of experience in Software development. I learned a dozen and more programming languages. I researched the details about Singletons in Java. So what make you think your are right?Pancreas
The final modifier is not intended to protect a field from change. It just indicates, that the programmer of the class doesn't recommend changing this field. Same with accessors. They are only intended to show a user of a class what methods/fields are safe to use.Dinar
@Vincent, isn't it contradict to the @Péter Török's comment?Dorado
@Pancreas I know that your comment is old, and perhaps your views have changed by now, but I thought I'd just add this: Singletons are evil for reasons that have nothing to do with Java. They add hidden complexity to your code. Additionally, they can make it impossible to unit test without also knowing that n singletons must also be configured first. They are the antithesis of dependency injection. Your team might make the decision that the pitfalls of having hidden complexity don't outweigh the convenience of Singletons, but many teams take the opposite stance for good reason.Bluma
No, it does not break the JVM. JVM allows static final fields to be modified by methods of the same class.Cilurzo

© 2022 - 2024 — McMap. All rights reserved.