Proposal: remove restriction that SpanContext must be a sealed/final class

[anuraaga]

I think the spec that requires SpanContext is too limiting to language authors since it brings language concerns (class inheritance) into the cross-language spec. Languages may have a language-specific reason to allow a non-sealed SpanContext. For example, in Java, we have a need to hide the implementation of SpanContext from a user app to prevent compatibility issues between auto instrumentation and the app which without special care, can share classpath and have collisions. This can be done efficiently if SpanContext is an interface - two interfaces, one in the app, the other in the agent, but one implementation generated by the agent. Otherwise, we are stuck with two implementations, that copy between each other. In some sense, the fact that we rewrite the usage of SpanContext by a user through severe bytecode manipulation already seems to be incompliant with the spirit of this spec of wanting only one implementation of `SpanContext. This is an issue specific to Java instrumentation - I'd recommend the spec not be a blocker in creating solutions to such issues.

[Oberon00]

I would vote for making this P1 @open-telemetry/technical-committee. We need a decision here. See also linked PR #969

[andrewhsu]

from the issue triage mtg today with TC, marking this as P1 because we need to make a decision on this issue by end of day today @bogdandrutu

[yurishkuro]

I've always been +1 to have SpanContext as interface. Do we have written explanation somewhere why that would be a bad thing?

[Oberon00]

@yurishkuro See rejected OTEP open-telemetry/oteps#58

[yurishkuro]

Thanks for the link. From what I can see there, there were no convincing arguments why SpanContext as interface would be bad, aside from the ref-counting in C++ argument, which seemed to be resolved in that discussion.

[carlosalberto]

I'm fine with un-sealing it too.

[bogdandrutu]

"Unsealing" is ok as long as the contract specifies:

• TraceID - w3c definition
• SpanID - w3c definition
• etc.

One of the reason we wanted it to be "sealed" was that we don't want to deal with any random length for traceid/spanid/flags etc. And it was one of the most important thing we agreed on during the initial merging requirements between OC and OT.

[carlosalberto]

One of the reason we wanted it to be "sealed" was that we don't want to deal with any random length for traceid/spanid/flags etc.

Sounds fair to me.