diff options
author | Michael Hixson <mhixson@techempower.com> | 2016-05-06 15:02:34 -0700 |
---|---|---|
committer | Michael Hixson <mhixson@techempower.com> | 2016-05-06 15:02:34 -0700 |
commit | 211adf2ccb0521ddb5a3eb153f1ea490e0c7249a (patch) | |
tree | cabd9bacda5bafe95566e5cffbca41173dfd06ec /src/main/java/com/fasterxml/jackson/databind/deser/ValueInstantiator.java | |
parent | 12e884a5b88e18e6c94078872f93667dc6513c23 (diff) | |
download | jackson-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.java | 8 |
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 |