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 3 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.

* @param i Number value to write
* @throws IOException if there is either an underlying I/O problem or encoding
* issue at format layer
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add

@since 2.20

* @param l Number value to write
* @throws IOException if there is either an underlying I/O problem or encoding
* issue at format layer
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add

@since 2.20 

here as well

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