This project is the main hub to all kinds of documentation related to Jackson JSON Processor.
For your first steps in understanding how to use Jackson, following tutorials are good places to start:
- Jackson Tutorial by StudyTrails
- Jackson in N minutes (
- Older Jackson in 5 minutes version (useful for 1.x)
- Jackson on Android (proguard definitions)
JVM Languages beyond Java
(need links to Scala, Kotlin, Clojure tutorials, articles)
Documentation under Jackson GH projects
Jackson project hub has links to all active Jackson projects. These projects contain plenty of project-specific documentation, such as:
- Core Annotations
- Streaming API
External (off-GitHub) documentation
Following sites are good sources for documentation:
And here are good articles around the web:
- General usage
- Jackson annotations:
- Streaming reading/writing
- Polymorphic type handling:
- Data formats beyond JSON
- Platform-specific Jackson integration
The easiest ways to participate is to join one of Jackson mailing lists (Jackson google groups):
- Jackson Announce: Announcement-only list for new Jackson releases, meetups and other events related to Jackson
- Jackson User: List dedicated for discussion on Jackson usage
- Jackson Dev: List for developers of Jackson core components and modules, discussing implementation details, API changes.
There are other related lists and forums as well:
- Smile Format Discussion: List for discussing details of the binary JSON format called Smile (see Smile Specificat
- Jackson Users is a Jackson-specific discussion forum for usage questions.
On Jackson versioning
Note that there are two major Jackson versions: 1.x (1.0 - 1.9) and 2.x (2.0 - 2.3). These versions can co-exist as they are located in different Java package and use different jar naming and Maven group/artifact ids. But this means that you have to make sure that all components in use have matching major versions: specifically, Jackson 2.x code does NOT understand or support Jackson 1.x annotations, or vice versa.
Minor versions (like 2.1 and 2.2) are backwards compatible with respect to public API: old code should work without recompilation, if (but only if) it relies on external API; public methods, annotations. When overriding internal functionality, we try hard to maintain backwards compatibility between adjacent minor versions; need for changes is indicated by deprecating internal methods. Recompilation is thus recommended when extending by sub-classing, for example.