GH-1109: Fix ComplexCopier for extension-type holder readers

[bodduv]

Background

ComplexCopier.copy does a deep-copy using a FieldReader from the source and a FieldWriter to write to the destination. On the read side in the EXTENSIONTYPE branch, it uses reader.getField().getType() to get the ArrowType it needs to forward to writer.writeExtension(value, type). Vector-backed extension readers (UuidReaderImpl, VariantReaderImpl) override getField(), so this works. Holder readers (NullableUuidHolderReaderImpl, NullableVariantHolderReaderImpl) on the other hand do not. AbstractFieldReader.getField throws via fail("getField"), so any ComplexCopier.copy call with a holder reader as input fails.

As #1109 points out, overriding getField() on a holder reader is a simple fix but a holder does not have a notion of Field, the same way primitive (as opposed to extension) holder readers also do not have notion of getField() and the method is not overridden.

What's Changed

ComplexCopier only needs the ArrowType here, not the whole Field. So this PR adds a narrower accessor for that:

  default ArrowType getExtensionType() {
    return getField().getType();
  }

on ExtensionReader. The default delegates to getField(), so every existing vector-backed extension reader keeps working unchanged. Holder readers override getExtensionType() to return holder.type() — the ExtensionHolder.type() method added in #892 already returns the right ArrowType (UuidType.INSTANCE, VariantType.INSTANCE).

ComplexCopier call reader.getExtensionType() instead of reader.getField().getType(). The new method goes on ExtensionReader rather than AbstractFieldReader to sit next to the other extension-specific methods already there (read(ExtensionHolder), readObject(), isSet()). Adding a default method is this specific way is source- and binary-compatible.

Closes #1109 .

[github-actions]

Thank you for opening a pull request!

Please label the PR with one or more of:

• bug-fix
• chore
• dependencies
• documentation
• enhancement

Also, add the 'breaking-change' label if appropriate.

See CONTRIBUTING.md for details.

[jbonofre]

LGTM, Thanks!

[bodduv]

Pointing Github "Explain Error" on failing build yielded:

Looking at the recent RC workflow runs on main:

• Run 24976298831 (main branch, RC workflow): FAILED - Same arrow::decimal compilation error

This shows the issue is pre-existing in main, not introduced by PR #1137. The JNI compilation failure affects:

• The RC (Release Candidate) workflow on macos-14 aarch64
• Both on main branch and PR GH-1109: Fix ComplexCopier for extension-type holder readers #1137

Some runs passed for PR #1137 though.

[jhrotko]

Thanks for taking care of this!