Hi,
This E-Mail contains some thoughts on various aspects of the JSTEP
proposals at https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP .
# JSTEP 2
## SORT_PROPERTIES_ALPHABETICALLY
While it's true that there is no guarantee, in practice the order that
reflection returns matches the declaration order. Sticking to
declaration order is sensible for two reasons:
- Declaration order is already the order that makes the most sense
semantically. Related fields will be close together and such.
- It provides a very simple solution for people that want to
"reorganize" the order of their json fields. With property sorting I
don't know how I would reorder fields, for example when jackson suddenly
spits out "first_name", "last_name", "id" as the property order even
though id makes most sense as the first property. Maybe I would try
using JsonProperty.index, but that only affects stuff like protobuf.
People shouldn't *rely* on the order of properties in json objects and
they shouldn't rely on the order returned by reflection, but there is
still some value in sticking to that order in my opinion.
## READ_ENUMS_USING_TO_STRING
What's the reasoning for this change? I can see two arguments here: On
one hand it makes it easy for users to use custom names (name() is
final) but on the other hand existing toStrings on enums may contain
auxiliary data that may be harmful for serialization (I found
https://java-browser.yawk.at/com.google.guava/guava/29.0-jre/com/google/common/base/StandardSystemProperty.java#com.google.common.base.StandardSystemProperty%23toString()
as an example).
If those are the reasons, I think I'd probably agree that using toString
is better on the balance.
## FAIL_ON_UNKNOWN_PROPERTIES
This is a weird one. It's super common to realize late that this should
be false for a project, but true seems like sane behavior to avoid bugs.
Also hard to get a general survey on this – sure, many people might
complain about it, but many people that are happy now would potentially
spend a lot more time debugging if this feature was flipped because they
don't realize their properties are being ignored.
I think the added exception is the smaller issue when compared to a
"fail silent" scenario that disabling this feature introduces.
## Changes to Date/Time defaults
See JSTEP 5.
# JSTEP 3
## LENIENT_SCALAR_CONVERSION
Sounds like a big can of worms. Type coercion is a pita. Also remember
that the type coercion in js, which would probably drive the coercion
for jackson json parsing, is inconsistent at times.
## TRIM_DECIMAL_TRAILING_ZEROES
true sounds like a sane default. imo values that are printed as scalars
in json are best off being in their "canonical" representation to get
through different json parsers untouched.
## Traversal
I'd follow java collection conventions: forEach method for ObjectNode
and stream method for ArrayNode. Maybe a fieldStream for ObjectNode too,
or even better, a proper entrySet that matches Map.entrySet behavior.
btw, you call them JsonObject and JsonArray here, are you thinking about
renaming them?
## Transformation
Maybe make a collector to use with streams? I think adding full blown
transformation methods to the container nodes is a step too far – you
could easily imagine tens of methods for various transformations that
few people would ever use because transforming json nodes directly is
not very common.
# JSTEP 5
Yes pleeeaasseee.
## Format strings
My proposal: Use java.time for initial deserialization everywhere, then
convert to other types as necessary. This would allow using only
java.time format strings.
Problems:
- compatibility with jackson 2 since you want to keep the same
annotations – how compatible are simpledateformat format strings with
java.time format strings?
- correct conversion. For Date this is easy, always parse as Instant and
convert to Date. But what about Calendar, where there's a weird mix of
time types?
## Default serialization format
IMO stick to java.time toString formats, meaning usually ISO 8601
strings. There's really no need to make the unix time format the default
anymore – ISO 8601 is more readable and the few bytes in savings really
don't matter when printing json
---
A common issue I have with evaluating these changes is that I have only
a narrow view of how people actually use jackson. I don't know how much
better that is for you Tatu, but maybe it would be worth it asking an
org like Pivotal that does lots of consulting involving jackson (as part
of spring) for feedback on how these changes would affect common use cases?
- Jonas
--
You received this message because you are subscribed to the Google Groups
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jackson-dev/91415551-dbdf-8e2c-9192-1eb12d396e4b%40yawk.at.
