-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Jackson Release 2.14
Jackson Version 2.14 is the next planned minor release from Jackson 2.x branch.
This wiki page gives a list of links to all changes (with brief descriptions) that will included, as well as about some of the active plans for changes and fixes to include.
No release yet
None written yet.
No planned changes
No planned changes
A class of impossible-to-fix problems related to Creator methods (constructors, factory methods) is due to "duality" of Creator discovery and General property discovery. Problem is that the process goes like this:
- General property discovery is performance by
POJOPropertiesCollector: this is based on finding regular accessors (Fields, Getter/Setter methods) using both name-based auto-discovery and annotations, but also includes (annotated) Creator property parameters -- but notably not parameters of possible implicit (auto-discovered) Constructors. Accessors are combined into logical properties, expressed as (and accessed through)BasicBeanDescriptioncontainer. -
BeanDeserializerFactorytakesBasicBeanDescriptionand introspect possible Creators: this starts from scratch and finds potential Creators both by explicit annotations and possible auto-discovery. It will also try to combine already known Properties (from step 1) with now-located Creator parameters.
... and the problem is that "implicit" Creators -- ones with no explicitly annotated parameters (note: Not related to annotation of Creators method itself, but to parameter annotations!) -- will not be known during step (1) and as such will:
- Not be renamed by
PropertyNamingStrategy - Not get annotations from related accessors (normally annotation in one of accessors is essentially applied to all), nor contribute annotations to be used for others
Fixing this general problem by either:
- Moving Creator discovery as part of
POJOPropertiesCollector(preferred), or - Trying to combine pieces in step 2 more throughly (could resolve some of the issues)
would fix some of existing failing tests, and in particular help with newly found problems with Record handling (added in 2.12).
Separate configuration settings for:
Part of/related to JSTEP-3, it'd be good to have a set of simple on/off features to configure read/write/transform aspects of JsonNode, distinct from POJOs.
These settings should ideally be per-call, similar to [De]SerializationFeature.
Part of/related to JSTEP-5 (and JSTEP-6), there are things that should be easily configurable as on/off "features", or similar configuration object(s).
One challenging part is that some of the settings should probably be per-call ones (i.e. can change on specific read/write); whereas others must be per-mapper (unchangeable after construction)
Handling of Enum value reading, writing, is currently configured with a hodge-podge of SerializationFeature / DeserialiationFeatures, but as with JsonNode and Date/Time values, that's not a good place as those should be for more general aspects of handling.
This is covered to some degree in JSTEP-6.
So we should like have EnumFeatures too, changeable on per-call basis; partly to replace existing [De]SerializationFeatures (for 3.0), and partly to expose new ones.
Mentioned as one future JSTEP on https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP, there really should be limits to maximum size and/or complexity of input to process, mostly to prevent potential DoS attacks (as well as accidental "intern brought down our system by broken script" cases). There is some prior art in Woodstox, for example (see Woodstox-specific settings ("limits")).
Changes implemented so far
None