JSTEP feedback

[Jonas Konrad]

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

[Tatu Saloranta]

On Tue, Sep 1, 2020 at 9:51 AM Jonas Konrad <m...@yawk.at> wrote:

Hi,

This E-Mail contains some thoughts on various aspects of the JSTEP
proposals at https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP .

Cool, thank you very much for sending these!

 

# 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.

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".

 

## 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.

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.

 

## 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.

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).

 

## 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.

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.

 

## 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.

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).

 

btw, you call them JsonObject and JsonArray here, are you thinking about
renaming them?

Ah good point. No, I'll fix the document -- renaming plan, if any, needs to be spelled out.

 

## 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.

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.

 

# 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?

I suspect they are not just subsets, and that there might not be simple or reliable one-way

conversion for these.

But I do not really have a good knowledge on this.

It almost feels like we'd need a small group of experts to rewrite it: bit like how Kotlin module

now has 2 owners with actual Kotlin knowledge (as well as help from original Kotlinista, Jayson)

who can hash out good solutions, decisions.

 

- 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?

Date has the big problem of it being a coordinate in space but one without TimeZone.

Calendar does have TimeZone so in a way it ought to be slightly easier (but obv has horrible API).

 

## 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

(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)

Yes, since users can easily change it to timestamp, default probably should be textual (even if from processing perspective -- not just size, CPU -- timestamp handling can be orders of magnitude faster).

That's what users expect, esp. outside Java-to-Java interactions.

---

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?

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).

-+ Tatu +-

 

- 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 jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/91415551-dbdf-8e2c-9192-1eb12d396e4b%40yawk.at.

[Jonas Konrad]

> 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

[Tatu Saloranta]

Ok; at least I'll record this as "may need further discussion".
In fact I'll probably need some way to track my thinking of status of
change suggestions
in sort of "No objections" / "some [limited?] concerns" / "no consensus".
Mostly so that by process of elimination we can quickly move safe/easy
ones into "let's do it"
category and continue discussions/decision process for trickier ones.

>
> >
> > 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

Ok.

> > 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.

Interesting. Yes, I have been wondering about this. It might be down to personal
approach too -- to me ignoring all unknown properties as general
default tends to go with "let's change
this one bit see what happens" school of implementation (not to be confused with
strategic opening of specific types which can be disciplined).

>
> Wide-reaching poll sounds difficult and is also subject to selection
> bias, but it couldn't hurt. Maybe twitter / reddit / other java communities?

I think this question definitely makes it into short list of hot &
highly debated defaults
and needs more attention that most other choices.

>
> > 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.

Ok one clarification: I think that coercion (if any) works quite
differently between
POJOs and JsonNode since:

1. For POJOs type coercion must be automatic since it occurs at binding time and
user gets what she gets. Intent is sort of clear from definition.
2. For JsonNode there is no typing read/bind and so "true" type is
retained in tree...
But access (getter) does then indicate intent, to some degree.
Since we can (and do)
have multiple accessors it is easier to support different
strict/lenient usage patterns partly
by just having separate "intValue()" (strict[er]) and "asInt()" (looser).

I suspect it will be easier to discuss details when drilling down on
this. I also think that
new `JsonNodeConfig` (which I hoped to introduce in 2.12 but likely
will be postponed)
could help design it to fit better than if CoercionConfig needed to be
used directly.

Oh and as for context: I know there is another quite divisive issue,
between strict, static typing
proponents and looser/more lenient dynamic typing ("scripting") proponents.
Given that JSON (et al) is used between systems that are often
implemented by folks with different
views on this, it is quite natural it surfaces on Java APIs too: ones
that often would be more geared
towards static style of doing things.

>
> > 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); }.

Yup. I don' t think it is difficult, it's just something I don't have
experience doing yet.

> > 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 :)

Right, this is definitely where actual tinkering, using API, would make sense.
I think I could have avoided couple of mistakes in JsonNode if I had
tried using it more
myself (issues I uncovered when I ended up converting some JSON
handling code at work,
code that was using org.json or json-lib, and matched JsonNode mostly
well but... with some
edge cases).

>
> BTW, what's the time table on Jackson 3?

Good question. Originally I thought 2.9 would be it for 2.x, which is
why I started work 2 years ago or so.
But then I started thinking about challenges of users upgrading
2.x->3.0 and thinking harder about whether
all changes I planned were impossible to do in 2.x -- finding many
weren't. That is sort of where 2.10 came from;
ideas to keep on pushing 2.x towards 3.0, esp. wrt Builder-style
construction, starting to deprecate things that
would not convert nicely.
It also became clear that if I wanted to go on with 2.x improvements,
there is actually no shortage of things that
can be done, in general.

Then again I feel 3.x has a lot of potential: solves the ObjectMapper
/ TokenStreamFactory separation, mutability
rather nicely; has some performance improvements; solves a few
otherwise difficult low-level problems.

So the question is: when should we move back to focus on 3.0, making it real.
I am thinking of going back to that right after 2.12, maybe starting
with big ticket items:

1. `JsonProcessingException` (checked) -> `JacksonException`
(unchecked) -- lots of changes but mostly mechanical
2. Java package: com.fasterxml.jackson -> com.fasterxml.jackson3 (or
whatever new Java package name deemed)
- similarly for Maven: is it
"com.fasterxml.jackson3.core:jackson-databind" or
"com.fasterxml.jackson3.core:jackson3-databind"?

Assuming this is what happens, timeline is still flexible: if only
including existing changes and some of must-haves, could get release
candidate out during Q1 2021. If going for existing JSTEPs, it could
stretch, but ideally would still result in an RC by, say, June/July
2021.

I have a feeling that upgrade this time might be more challenging than
1.x -> 2.x however, due to larger user base.
The plan is to once again allow full co-existence of 2.x and 3.x -- I
don't think it can be any other way, if one was to force one or the
other,
I don't think 3.0 would see much adoption by existing Jackson users --
but that can also delay adoption.
On upside I think that indirect use via Spring, for example, can help
here: especially since one exception to above versioning idea
(of repackaging everything is this)

- jackson-annotations 2.x and 3.x WILL retain old coordinates,
designed to be backwards/forwards-compatible so
that Jackson 2.x using code can actually use `jackson-annotations`
3.x (and to some degree vice versa).
Effectively there will be some coupling like "2.13 and 3.0 of
annotations contain same definitions"
(I am happy to expand on this if anyone interested in details but for
now I hope above suffices)

> > 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.

Yes. I think that something like... "Working Group" or SIG -- that is,
more than 1 person
with deep enough knowledge of domain, working together -- could write
a document that
outlines differences, possible ways to unify things (translate?)

> >
> > 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.

Yes. My thinking with JSTEP was to basically present something, anything,
and hope that it triggers ideas for improvements. So take existing approach as
little more than a Proof-of-Concept of trying to come up with something better
than bunch of Github issues.

I think you pointed out the big(gest) flaw -- lack of interactivity.
No way to comment or
vote, or even indicate interest. In that way, this is inferior to
Github issues, sadly. :)

So, I think existing JSTEPS -- or similar replacement thereof -- could
be more like
"Big Feature Proposal with Some Preliminary ideas": a starting point
which at some point
should be turned into something else, something more defined.
It could be Github Issue based, although the overall Big Issues
probably should live outside
of actual concrete repos (i.e. not in `jackson-databind`). In a repo
that contains such... Epics?
... with links to implementation ones.
I am not a big advocate of Jira but this is something where Jira would
actually be quite ok to use.

Still, more important than exact process is that more interested
individuals need to be involved.
There are many interested people, I think, with various constraints in
involvement.
But tools to solve these exist in some form.

I wonder if one way forward would be to look into social/interaction
part, by maybe doing:

1. Outline domains (problem/design/impl area) for which a WG/SIG would
be needed (and once again,
by wg/sig I simply mean 2 or more interested developers)
2. Add some mechanism to indicate tentative interest by developers on
one or more of (1)
3. Figure out how to get interested people working together solving
problems within domains

For example, the whole Date/Time aspect seems like pretty consistent area.
Java 8 streaming support could be another one (not just for JsonNode,
but maybe starting there)...
although, JsonNode (Tree Model) API itself could conceivably be a domain.
Various format modules could be domains of themselves (Avro, CSV,
Protobuf, XML).

-+ Tatu +-

>
> - 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 jackson-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/397e373b-464c-df98-f3ef-3c172e9496d9%40yawk.at.