OpenTelemetry.getTracer(...) differs from API spec

[MariusVolkhart]

Describe the bug
The OpenTelemetry.getTracer(...) family of methods claim to reject a null library name. The spec for obtaining a tracer indicates that invalid names such as null and empty string should lead to a default value.

This behavior (returning a default) is found when only the API is on the classpath, but the SDK rejects null and throws an exception.

Steps to reproduce

OpenTelemetry.getGlobalTracer(null);
OpenTelemetrySdk.get().getTracer(null);

What did you expect to see?
I don't know what the right answer is, but it's odd to me that the API silently allows null (but documents it as invalid), while the SDK throws on null, and the spec suggests null should be silently handled.

What version and what artifacts are you using?
Artifacts: opentelemetry-api, opentelemetry-sdk
Version: v0.9.1, 0.10.0-SNAPSHOT

[dengliming]

What about adding an overloaded method like:

default Tracer getTracer() {
    return DefaultTracer.getInstance();
  }

and we don't need to check the null library name.

[anuraaga]

I like the idea of providing an API to get a tracer without a name, but FWIU, the spec is talking about it but hasn't really come to a conclusion on whether we should proceed with it or not.

open-telemetry/opentelemetry-specification#586

Either way, we would still have the methods that accept string and may be passed null, so in the meantime I think we should fix the bug where the SDK is throwing an exception on null, it should return a tracer with either an empty string name or a name like "default" if an empty string name isn't allowed, not sure off the top of head.