(yaml) Does not handle octal or hexadecimal representations of integers

[cowtowncoder]

(from: https://github.com/FasterXML/jackson-dataformat-yaml/issues/37 by @jvantuyl)

The use of BigInteger for really big integers introduces an interesting behavior. For a very large zero-prefixed number, it won't see a leading zero as indicating octal (because BigInteger's constructor doesn't mirror Integer.parseInt or Long.parseLong).

In the long run, also doesn't support the 0o644 notation from YAML 1.2, which I'm starting to see floating about.

[cowtowncoder]

Ideally we would support all valid YAML values, to the degree SnakeYAML does. So there is no intent to limit use of octals. However, with YAML it is not always trivial to figure out proper coercions.

One useful thing here would be a set of test cases/examples. Supporting octal formats should be quite easy, but implementation will be more reliable with verification.

[jcalcote]

Just a comment on how important this item is - when you're serializing configuration data from pojos and you have fields that represent large sizes - e.g., memory, file sizes, etc. - hex numbers look a lot cleaner and mean more to the reader than decimal values. I wrote custom serializers and deserializers for long and int so I could output such fields in hex and read in whatever, but it would be nice if Jackson both supported all yaml scalar formats AND provided field annotations that allowed the developer to specify the radix for serialized values. Thanks for the great project, btw.

[cowtowncoder]

@jcalcote If you had interest in helping here it would be great to know why SnakeYAML does not support such values at this point; and if there was a way to configure it to do that. Challenge is that since jackson-databind at higher level is format agnostic it is not easy to apply coercions from hex-strings since those would typically be unexpected with other formats. So ideally it'd be low-level parser (provided by SnakeYAML) that would do coercion; we could also further have YAMLParser.Features to enable/disable such behavior if necessary.

[cowtowncoder]

Update: SnakeYAML DOES support these, as expected. Problem is more similar to #65 and code needs to be improved to handle binary/octal/hex/60-base variants, as per:

http://yaml.org/type/int.html

[Vlatombe]

This does seem to be a problem with SnakeYAML. AFAICS, the only coercion to int it does is in base 10. As noted in its documentation, it only supports JSON schema to do coercion and not Core schema which would be required to support other int formats.

[cowtowncoder]

@Vlatombe ah. Based on other notes (including ones for #65) that does sound plausible. Not sure if I should close this issue.
There is also the thing about Jackson 3.0 using snakeyaml-engine, which I suspect also takes more restrictive view of allowed conversions, and probably won't support octal numbers either.

[cowtowncoder]

There is issue #71 for hexadecimal case, at least; closing this one.