Skip to content

Add support for writing unsigned numbers to CBOR #603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 15, 2025

Conversation

Radiokot
Copy link
Contributor

@Radiokot Radiokot commented Jul 9, 2025

Hey guys,

In a project I use Jackson CBOR dataformat for, the CBOR encoded in Kotlin is decoded by software expecting uint64. This PR implements support for writing unsigned numbers (long, int) in custom serializers, so values negative in Java do not end up negative in the CBOR. (https://datatracker.ietf.org/doc/html/rfc7049#appendix-A, https://datatracker.ietf.org/doc/html/rfc7049#appendix-B)

I've added generator methods and tests for them, but I am currently not sure what to do with the parser. In fact, an unsigned number can be parsed as BigInteger which is then converted to long via BigInteger::toLong, but it lacks the boundary check.

Currently, this can be used with custom serializers like this:

class UnsignedLongSerializer : JsonSerializer<Long>() {
    override fun serialize(value: Long, generator: JsonGenerator, serializerProvider: SerializerProvider) =
        (generator as CBORGenerator).writeNumberUnsigned(value)
}

class UnsignedLongDeserializer : JsonDeserializer<Long>() {
    override fun deserialize(parser: JsonParser, deserializationContext: DeserializationContext): Long =
        (parser as CBORParser).bigIntegerValue.toLong()
}

data class Account
@JsonCreator
constructor(
    val name: String,
    @JsonSerialize(using = UnsignedLongSerializer::class)
    @JsonDeserialize(using = UnsignedLongDeserializer::class)
    val balance: Long,
)

Do you think if support for unsigned numbers is needed in Jackson? If so, what should I add to proceed?

Thanks.

@cowtowncoder
Copy link
Member

cowtowncoder commented Jul 9, 2025

On reader side: not 100% sure. Was about to suggest caller has to deal with it but... haven't thought it through really.

As to support needed/useful; I think what you propose on writing makes sense as sort of "least we can do" approach.

@cowtowncoder
Copy link
Member

Ok, looks good to me.

Just one process thing before I merge this PR: unless we have gotten one already (I don't think so but if we have LMK), we'll need a CLA; doc is here:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

it only needs to be sent once before the first contribution. The usual way is to print it, fill & sign, scan/photo, email to cla at fasterxml dot com.
Once we have it I can merge this PR & it's good for any other PRs for all Jackson repos.

Thank you again, looking forward to merging!

@cowtowncoder cowtowncoder added the cla-received Marker to denote that there is a CLA for pr label Jul 15, 2025
@cowtowncoder
Copy link
Member

CLA received, hoping to do final review & merge later tonight.

@cowtowncoder cowtowncoder added this to the 2.20.0 milestone Jul 15, 2025
@cowtowncoder cowtowncoder merged commit 40fc2bd into FasterXML:2.x Jul 15, 2025
4 checks passed
cowtowncoder added a commit that referenced this pull request Jul 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cbor cla-received Marker to denote that there is a CLA for pr
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants