Skip to content

StringEncoder javadoc documents the wrong implementation priority order #8620

Description

@thswlsqls

Describe the bug

The StringEncoder interface javadoc documents the implementation priority order as VarHandle → Unsafe → Fallback, but getInstance() selects them in the opposite order.

Steps to reproduce

Read the StringEncoder javadoc, then follow getInstance() to StringEncoderHolder.createInstance().

What did you expect to see?

The documented priority order matching the code that the javadoc points at.

What did you see instead?

StringEncoderHolder.createInstance() (line 62) tries UnsafeStringEncoder first — its inline comment says "so try it first" because Unsafe is faster. VarHandleStringEncoder is only tried afterwards.

It is wrong in the other branch too: proactivelyAvoidUnsafe() (line 90) skips Unsafe entirely on Java 23+, or when the version cannot be parsed, so Unsafe is never the documented second choice.

Both files came from #7701, so the javadoc has been inaccurate since it was added.

What version and what artifacts are you using?

Artifacts: opentelemetry-exporter-common
Version: main @ 63ebd94
How did you reference these artifacts? N/A — reading source.

Environment

Compiler: Temurin 21
OS: N/A

Additional context

Javadoc only; no runtime behavior is affected. Related: #7701

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions