Add option for serializing and deserializing non-final static fields, disabled by default

[MikeDombo]

Sorry for all the PRs, but I just wanted to get all my changes up for review ASAP.

This change adds the option INCLUDE_STATIC_FIELDS which is disabled by default. When enabled, it will allow the serialization and deserialization of non-final static fields. I am excluding final static fields because they cannot be properly deserialized without modifying the field access. Current behavior (2.12) is that the final static field will be serialized but will fail to deserialize.

I also needed to expose the features list of the JSONReader and JSONWriter in order for the annotation plugin to have access to the features and check if something is enabled or not. I would have used a method reference like JSONReader::isEnabled(Feature) but that's only available for Java 8 and I of course don't want to increase the version requirement unless that's something that you want to do.

[cowtowncoder]

Absolutely delighted to get these PRs, no need to apologize at all! :-)

Very good analysis, and I agree that Java 8 is not (yet) available unfortunately for jackson-jr hence this makes sense.
Baseline will eventually be increased (at very least in 3.0) but I wasn't planning to raise it for 2.13.

[MikeDombo]

Thank you for all the merges @cowtowncoder!

Is there any timeline for when 2.13 might be released?

[cowtowncoder]

Np, happy to get this new improved functionality!

Timing of releases is always challenging. With 2.13 I was hoping for a relatively "small" version, completed quickly, but including one major rewrite: that of Creator introspection -- this because it causes a whole class of problems where properties passed via Creator (constructor or factory method) are not properly synced with "regular" properties (set using Field or setter Method).
But that is a huge undertaking and I have not really dug in.
Challenge being that my time for Jackson is somewhat limited; as well as big scope of Jackson itself (that is, bugs reported, fixes etc, work that is needed and has high priority). Fortunately I am not maintainer of all modules (most notably Scala and Kotlin modules have active maintainers), but jackson-databind alone gets lion's share of issues.

So. If all goes well, I will work on that one big feature, get it done sometime in early June, and we can move to pre-release/release-candidate phase in late-June/early-July. It takes usually at least 1 month to get through RCs (to get any useful feedback, patch things), sometimes up to two. Release candidates are pushed to Sonatype and can be usable, but the official 2.13.0 could come out earliest around mid-August I think; more likely early September.

I do want to make sure the release does not get postponed unnecessarily, of course; current set of changes (https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13) itself would probably qualify for a release (as in, there are plenty of fixes, improvements).
So I think I'll probably start thinking about release schedule in 2 weeks or so (I'm on vacation next week) and will try to send something about plans on jackson-dev mailing list.

[MikeDombo]

💯 Support for creator and similar would be awesome. I hacked around the existing implementation and extended BeanReader so that I can set properties using Lombok's generated builder.

Have a look if you're interested: https://gist.github.com/MikeDombo/49b410f9561451a3a96f72322e4308f0

I'm sure you wouldn't want this implementation in jackson-jr since it is fairly hacky, but I think it is an interesting use case for further extension points. Basically, I'd want a way to override create(), setPropertyFor, and some sort of finalizeBean so that I can create a builder, set the properties using the builder, and then finalize the builder calling build to return the final bean.

[cowtowncoder]

Ah quick clarification: comment above was mostly about Jackson in general, since release schedule of jackson-jr is part of the whole Jackson suite. So although otherwise I'd probably release new version of jackson-jr itself more quickly, core components need some more work.
That said, support for using constructors and factory methods would definitely be useful.

I'll have a look: I don't have anything against further additions, within context of keeping jackson-jr implementation as compact as possible (sort of minimalistic view).

[cowtowncoder]

That looks usable as basis: I filed #87 for possible work. Looks like we'd need to add at least one annotation type as well as Jackson @JsonPOJOBuilder is unfortunately not part of jackson-annotations (not quite sure why I decided to add it there: unlike other databind annotations, it does not seem to have dependencies to types there).
Not a big deal, just something to note.

Otherwise I assume some of extension points may be reused but like you said, some existing functionality needs to allow overriding or add extension point(s).