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/CAL4a10j9%2Bvmq2UNvpcNW_wVwxtsCQG2U%3DGgoAXCvKZBSCJ75Ug%40mail.gmail.com.

Reply via email to