Support collections nested in Map fields during (de)serialization

[welpie21]

The bug

ValueClassConverter (the read path used by select(Class, ...), create(Class, ...), Value.get(Class), etc.) only handled objects and scalars as Map entry values — the // todo - array support inside maps at the old line 204. It also only extracted the raw value type of the map (secondTypeArgumentRaw), so nested generics lost their element-type information.

Reproduction (before the fix)

POJO field shape	Failure on read-back
Map<String, List<String>>	SurrealException: Unsupported value: ['apple', 'banana'] (thrown from convertSingleValue)
Map<String, List<Pojo>>	SurrealException: Unsupported value: [{ first: 'Ada', last: 'Lovelace' }]
Map<String, Map<String, String>>	SurrealException: Failed to create instance of ... caused by NoSuchMethodException: java.util.Map.<init>() (the object branch tried to instantiate the raw Map interface as a POJO)

The write path (ValueBuilder) already recurses through collections and maps correctly — verified by a write-only test — so this is a read-path-only fix. Records use the same convertValueToType path and were equally affected.

The fix

In the Map branch of ValueClassConverter.convertValueToType, keep the full generic Type of the map values (new secondTypeArgument, replacing secondTypeArgumentRaw) and route every entry value through convertValueToType(entryValue, valueType, valueGenericType) — the same recursion used for top-level fields. This makes arrays inside maps hydrate with correct element types, and nested maps recurse into the existing Map branch instead of being treated as POJOs. The TODO is resolved and removed.

No changes to the cached per-class field metadata (SurrealFieldNames) were needed; the fix is purely in the value-conversion recursion.

Tests

• MapNestedCollectionsTests (main suite): round-trip create → select for Map<String, List<String>>, Map<String, List<Name>>, Map<String, Map<String, String>>, plus a write-path-only structural check.
• RecordMapNestedCollectionsTests (record suite): round-trip of a record with all three shapes.
• Full ./gradlew test and ./gradlew recordTest pass.

🤖 Generated with Claude Code

[emmanuel-keller]

Review — approve with nits.

The fix is correct for the three documented shapes, and it's actually a strict improvement: scalar-valued maps (Map<String,Integer>, Map<String,Instant>, …) now respect their declared type instead of coming back as Long/Double/ZonedDateTime. No Rust touched, so the native-handle model is unchanged.

Test gaps worth closing: a scalar-leaf typed case (e.g. Map<String,Integer>) to lock in that new behaviour; empty-map / empty-inner-list / null-entry-value; and the deeper shapes noted inline (either fix or add a CHANGELOG caveat).

[emmanuel-keller]

Routing map values through the full convertValueToType recursion is the right fix. One scope caveat: the sibling convertArrayElement was left unchanged and still lacks Map/Optional/type-aware-scalar handling and reuses the outer elementType when recursing into nested arrays. So one level deeper than the fixed cases still throws on read even though ValueBuilder serializes it fine — a genuine round-trip asymmetry. Examples that still fail: Map<String,List<Map<String,String>>> and Map<String,List<List<Pojo>>>. Cleanest fix would be to have convertArrayElement delegate to convertValueToType too (descending firstTypeArgument for nested arrays), unifying both paths.

[welpie21]

Fixed in c8f5e80. Reproduced both cases first: Map<String,List<Map<String,String>>> failed with NoSuchMethodException: java.util.Map.<init>() (object elements went through convert(elementType, ...)) and Map<String,List<List<Pojo>>> with NoSuchMethodException: java.util.List.<init>() (nested arrays reused the outer elementType). In both repros create() succeeded and only the read-back conversion threw, confirming the round-trip asymmetry — the fix is read-path only.

convertArrayElement now delegates typed elements to convertValueToType, whose isArray branch descends one firstTypeArgument per level, so both recursion paths are unified at any depth (Map/Optional/Value/type-aware scalars included). When no generic element type is available (raw collections) the historical type-agnostic behaviour is kept. One deliberate side effect of the unification: typed scalar elements now hydrate with their declared element type, e.g. List<Integer> holds Integer instead of Long — covered by a test and noted in the changelog.

New coverage: MapNestedCollectionsTests#roundTripMapOfListsOfMaps, #roundTripMapOfListsOfPojoLists (POJO path) and RecordMapNestedCollectionsTests#roundTripDeeperNestingAndConcreteMapTypes (record path). Full test + recordTest suites are green.

[emmanuel-keller]

Minor (pre-existing pattern): always constructs new HashMap<>(), so a field declared as a concrete/ordered map type (TreeMap, LinkedHashMap, SortedMap) will fail on set. Also keys are always taken as String, ignoring the map's first type argument (Map<Integer,X> → String keys). Both pre-date this PR; noting since they're in the 'Map fields' scope.

[welpie21]

Addressed the map-instantiation half in c8f5e80: newMapInstance now instantiates concrete declared types (LinkedHashMap, TreeMap, ...) via their no-arg constructor and picks a matching implementation for the JDK map interfaces (SortedMap/NavigableMap → TreeMap, ConcurrentMap → ConcurrentHashMap, ConcurrentNavigableMap → ConcurrentSkipListMap); plain Map (and unknown abstractions) still fall back to HashMap. Repro before the fix: a LinkedHashMap field threw IllegalArgumentException: Can not set java.util.LinkedHashMap field ... to java.util.HashMap. Covered by MapNestedCollectionsTests#roundTripConcreteAndSortedMapFieldTypes (POJO fields) and the TreeMap record component in RecordMapNestedCollectionsTests.

I've deliberately deferred non-String keys (Map<Integer,X>): SurrealDB object keys are strings on the wire (Entry.getKey() returns String), and the write path already stringifies keys via entry.getKey().toString(), so honouring the first type argument means parsing strings back into arbitrary key types (numbers, UUIDs, enums, ...) with its own failure modes — that feels like a separate feature/PR rather than part of this fix. Happy to file an issue for it if you agree.