A different new strategy for interop with OpenTelemetry API brought by application

[trask]

If the OpenTelemetry API exposed primarily interfaces, I think we could provide implementations of those interfaces that implement both the application's (unshaded) OpenTelemetry API and the agent's (shaded) OpenTelemetry API at the same time.

This doesn't get rid of the shading, but I think it would eliminate the need to bridge back and forth.

[bogdandrutu]

If the OpenTelemetry API exposed primarily interfaces, I think we could provide implementations of those interfaces that implement both the application's (unshaded) OpenTelemetry API and the agent's (shaded) OpenTelemetry API at the same time.

This will lead in duplicate code anyway, I probably don't have too much experience with the complexity of the bridge but you still need to build a bridge or duplicate the entire SDK.

Let's get as an example a TraceId interface:

• api.TraceId - interface
• shadeApi.TraceId - shaded api.TraceId interface
• sdk.TraceId - implementation

When the sdk generates a new "sdk.TraceID" you need to do the same bridge as today to ensure that it also implements the api.TraceId and shadeApi.TraceId. I don't see (probably I am wrong) how this will benefit

[trask]

This will lead in duplicate code anyway, I probably don't have too much experience with the complexity of the bridge but you still need to build a bridge or duplicate the entire SDK part.

The win here is performance, not code complexity.

In your example

• api.TraceId - interface
• shadeApi.TraceId - shaded api.TraceId interface

We would write our own TraceIdImpl that implements both api.TraceId and shadedApi.TraceId.

Then we would hijack the factory method that people use to instantiate api.TraceId, and return our TraceIdImpl.

And then we don't need to bridge TraceIdImpl back and forth, since it implements both sides(!)

[bogdandrutu]

@trask I cannot see how that happens, because that is inside the SDK where we create the TraceID (some custom IDGenerator for example), so most likely you cannot access that code unless you do bytecode manipulation, but that is something that the SDK will not guarantee to be backwards compatible (we can change the code where we generate the ids).

[trask]

We will instrument TraceIds.create() (or whatever factory method the API/SDK provides to create a TraceId)

[bogdandrutu]

My point is that, there are a lot of places where we will create objects that implement different interfaces (probably not using factories etc.) and will be hard to bytecode change things in a way to return the new objects, so you will end up re-writing the entire SDK (my concern).

You most likely need also SDK to define factories for all the interfaces and allow configuring all of them to achieve that.

[bogdandrutu]

We will instrument TraceIds.create() (or whatever factory method the API/SDK provides to create a TraceId)

Once TraceID is an interface I can write code:
return new TraceID {
...
}

I don't need to always go via a factory method

[trask]

You most likely need also SDK to define factories for all the interfaces

Ya, the requirements for this to work are

• interface
• don't expose the impl class (factory method that we can instrument and return our own impl)

Once TraceID is an interface I can write code:
return new TraceID {
...
}

I don't need to always go via a factory method

Yeah, I wish we could prevent this, we'll still have bridge this back and forth, but at least we win when people use the normal APIs.

...

Oh! Maybe we can win without relying on instrumenting the factory method! We can hijack the api.TraceId and make it extend the shadedApi.TraceId (in this case at least, since it only expose standard Java types)

[bogdandrutu]

I think we should try this before making too many changes in the API

[trask]

👍

Dropping TraceId and SpanId classes, replacing them with String inside of SpanContext seems to be independent discussion though?

[bogdandrutu]

Yes but I saw a lot of other changes to make things interfaces based on this assumption. Also it may influence if SC is a final class or interface