Protect Final Variables from reflection

Question

I want to design a class to demonstrate immutability, incrementally.

Following is a simple class

public class ImmutableWithoutMutator {
    private final String firstName;
    private final String lastName;
    private final int age;

    public ImmutableWithoutMutator(final String firstName, final String lastName, final int age) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.age = age;
    }

    @Override
    public String toString() {
        return String.format(
                "ImmutableWithoutMutator [age=%s, firstName=%s, lastName=%s]",
                age, firstName, lastName);
    }
}

Now I can still breach in using reflection, by using the following code.

import java.lang.reflect.Field;

public class BreakImmutableUsingReflection {
    public static void main(String[] args) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
        ImmutableWithoutMutator immMutator = new ImmutableWithoutMutator(
                "firstName", "lastName", 2400);
        System.out.println(immMutator);

        // now lets try changing value using reflection
        Field f = ImmutableWithoutMutator.class.getDeclaredField("age");
        f.setAccessible(true);
        f.set(immMutator, 2000);

        System.out.println(immMutator);
    }
}

My question is, I have not modified the Modifiers for the fields using reflection API. Then how the code is still able to mutate final fields?

Possible duplicate of http://stackoverflow.com/questions/1615163/modifying-final-fields-in-java?rq=1 — Patashu, Apr 12 '13 at 06:00

score 10 · Accepted Answer · answered Apr 12 '13 at 05:59

This is expected behaviour - it's just something you shouldn't do.

From the documentation for Field.set:

If the underlying field is final, the method throws an IllegalAccessException unless setAccessible(true) has succeeded for this Field object and the field is non-static. Setting a final field in this way is meaningful only during deserialization or reconstruction of instances of classes with blank final fields, before they are made available for access by other parts of a program. Use in any other context may have unpredictable effects, including cases in which other parts of a program continue to use the original value of this field.

Now if you then want to argue this breaches all kinds of security, you need to ask yourself why you've got code you don't trust to be sane running with sufficient permission to call field.setAccessible(true). Basically, protection is given by the security manager - but if you're running without a security manager which stops you from doing this, you can shoot yourself in the foot.

`if(author.getName().equals("Jon Skeet")) { this.upvote (); } else { this.readAnswer (); }` — Radu Murzea, Apr 12 '13 at 06:02

score 1 · Answer 2 · answered Apr 12 '13 at 06:07

1

No, you can do that. I suggest to read The Security Manager and the Java SE 7 Security Documentation if you want to restrict certain operations.

answered Apr 12 '13 at 06:07

dierre

7,140
12
75
120

2

ok I didn't see Jon Skeet's answer before posting. I'm going to hell now. – dierre Apr 12 '13 at 06:08

score 1 · Answer 3 · edited May 23 '17 at 11:49

1

You can protect from setAccessible using the SecurityManager. You can either specify it on the command line or create it dynamically, like they do it here.

But even if you protect from reflection your code would still be not protected against bytecode modification libraries like ASM.

So you shouldn't rely on your fields being final.

edited May 23 '17 at 11:49

Community

1
1

answered Apr 12 '13 at 06:27

Oleg Mikheev

17,186
14
73
95

please copy the solution from the source. – Jafar Ali Jan 02 '23 at 09:46

Protect Final Variables from reflection

3 Answers3