Hi Scott,
On 10/23/26 23:03, Scott Murphy Heiberg wrote:
Hi all,
PR #2949 (https://github.com/apache/groovy/pull/2949) moves groovy-yaml,
groovy-toml and groovy-csv to Jackson 3. Paul asked that one consequence be
raised here rather than land quietly.
Jackson 3's YAML parser resolves unquoted values by the JSON schema, and the
resolver can't be configured. Only lowercase true, false and null and plain
decimal numbers take a type. yes/no/on/off, True/FALSE, Null, ~ and 0x1F/017
now arrive as strings, where Groovy 6 read them as booleans, null or integers.
The case most likely to bite: "enabled: off" read with YamlSlurper.parseText
now gives the String 'off', which is truthy, with no error. The typed parseAs/parseTextAs
API rejects it for a boolean property instead.
The PR documents this as a 7.0 breaking change and has a test that pins it. The
YAML guide shows how to load with SnakeYAML directly for documents that need
YAML 1.1 typing. Comments welcome, especially if anyone thinks it shouldn't
ship as is.
I see the problem. On one hand it makes sense to progress to YAML 1.2
core, on the other hand this is a breaking change... Only we do not move
to YAML core even. So it looks to me we move from lax yaml parser to a
non-standard conform yaml parser and break code along the way - and
that, even though the JSON schema ths is based on, would allow custom
type transformations.
On the other hand supporting a yaml parser that orientates itself at
YAML 1.1 and is compatible will also require some effort to keep maintained.
For me personally I have a few cases with YAML:
* gitlab CI/CD: Here I would want support for aliases, anchors and
merges as part of the standard. And also includes, but those are not
part of the standard. Right now groovy-yaml is not suited for that
* simple configuration files, usually I do that according to the newer
schemas, so no conversion from "on" to boolean
* agentic ai producing yaml. Here validation against a schema is
important for me. I do not want the lax standards of yaml 1.1 here.
* skill files for ai with front matter. arguably this is not yaml. This
tends to be more mardown framing with a yaml block for the
specification. Accordingly you have to read a subsection of the file as
yaml, not the whole file. Or first extract and then provide as string to
the parser.
What I do not have to deal with usually is legacy yaml, that follows the
old conversion ideas, that needs to be migrated to a new jackson
version. I did have that with some spring stuff, but that was years ago.
bye Jochen
