Mr Bean is an extension that implements support for "POJO type materialization";
ability for databinder to construct implementation classes for Java interfaces and abstract classes, as part of deserialization.
Extension plugs in using standard Module
interface, and requires Jackson 2.0 or above.
Module is licensed under Apache License 2.0
To use module on Maven-based projects, use following dependency:
<dependency>
<groupId>com.fasterxml.jackson.module</groupId>
<artifactId>jackson-module-mrbean</artifactId>
<version>2.11.0</version>
</dependency>
(or whatever version is most up-to-date at the moment)
To use the the Module in Jackson, simply register it with the ObjectMapper instance:
ObjectMapper mapper = new ObjectMapper()
// com.fasterxml.jackson.module.mrbean.MrBeanModule:
mapper.registerModule(new MrBeanModule());
Once module is registered, all you need is an interface like:
public interface Point {
// may have setters and/or getters
public int getX();
public void setX(int value);
// but setters are optional if getter exists:
public int getY();
}
and then you can read JSON into an implementation class of given interface or abstract class:
String json = "{\"x\":12,\"y\":35}";
Point p = objectMapper.readValue(json, Point.class);
(to contrast, try running this example without module registration -- this would result in an exception being thrown)
Note: this works transitively as well, meaning that implementation classes will be materialized for any interface and abstract types.
Module implements Jackson's AbstractTypeResolver
interface and registers it via Module interface. This is how it gets invoked when an abstract type is encountered, which is problematic for deserialization (unless polymorphic handling is enabled; see the next section).
Actual byte code generation uses ASM library, and simply generates methods for all abstract methods. No naming convention is required; basic signature is enough. This means that zero-argument methods are considered "getters" and one-argument methods "setters". Naming is considered to be able to generate internal field; but beyond this naming is of no consequence. Annotations are not introspected at this point; however, Jackson databinding will make use of them later on -- typically annotations from implemented interface or abstract class get used, as no annotations are added to the implementation classes.
One potential area of conflict is that of handling of so-called polymorphic types (POJOs annotated with @JsonTypeInfo
annotation).
Since base classes are often abstract classes, but those classes should not be materialized, because they are never used (instead, actual concrete sub-classes are used).
Because of this, Mr Bean will ''not materialize any types annotated with @JsonTypeInfo annotation''.
Another potential concern is that of "default typing", in which case Jackson would use polymorphic type handling for wider set of types. Use of Mr Bean is not recommended together with enabling of "default typing", since either mr Bean or default typing is not going to work correctly.