1

Let's say I have a 

class Foo(){
    public final static int bar = -1;
}

disassembled bytecode will look something like this

super public class Foo
    version 51:0
{

public static final Field bar:I = int -1;

public Method "<init>":"()V"
    stack 1 locals 1
{
        aload_0;
        invokespecial   Method java/lang/Object."<init>":"()V";
        return;

}

} // end Class Foo

And yes, this surprised me. I would have expected there to be a <clinit> method containing an assignment to bar that I could then replace. (Which is indeed what happens when I remove the final modifier.)

How do I change the value for a final field? What do I hook into?

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
User1291
  • 7,664
  • 8
  • 51
  • 108
  • 1
    do you know what 'final' does? unless the final variable is a mutable type, you can't just "change" the value. – Stultuske Feb 13 '18 at 13:45
  • 1
    @Stultuske: Looking at the tags, I think the OP is trying to do this post-compilation. @ User1291 - It would help a lot if you provided more details around what you're actually trying to do. – T.J. Crowder Feb 13 '18 at 13:46
  • The -1 will be in Foo's constant table, which you can see via `javap -c -v Foo`. The class file format being public and well-documented, you can probably find it there and manipulate it (it's at offset 0x30 in my `Foo.class`, but obviously that will vary depending on the other contents of `Foo`; for instance, just a minor change to `Foo` moved it to offset 0x18). – T.J. Crowder Feb 13 '18 at 13:49
  • @T.J.Crowder Well, this IS basically exactly what I'm trying to do. I have some classes that get instrumented and some IDs that get distributed in the process and I then need the amount of IDs distributed available when I run the instrumented classes to create an array. So why not create a dedicated class holding all constants that I do not know until I've actually done the instrumentation and instrument *that* class? – User1291 Feb 13 '18 at 13:51
  • @User1291: Well, then you'll want to [read this](https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html) (for the version of Java you need to do this with, the class file format has changed a coule of times) and work from there. – T.J. Crowder Feb 13 '18 at 13:53

1 Answers1

6

Your expectation is incorrect. A static final int which is initialized with an integer literal will be a compile-time constant. Compile-time constants get inlined by the bytecode compiler.

It will not be possible to change the value at runtime, or using bytecode modification. The inlining that the bytecode compiler did can't be unwound. Recompilation of the class and its dependent classes is the only tractable way to change the value of a compile-time constant.

Note this is not just an inconvenient artifact of the Java compiler implementation. This handling of compile-time constants is mandated by the JLS. For example, JLS 17.5.3 says this about trying to change a compile-time constant final using reflection:

"If a final field is initialized to a constant expression (§15.28) 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 value of the constant expression."

In other words, a reflective API call to change Foo.bar may appear to succeed, but the actual value that has been inlined doesn't change. In fact, the only code that is likely to see the updated value is code that reads Foo.bar using reflection!

One possible workaround would be to declare the constant in a way that makes it not a compile-time constant. For example:

class Foo() {
    public final static int bar = Integer.parseInt("-1");
}
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • @ User1291: For instance, when I created a `Bar` which simply output `Foo.bar` from main, the -1 was pushed on the stack via [`iconst_m1`](https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.iconst_i), since -1 happens to be so frequently used that "push -1 on the stack" is a bytecode of its own. Recompiling `Foo` with a different value had no effect on `Bar`'s output at all. Recompiling `Bar` at that point with a value without a dedicated bytecode revealed the value in `Bar`'s constant table. – T.J. Crowder Feb 13 '18 at 14:13
  • The workaround seems to work. Prevents inlining and provides a ```` (containing a call to ``Integer.parseInt`` + ``putstatic``) that can be replaced. Of course we're then providing an inlineable value that won't be inlined, but I doubt anybody will hang me for it. Thank you. – User1291 Feb 13 '18 at 14:28
  • 1
    But, of course, it doesn’t have to be an operation as expensive as `Integer.parseInt("-1")`. You will be fine with `Integer.hashCode(-1)`. If you don’t mind having a bit more complex source code, the most efficient variant is `public final static int bar; static { bar = -1; }`, just using an explicit initializer that merely consist of the assignment of the desired value… – Holger Feb 13 '18 at 16:20
  • You CAN change the final values with the Reflection API. – Saclyr Barlonium Feb 13 '18 at 18:32
  • 1
    Not if it is a compile time constant, you can't! – Stephen C Feb 13 '18 at 22:48
  • @Holger ``hashCode`` is non-static (and also takes no arguments). And the explicit initialiser is interesting because I thought I had already tried that. Guess I mis-remembered or forgot to re-disassemble, I don't know. Either way, thank you. As the initialisation is replaced anyway, though, efficiency doesn't matter in *this* case. I'm therefore leaning towards the ``= Integer.parse("-1")``, simply because it's copy-pasteable whereas a static initialiser, you'd have to adjust after copying. – User1291 Feb 14 '18 at 08:33
  • @User1291 [`Integer.hashCode(int)`](https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#hashCode-int-). If you ever consider what happens behind the scenes for parsing a string into a number, you’d never consider `Integer.parse("-1")`. – Holger Feb 14 '18 at 08:38
  • @Holger Ah, sorry, my bad. The project I'm working on requires Java 7 so that's the API I checked. But yes, I have no trouble believing you that ``parse`` is incredibly inefficient. My point was that since it's never going to be executed anyway (unless you forget to rewrite the intialisation, which would be a bug), we can get away with not caring (again, in *this* case). – User1291 Feb 14 '18 at 08:46
  • 1
    @User1291 I see, so the code is supposed to *always* be rewritten. In that case, I’d add a dummy method like `static native int initialValue();` and use `final static int bar = initialValue();`, which will fail immediately, if the code transformation has been forgotten. Removing the dummy method during the instrumentation should be easy… – Holger Feb 14 '18 at 08:51
  • @Holger Interesting. You don't even *have* to remove the dummy method. I'd have expected this to throw an ``UnsatisfiedLinkError``, but apparently, Java doesn't care if it never needs to actually call the method. Thank you. – User1291 Feb 14 '18 at 09:13
  • 1
    @User1291 since you are free to decide when to do the linking, as long as it is done before invoking the method, the only place where an `UnsatisfiedLinkError` can be thrown, is when you actually invoke the method (and haven’t linked it). So yes, you don’t need to remove the method, but it might be a good style to do it, as it isn’t very hard. – Holger Feb 14 '18 at 09:19
  • Note that `parseInteger` was not intended to be practical. Any method call that returns an `int` will be sufficient to cause the expression to not be a compile-time constant expression. And a few other things as well. And, as Holger points out, the method doesn't need to work if you never call it. – Stephen C Feb 14 '18 at 09:45