Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan by dougqh · Pull Request #10472

Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan by dougqh · Pull Request #10472 · DataDog/dd-trace-java

added 16 commits

January 12, 2026 14:33

EntryIterator and EntryChangeIterator are arguably redundant

Fixed bug TagValueConversions.toBoolean
Could cause LegacyTagMap.EntryReader to produce incorrect answers to some queries

For simplicity, now treating Byte and Short as Integer.  That will make calling code doing primitive handling simpler.

Fleshing out tests -- more tests to come

Coverage for byte, short, float, and double

Adding methods to AgentSpan / DDSpan that take TagMap.Entry/Reader objects directly

This will enable TagMap.Entry reuse which can reduce memory allocation/GC pressure

Methods are intended to be used to create TagMap.Entry objects for repeatedly used values

Overloads are provided for all the supported types to be easier for developers not familiar with TagMap internals.  Internally, TagMap still uses the more explicit new<X>Entry methods.

Removing statics that were previously moved to TagValueConversions

- tests exposed missing TagMap.Entry.create for boolean
- added explanatory strings to some asserts

This was referenced

Feb 2, 2026

Co-authored-by: Alexey Kuznetsov <alexey.kuznetsov@datadoghq.com>

Using DisplayName to improve readability instead of separating prefix / suffix with underscore

- setMetric not guards against null
- TagMap.create now allows null - and returns null in response

The intention is to let null values benignly flow through TagMap.Entry.create into AgentSpan.setTag / setMetric

Fixing oversight of creating newAnyEntry rather newObjectEntry in create(tag, CharSequence)

Changed tests to use camel case - using DisplayName for test report readabilty

…aDog/dd-trace-java into dougqh/fdirect-apis-for-tagmap-entry

dougqh deleted the dougqh/fdirect-apis-for-tagmap-entry branch

February 5, 2026 20:32