codegen: Support a wider range of oneOfs

[hughsimpson]

Until now, oneOfs have been handled exclusively for 'object' type children, but that doesn't cover all eventualities... This pr supports derivation of wrappers to handle a wider range of oneOf combinations. A hugely contrived test example of the wrappers is:

  case class Abrdvark(b: Boolean)
  case class Acrdvark(c: Boolean)
  sealed trait Aardvark
  case class AardvarkUUID(v: java.util.UUID) extends Aardvark
  case class AardvarkDate(v: java.time.LocalDate) extends Aardvark
  case class AardvarkDateTime(v: java.time.Instant) extends Aardvark
  case class AardvarkDuration(v: java.time.Duration) extends Aardvark
  case class AardvarkString(v: String) extends Aardvark
  case class AardvarkDouble(v: Double) extends Aardvark
  case class AardvarkAbrdvark(v: Abrdvark) extends Aardvark
  case class AardvarkAcrdvark(v: Acrdvark) extends Aardvark

and a more realistic one:

  sealed trait StringOrNumber
  case class StringOrNumberString(v: String) extends StringOrNumber
  case class StringOrNumberLong(v: Long) extends StringOrNumber

Some combinations can't be handled, but disambiguation can often be achieved by having sub-formats come before the parents

EDIT: I think in scala 3 you could probably also define a def v: T1 | T2 | T3 alias in the parent, but that might not actually be useful, idk. I haven't bothered here.

[hughsimpson]

The circe and zio variants I let an LLM write after I had jsoniter working. I guess it does save time sometimes, once there's a pattern to follow :)

EDIT: Nope, I tell a lie, it ballsed up at least the zio implementation and hid it by not writing a test.

EDIT x2: No actually, that was me, I'm the idiot

EDIT x3: I have no idea if anyone cares which bits are llm and which not, but leaning into honest disclosure as my own personal approach.

[hughsimpson]

This can be implemented later, I ran out of f's, and I'm not sure it's particularly likely to come up outside of things like converting another standard into an openapi representation (I remember FHIR had this sort of ambiguity in theory like for PDF vs plain text on some attachments?)

[hughsimpson]

Unrelated but this was failing some tests. Noticed when adding sbt2 support, just remembered about it.

[hughsimpson]

This silly double-wrapped non-discriminated oneOf structure is easy to accidentally break in jsoniter parsing, it turns out 😅 Added extra tests there.

[hughsimpson]

Annoyingly haven't managed to get a clean CI run yet, but the failure is unrelated to these changes

[adamw]

@hughsimpson yeah sorry about the flaky CI, I re-ran the failing test

[hughsimpson]

Oh wait. There was a failing openapiCodegenCore3 in there? I didn't see that locally... let me see

 sttp.tapir.codegen.RootGeneratorSpec *** ABORTED *** (26 seconds, 980 milliseconds)
2026-06-26T11:34:22.9289462Z [info]   java.lang.UnsupportedClassVersionError: zio/json/IsUnionOf$ has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

ah ok, it's a java version thing. Will push a fix.

[hughsimpson]

Sorry about that. It's the test I just enabled, it passed when I ran locally so hadn't considered it as a culprit 🤦 All should be fixed now 🤞

[hughsimpson]

hurrah, got there in the end

[hughsimpson]

This does run against scala 3 + zio on java 21, and passes there, so fine to skip this

[adamw]

Ah, not that flake'y after all! (this time ;) )