The main problem is that JDK does not guarantee any ordering, as far as
I know,
not even within class (although with Java 8 within one class declaration
order of fields
appears to be preserved?); and relative ordering of Fields and Methods
is undefined even
if order within each class was preserved (which, once again, I don't
think is specific to be true).
Things get even messier with inheritance: figuring what order even means
(for methods, declared in
interfaces) seems futile.
So, in essence, I don't think there is such a thing as stable,
predictable declaration ordering.
So to me the choice is more between "an arbitrary unstable ordering" vs
"a stable ordering with simple rules".
You're right in that the ordering isn't guaranteed by the JDK, but my
point is this: Using the ordering that falls out of reflection is
sensible because it matches the semantic ordering from the source code
in a "best-effort" way. If I have the class Person { int id; String
firstName; } it's most sensible to have "id" before "firstName"
semantically.
Of course such an ordering would not be guaranteed to be stable across
versions, and you have all the edge cases like super classes and mixing
methods and fields you mention, but people shouldn't rely on json object
order for actual machine parsing of json anyway and for human
readability the order from source code makes the most sense.
I see your point though, there's something to be said for having a
canonical (alphabetical) order, eg for unit tests where people hard-code
the json. I think we all remember the java7->8 transition where many
people had their tests break because they relied on HashMap order :)
This is just based on number requests to change it, allowing a simple
non-annotated way of custom serializations.
It also still works the same way for the simplest case of only declaring
values with nothing else.
So it seems likely that this would add a bit of functionality without
much downside -- although there is something to be said for stability,
avoiding unexpected changes to existing behavior (even if existing
behavior might be sub-optimal on its own; now it is "the standard").
However: just because many ask for this to be changed obviously does NOT
measure people who might
prefer keeping setting as-is.
So I am open to be convinced differently if anyone wants to argue for
not changing this default.
Yea you're right, my point about having toString contain some more
information is very rarely relevant so it shouldn't be an issue most of
the time and if it's useful to some people that's a good thing
What I can say here is simply that:
1. My original choice was fully based on my own experiences of "fail
silent" that drove me crazy wrt JAXB
2. This truly is the one setting that MANY people think I got wrong, and
appears to be set to "ignore unknown" for most test cases (which is
frustrating as that is exactly where one should [usually] not ignore them)
I suspect this is something that should be studied in some form wrt
wide-reaching poll.
My thinking is that sometimes Vox Populi should be listened even if it
seems wrong for long-term (caveat: if the downside is still limited, not
in areas of bigger risk like adding/keeping security holes).
I've asked around a bit and have yet to find anyone that actually wants
ignore unknown by default :) Maybe that's selection bias on my part, but
my guess is that this really is one of those cases where the people that
don't like the status quo are the ones complaining while the people that
prefer it don't say anything.
Wide-reaching poll sounds difficult and is also subject to selection
bias, but it couldn't hurt. Maybe twitter / reddit / other java communities?
Is this comment wrt default setting, or for feature itself?
I think some control of coercibility is needed even to support evolution
of existing operations.
I specifically think this feature was to answer question on whether
node.booleanValue()
should work for `IntNode` or throw exception.
However... this may need be re-thought with 2.12 added `CoercionConfig`
which will allow more configurability: should be possible to check
`CoercionConfig` for `JsonNode` which would allow specifying more
granular settings (and ideally also extremes: "no coercions" /
"everything and kitchen sink") conveniently.
My opinion is that no coercion should be possible because coercion can
have so many subtle differences across languages and may even be
internally inconsistent. But I don't work with APIs where it's necessary
in the first place, so I'm biased there – I guess if the config API is
good it's a low risk addition.
I think I will need help with this particular aspect as I neither have
had much time to think it through
nor am I actually super-fluent with Java8/Streams implementation (from
provider end, i.e. how to expose
things in canonical/compatible way).
Exposing streams isn't all that difficult. You just have to implement a
Spliterator (a simple one is already part of Iterable) and then add
Stream<X> stream() { return StreamSupport.stream(spliterator(), false); }.
Right, I think it is more important to make node types allow streaming
in a way in a way that allows re-building.
I guess there might be need to also make construction accessible in
similar way wrt `JsonNodeFactory`.
But I definitely need others to help with ideas here.
Yea there's some work to be done here. I *think* having just a Stream
and some collectors could work, but it'd be best if someone could go and
try some common use cases for transforming json trees to see how well
different APIs work. Unfortunately a bit busy with my masters atm, or
I'd do it :)
BTW, what's the time table on Jackson 3?
I suspect they are not just subsets, and that there might not be simple
or reliable one-way
conversion for these.
Yea you're right, looking at the time format strings the format is
similar but not identical. First difference I can see is F for
day-of-week-in-month vs for week-of-month. Would be nice to know where
the differences are and if it's feasible to convert between the two, but
since the JDK implementations are totally independent from each other
surveying that would need some work.
(by unix time format I assume you mean Java timestamp -- both are based
on offset from Jan 1, 1970, GMT or so, but I think Unix uses seconds,
Java milliseconds)
Yep.
That is a great idea!
Any Pivotal folks who could share their perspectives? I'd be happy to
set up meetings, whether calls or just over chat (sending email on list
obv. works well).
I've also asked around a bit, trying to reach Pivotal as well. But what
I've noticed is that a lot of people are at least expressing interest in
JSTEP since basically everyone uses Jackson. The problem is that JSTEP
is many small changes and not everyone wants to invest the time to read
through them all. One solution would be to make some shorter overview of
the important questions that go more in the preference direction than
actual technical discussion, eg the ignore unknown properties thing and
maybe alphabetical property order. First thought would be a github issue
for each – everyone has an account, it allows some basic voting and
commenting, and you can see who voted to get some idea if you run into
selection bias again. Could also then post the issue link on some other
platforms like twitter.
- 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/397e373b-464c-df98-f3ef-3c172e9496d9%40yawk.at.
