Provide a public API for creating Emitter without exposing implementa…

[anuraaga]

I noticed that the SDK exposes almost all of its classes to users. For an SDK, where it's important to preserve backwards compatibility, this can make it difficult to improve on the code. An example is #145 where we want to optimize our SDK by changing the implementation of how we request rules, but we can't do so on a minor version release since we expose all of the rule APIs to users. There's a low chance they're using them in their code, but as soon as a method is public, it has to stay that way until the next major version, which cramps evolution of the SDK.

In an aim to improving by 3.0, I'd like to deprecate much of the public API surface to reduce it to only what users / instrumentation writers need. This PR is a small first step to serve as an example of what that may look like.

Let me know your thoughts on this. If it sounds like a good idea (I strongly suggest it), I'll file a tracking issue and we can maybe do a fixit at some point to knock it out.

[shengxil]

I noticed that the SDK exposes almost all of its classes to users. For an SDK, where it's important to preserve backwards compatibility, this can make it difficult to improve on the code. An example is #145 where we want to optimize our SDK by changing the implementation of how we request rules, but we can't do so on a minor version release since we expose all of the rule APIs to users. There's a low chance they're using them in their code, but as soon as a method is public, it has to stay that way until the next major version, which cramps evolution of the SDK.

In an aim to improving by 3.0, I'd like to deprecate much of the public API surface to reduce it to only what users / instrumentation writers need. This PR is a small first step to serve as an example of what that may look like.

Let me know your thoughts on this. If it sounds like a good idea (I strongly suggest it), I'll file a tracking issue and we can maybe do a fixit at some point to knock it out.

Great idea! The over exposed implementation has became obstacle of our feature development. There is another plan in 3.0 to isolate X-Ray data models (https://github.com/aws/aws-xray-sdk-java/tree/master/aws-xray-recorder-sdk-core/src/main/java/com/amazonaws/xray/entities) from the core package. Let's sync before merging this.

[anuraaga]

Added a DelegatingEmitter to replace inheritance of the implementation classes.

[shengxil]

Nice idea. Can we change the usage at https://github.com/aws/aws-xray-sdk-java/blob/master/aws-xray-recorder-sdk-core/src/main/java/com/amazonaws/xray/AWSXRayRecorder.java#L131-L135 too?

[anuraaga]

Good call thanks!