Which CBOR library to use ? (Jackson, CBOR-JAVA)

[sbernard31]

Current state :
Currently we have decoder/encoders based on both implemenation available in the repository but we should not keep both for the stable release. (to limit library dependencies)
Note we are currently at the beginning of the development phase for 2.0.0 and we release milestone regularly, for now if those milestones contains both implementation this is not a problem. So this is most a long term issue.

Why both implementation ?
SenML CBOR was a contribution from @cavenaghi9 and it choose Jackson as CBOR implementation.
OSCORE support is currently in development (by @rikard-sics) and based on californium-oscore which depends on CBOR-JAVA.

I don't know the initial reason about Jackson choice.
CBOR-Java choice is because COSE-JAVA will be needed and depends on it. (see #866 (comment) for more details)

Which should we choose ?
This is a comparison table to help to do the better choice.

Jackson	CBOR-Java
❌ NOT used by COSE-JAVA (cose-wg/COSE-JAVA#102)	✔️ used by COSE-JAVA
✔️ Active Project (release / activity) Committers are open to modification	✔️ Project active (release / activity) Committers are open to modification
✅ jar size : + only 58,7 ko (v2.11.2) for Leshan because we already depends on jackson-core(351,5ko) & databinding(1,4Mo) & annotations(68,4ko), if that was not the case total dependency will be ~1878 ko 😨 )	✅ : jar size : 170,5ko (v4.0.0) + (dependency to number v1.4.3 213,8ko : Total 348,3ko )
❓ JSON Jackson is known as fast (we don't know for CBOR)	❓ No idea about performance.
❕ : No support for Date but could be implemented ((FasterXML/jackson-dataformats-binary#230))	✔️ Support of Date (without bug since 4.3.0 peteroupc/CBOR-Java#14))
❗ Not so easy to handle tag, probably because Jackson API is more JSON friendly than CBOR friendly (FasterXML/jackson-dataformats-binary#105 (comment))	✔️ CBOR friendly API.
✔️ Support BigInteger/BigDecimal	✔️ Support of BigInteger/BigDecimal (since 4.3.0 peteroupc/CBOR-Java#13 (comment)
✔️ Same API as Jackson JSON we already use (more consistent)	❕ : Does not respect Java Naming convention.
	❕ Come with a dedicated number implementation not so Java friendly.
	✔️ : We can easily handle field order since 4.3.0 ( peteroupc/CBOR-Java#13 (comment))

(Note : clearlydefined sounds to prefer Jackson than CBOR-Java:com.upokecenter/cbor, this can make integration in eclipse project faster.)

[sbernard31]

Currently my feeling is Jackson would be better but COSE-JAVA don't support it which could be critical issue.

[cowtowncoder]

One note on performance: while I am not aware of independent evaluation, Jackson project itself uses this:

https://github.com/FasterXML/jackson-benchmarks/

to compare relative performances of backends: CBOR implementation is somewhat faster for same (smallish) test content than JSON; maybe 30-40% faster to deserialize, and similar for writing.
It might be useful if anyone wants to understand performance aspects, and/or maybe add separate tests (or just use for inspiration).

[sbernard31]

I change a little bit the table above ☝️ and now it's maybe less clear that Jackson is more appropriate.

[jvermillard]

jackson cbor doesn't support the full spec and due to it's JSON root it's not easy to support features like tags:
FasterXML/jackson-dataformats-binary#105

in general non json concept are not well (or not at all) mapped in jackson cbor. I don't like the way jackson hide some details about the encoding and try to make cbor feel like json where there is much more complexity in cbor (finite vs infinite length encoding, tags for date etc..)

[cowtowncoder]

Jackson is not CBOR-specific (nor necessarily JSON any more) and due to supporting multiple formats there are definitely trade-offs. Most users do not really care about most of low-level details of encoding formats (and details vary across formats), but if access to format-specific details is important then CBOR-only libraries have their benefits for sure.

This is similar to question of XML-specific tools (DOM trees) vs higher-level databinding like JAXB or Jackson XML module -- latter is significantly more convenient for most use cases, but to do that will encapsulate many of details. Use of former will couple users to specific format and typically require more knowledge, make users care about such details.

The question, then, is: is Leshan's focus on using CBOR for communication, or doing something else? How much do users really care about underlying format(s)? Is format focus of API design (usually it isn't): or should design accommodate maybe multiple access formats (f.ex to support clients that might prefer format like json or yaml for simple textual access).

Anyway some food for thought.

[sbernard31]

Some more news from CBOR-Java and most of issues detected will be fixed soon.

[sbernard31]

We finally go to CBOR-JAVA.
There is no more issue related to it.
It is used by COSE-JAVA that we will probably depends on for OSCORE.
More CBOR friendly API.