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:

defaultArrowTypegetExtensionType() {
returngetField().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 .

[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!

[bodduv]

@jbonofre there might be an issue with CI, could we try to rebuild?

[jbonofre]

I'm working on CI fix right now.

[lidavidm]

@bodduv please rebase

[bodduv]

Thank you for taking a look, @lidavidm. I make the PR up-to-date.