aboutsummaryrefslogtreecommitdiff
path: root/src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java
diff options
context:
space:
mode:
authorMichael Hixson <mhixson@techempower.com>2016-05-06 15:02:34 -0700
committerMichael Hixson <mhixson@techempower.com>2016-05-06 15:02:34 -0700
commit211adf2ccb0521ddb5a3eb153f1ea490e0c7249a (patch)
treecabd9bacda5bafe95566e5cffbca41173dfd06ec /src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java
parent12e884a5b88e18e6c94078872f93667dc6513c23 (diff)
downloadjackson-databind-211adf2ccb0521ddb5a3eb153f1ea490e0c7249a.tar.gz
WIP: Allow more control over default creator property values
There are no javadocs or tests yet; this is to set up a pull request for discussion. This should be a backwards-compatible change. A new method is being added to ValueInstantiator, but by default it will call an old method and have exactly the same old behavior. The behavior only changes if and when the application decides to override this new method in their own ValueInstantiator. (I suppose that if someone out there already made their own ValueInstantiator subclass with this exact signature, this change would not be backwards-compatible for them. But that seems like a very unlikely scenario.) The hasParameter and getParameter methods of PropertyValueBuffer are not used by jackson-databind itself. Those are the methods that we expect applications to use if they want finer-grained control over default values. Instead of eagerly fetching every default value (and possibly throwing an exception for missing-but-required parameters), applications can use hasParameter to check if each property is present, and then use getParameter to fetch the known-present values one by one. One weird thing about this change is that it exposes a class in the deser.impl package (PropertyValueBuffer) in the API of the root deser package (ValueInstantiator). That seems "wrong" given the names of the packages, but maybe no one cares? We could make PropertyValueBuffer implement an interface that exposes hasParameter, getParameter, and getParameters, then use that interface in ValueInstantiator instead... I suspect that no one would ever implement that interface except PropertyValueBuffer, making the interface useless. The end goal of this is to let Kotlin applications use that language's support for default parameter values. The same mechanism might work for other JVM-based languages with default values, but I have only proved it out with a Kotlin application. Related discussion: https://github.com/FasterXML/jackson-module-kotlin/issues/26
Diffstat (limited to 'src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java')
-rw-r--r--src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java8
1 files changed, 8 insertions, 0 deletions
diff --git a/src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java b/src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java
index a0db47e7f..628b4f225 100644
--- a/src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java
+++ b/src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java
@@ -4,6 +4,7 @@ import java.io.IOException;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.*;
+import com.fasterxml.jackson.databind.deser.impl.PropertyValueBuffer;
import com.fasterxml.jackson.databind.introspect.AnnotatedParameter;
import com.fasterxml.jackson.databind.introspect.AnnotatedWithParams;
@@ -178,6 +179,13 @@ public abstract class ValueInstantiator
getValueTypeDesc());
}
+ public Object createFromObjectWith(DeserializationContext ctxt,
+ SettableBeanProperty[] props, PropertyValueBuffer buffer)
+ throws IOException
+ {
+ return createFromObjectWith(ctxt, buffer.getParameters(props));
+ }
+
/**
* Method to called to create value instance from JSON Object using
* an intermediate "delegate" value to pass to createor method