@JsonUnwrapped annotation is ignored when a field is an Optional

[akobiakov]

Consider the example:

public class Test {
    public static void main(String[] args) throws JsonProcessingException {
        System.out.println(new ObjectMapper()
                .registerModule(new GuavaModule())
                .writeValueAsString(new Parent()));
    }
}

class Child {
    @JsonProperty
    private String text = "hello, world!";
}

class Parent {
    @JsonProperty
    @JsonUnwrapped
    private Child child = new Child();
}

Produces: {"text":"hello, world!"}

Whereas the following example:

public class Test {
    public static void main(String[] args) throws JsonProcessingException {
        System.out.println(new ObjectMapper()
                .registerModule(new GuavaModule())
                .writeValueAsString(new Parent()));
    }
}

class Child {
    @JsonProperty
    private String text = "hello, world!";
}

class Parent {
    @JsonProperty
    @JsonUnwrapped
    private Optional<Child> child = Optional.of(new Child());
}

(note, that the child field is now Optional)

Produces: {"child":{"text":"hello, world!"}}

Such a behaviour looks a bit odd and counterintuitive. In my opinion, the output should be the same as in the first case.

[cowtowncoder]

Yeah, I hate Optionals in all its forms. I wish people did not use it, because the whole framework now has to be made aware of this extra-linguistic feature.

If this can be supported, great, but until then the work-around is to not use Optional for types that require any of advanced features, such as unwrapping, polymorphic type handling, or even inclusion changes.

[cowtowncoder]

Will investigate to see if there might be an easy fix here.

[cowtowncoder]

Ok, there are couple of few issues here. First one is that the way Guava Optional serializer overwrites BeanPropertyWriter, which in turn prevents unwrapped handling from taking effect.
But even if this is removed, core databind has an assumption that serializer/BeanPropertyWriter need to be of specific type, to be able to support name mangling.

It should be possible to work through these issues. First one needs to be tackled for other reasons (changes to how inclusion of Guava Optionals is determined wrt null, absent).
The second issue should ideally be tackled afterwards.
But both can be done at earliest for 2.6.0, so it may be a while.

[cowtowncoder]

FWIW, handling of Optionals has been changed and should be cleaner, regarding inclusion.
Guava module may or may not replace BeanPropertyWriter, depending on backwards-compatibility setting.

[cowtowncoder]

Ok; this works now, as long as module does NOT use the backwards-compatible "treat Optionals as nulls" mode. This is configured via GuavaModule.
Why the old mode does not work is not exactly clear, as code is changed to try to work for both modes; but at this point unwrapping works for new, and not for old.