Allow inlining/unwrapping of child objects

Ah. At this point, this is both the most highly voted open issue, and the second oldest open issue.
Plus given that the oldest one is to be soon implemented (related to earlier implementation of JACKSON-102), will soon also be the oldest.

Which is just to say that I will see if this could be implemented for Jackson 1.8.

Quick note: unfortunately this will not make it in 1.8. Since it is the highest voted open issue, it will be one of 2 "must haves" for 1.9, along with AnnotationIntrospector rework ("property unification", combine annotations for setters, getters and fields of same property).

Three Questions:

Will the enhancement be applicable just during serialization, or will it have a deserialization counterpart to "wrap" appropriate JSON elements into an object?

Will the enhancement have any any new unwrapping/wrapping functionality for (Java or JSON) arrays?

Also, will the enhancement be applicable just to unwrapping Java child objects, or will it include unwrapping child JSON elements?

If implemented this would be symmetric, i.e. supported in both directions. Ideally new features are symmetric, although some existing functionality is not (root-element wrapping to support JAXB and frameworks).

Arrays/collections would probably not be supported, since they are just containers for anonymous values. Although separate functionality could be implemented for single-element wrapper arrays (if so, it'd deserve its own Jira entry).

As to JSON vs Java, there is another Jira entry for doing the reverse I think; from implementation perspective both need to be supported separately, and most likely annotations differ as well. It would be nice to have both included in same release, to have orthogonality. But given different challenges in implementation (mostly due to streaming/incremental nature of data binding), it is likely these will be implemented separately.

Arrays/collections would probably not be supported, since they are just containers for anonymous values. Although separate functionality could be implemented for single-element wrapper arrays (if so, it'd deserve its own Jira entry).

Issue 592 so logged.

http://jira.codehaus.org/browse/JACKSON-592

Ah. This was ridiculous amount of work; but now there is @JsonUnwrapped, which will work as expected, both for serialization and deserialization.

One caveat is that this will not work well with polymorphic types. But aside from that, things should just work.

Is it possible that this feature obeys somehow the @JsonIgnoreProperties(ignoreUnknown = true) setting?

Because currently (trunk) a NullPointerException is thrown when I try to deserialize a json string into an object with a @JsonCreator constructor and a @JsonUnwrapped field.

Note: only "id" is present in the creator, "name" is an optional attribute.

See test below that reproduces the problem

 
 @Test
 public void testExtensions() throws SerializerException, JsonGenerationException, JsonMappingException, IOException {
     // create a new instance of, with a wrapped B inside.
     A a = new A(new B("test"));
     
     // serialize a, prints "{"name":"test"}" as expected.
     ObjectMapper mapper = new ObjectMapper();
     StringWriter w = new StringWriter();
     mapper.writeValue(w, a);
     String json = w.toString();
     System.out.println(json);
     
     // try to deserialize a A throws exception.
     A a2 =  mapper.readValue(json, A.class);
 }
 
 @JsonIgnoreProperties(ignoreUnknown = true)
 public static class A {
     private B b;
     
     public A(B b) {this.b = b;}
     
     @JsonUnwrapped
     public B getB() {
         return b;    
     }

    // This creator is not working, a NullPointerException is thrown
     @JsonCreator
     public static A creator(@JsonProperty("id") String id) {
         return new A( new B(id) );
     }

    // This creator works
	//        @JsonCreator
	//        public static A creator(@JsonProperty("id") String id, @JsonProperty("name") String name) {
	//            return new A( new B(id) );
	//        }

     
 }
 
 @JsonIgnoreProperties(ignoreUnknown = true)
 public static class B {
     String id;
     String name;
     
     public B(){}
     public B(String id) {this.id = id;}
     public String getId() { return name;}
     public String getName() { return name;}
     public void setName(String name) {this.name = name;}
 }

Yes, basically implementation has to accept all kinds of things first, as it can not quite determine required ones. This is mostly to support multiple unwrapped objects, without requiring deserializers to declare things they accept... it's a mess.
This is very tricky feature to support, so there may be some edge cases;but i'll see what's the issue with the test case.

It would be nice if the JsonUnwrapped annotation had an optional "prefix" attribute which could be prepended to each property of the object being unwrapped. That way, if you had a parent object with two child objects of the same type, you could annotate them both with JsonUnwrapped without having a clash in attribute names.

For example

class Bean {
   String name;
   @JsonUnwrapped(prefix="start")
   Point start;
   @JsonUnwrapped(prefix="end")
   Point end;
}

could be serialized as

{
  "name" : "...",
  "startx" : 1,
  "starty" : 1,
  "endx" : 99,
  "endy" : 99
}

This would also be useful if the child had an attribute with the same name as one of the parent's attributes.

Sounds like a good idea: can you create a separate feature request? The reason is that it'll be easier to track this; whether this can get in 1.9 depends on various factors.

I added feature request JACKSON-669 to track this