Is there any reason not to use names of enum?

[kwon37xi]

When I see EnumSerializer, it does not use enum's name. It uses ordinal.

This makes a problem when the order of enum constants changed
When the order changed, if it throws an exception, it's ok.
But if the deserialized ordinal exists in the new enum class, kryo does not throw any exception, just sets wrong enum value.

I made EnumStringSerializer by myself, and want to contribute to this project.

But Kryo's enum support has been very long time. I'm not sure whether you have specific reason not to use names for a long time.

Is there any reason not to use enum's name?

[NathanSweet]

Ordinals are smaller. We'd merge an Enum serializer that uses names, but it
won't be used by default. It should be called EnumNameSerializer.

On Mon, Jun 22, 2015 at 2:54 PM, KwonNam Son notifications@github.com
wrote:

When I see EnumSerializer, it does not use enum's name. It uses ordinal.

This makes a problem when the order of enum constants changed
When the order changed, if it throws an exception, it's ok.
But if the deserialized ordinal exists in the new enum class, kryo does
not throw any exception, just sets wrong enum value.

I made EnumStringSerializer by myself, and want to contribute to this
project.

But Kryo's enum support has been very long time. I'm not sure whether you
have specific reason not to use names for a long time.

Is there any reason not to use enum's name?

—
Reply to this email directly or view it on GitHub
#321.

[magro]

@NathanSweet Don't we need a replaceDefaultSerializer then?

[NathanSweet]

Don't think so, EnumSerializer is lower priority than any default
serializer added by a user.

On Mon, Jun 22, 2015 at 6:02 PM, Martin Grotzke notifications@github.com
wrote:

@NathanSweet https://github.com/NathanSweet Don't we need a
replaceDefaultSerializer then?

—
Reply to this email directly or view it on GitHub
#321 (comment)
.

[magro]

Ah, right.