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

Open
wants to merge 4 commits into
base: 2.x
Choose a base branch
from

Conversation

Radiokot
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants