Extending map leads to either complicated eq/hashCode or potential for masking fields. This was caught downstream where the "geo" field in ResourceRecordSet was masked by an identical key in the map. Most predictable solution is to not extend map on statically defined types.
The only exception is rdata. rdata is wide open and we only have java classes for a small number of types. Until we enforce a supported subset, using Map to back rdata is still a valid compromise. That said, it implies the cost of test code to ensure map and java objects are equiv (entries == field values).
Extending map leads to either complicated eq/hashCode or potential for masking fields. This was caught downstream where the "geo" field in ResourceRecordSet was masked by an identical key in the map. Most predictable solution is to not extend map on statically defined types.
The only exception is rdata. rdata is wide open and we only have java classes for a small number of types. Until we enforce a supported subset, using Map to back rdata is still a valid compromise. That said, it implies the cost of test code to ensure map and java objects are equiv (entries == field values).