On Tue, May 19, 2020 at 12:42 PM Clément Poulain <[email protected]> wrote: > > I think the answer can be found in this post, in "Remember Constant > Expressions" section: > https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection/3301720#3301720 > > It links to: > https://stackoverflow.com/questions/17506329/java-final-field-compile-time-constant-expression > and: https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.3 > > " If a final field is initialized to a compile-time 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."
That makes sense wrt symptoms here. Thank you for the link, can refer others to that. In this particular case, then, it's the actual initializer that causes it then, I think. Too bad there is no straight-forward way to figure out this case via Reflection, to filter out such "true" constant cases (vs cases where initalization is from constructor). But at least it is good to know what triggers this. -+ Tatu +- > > On Tuesday, May 19, 2020 at 9:28:59 PM UTC+2, Tatu Saloranta wrote: >> >> On Tue, May 19, 2020 at 12:21 PM Tatu Saloranta <[email protected]> wrote: >> > >> > On Tue, May 19, 2020 at 7:52 AM Clément Poulain <[email protected]> wrote: >> > > >> > > I have edited the gist to simplify it by using an simple Integer field >> > > instead of my own bucket object. >> > > >> > > The corresponding output is now: >> > > >> > > 1. {"myInt":42,"myInteger":42} >> > > 2. myInt: 42, myInteger: 100 >> > > 3. {"myInt":100,"myInteger":100} >> > >> > Interesting. I'll run to see what I can see on my end but in the >> > meantime, I'll mention that there is >> >> I see the same results as you, and they seem to be stable too (and not >> due to just temporary invisibility of changes). >> Perhaps this is due to some optimization of direct access, wherein >> what is declared as a constant is assumed to be >> so (although I thought that would only be done for `static final` >> members?); whereas access through Reflection >> will find actual modified value. >> >> -+ Tatu +- >> >> > >> > MapperFeature.ALLOW_FINAL_FIELDS_AS_MUTATORS >> > >> > which defaults to enabled; but disabling of which will prevent use of >> > final fields. >> > Use of final fields was originally an oversight (no check was done to >> > see if a visible field is final or not), >> > and its functioning really depends on how JVM handles it -- my >> > understanding is that it's sort of a quirk to >> > allow JDK's own Serialization mechanism (java.io.Serializable) >> > deserialization otherwise immutable objects, >> > and that there is some window of opportunity during which such changes >> > are allowed. And probably there is >> > also question of visibility of changes, such that in your case changes >> > are not immediately visible for some >> > reason. >> > >> > But I doubt there is much Jackson can do to change what you observe, >> > which is why disabling above-mentioned >> > MapperFeature probably makes sense (and only pass values to final >> > fields via `@JsonCreator`) >> > >> > -+ Tatu +- >> > >> > > >> > > On Tuesday, May 19, 2020 at 4:20:55 PM UTC+2, Clément Poulain wrote: >> > >> >> > >> Hi there, >> > >> >> > >> I'm experience a strange behavior when working with Jackson (v2.11.0) >> > >> when working with final fields. >> > >> I have a POJO with some final fields, which I want to NOT be modifiable >> > >> during deserialization. It seems to be working as expected for >> > >> primitive type, but not for objects. >> > >> >> > >> I have created this gist to demonstrate the issue: >> > >> https://gist.github.com/Plonk42/82409983a684b44df6a564acc43a7d75 >> > >> >> > >> The output of this gist is: >> > >> >> > >> 1. {"myField":42,"bucket":{"bucketField":42}} >> > >> 2. myField: 42, bucketField:100 >> > >> 3. {"myField":100,"bucket":{"bucketField":100}} >> > >> >> > >> On line 1., the output is what we expect (both fields set to 42). >> > >> Then I'm de-serializing a JSON payload representing a POJO, and we see >> > >> the first strange thing: "myField" is not modified (still 42) but >> > >> "bucketField" is modified (now 100). >> > >> Then serializing again the resulting POJO, it gets even stranger: now >> > >> both fields are set to 100. >> > >> >> > >> Am I missing something?? >> > >> >> > >> Thanks, >> > >> Clément >> > > >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "jackson-user" group. >> > > To unsubscribe from this group and stop receiving emails from it, send >> > > an email to [email protected]. >> > > To view this discussion on the web visit >> > > https://groups.google.com/d/msgid/jackson-user/e183668f-4309-42a9-ad06-ca54848a40e2%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/056deaa2-8837-4c3c-a751-9725c8b50fc4%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAL4a10gjOmipzyjbzUbvoTgKObcH%2BG9mqUMLv09-tY%2B6rQNrUQ%40mail.gmail.com.
