Consider reverting/amending #1534 (removes fallback tracer name)

[jkwatson]

#1534 changed the spec to require null tracer names to be kept intact. Unfortunately, this ends up introducing a pretty significant behavioral breaking change to the Java SDK interfaces for exporters. It would require our InstrumentationLibraryInfo to return a nullable name attribute, which means that all exporters (both ours and any 3rd party) now have to guard against a null attribute, or risk throwing NullPointerExceptions in the exporter.

See this Java PR for the impact within the java repository itself: open-telemetry/opentelemetry-java#3153

I think that we should amend this part of the specification to note that nulls should be converted into empty strings, or we should revert that change and specify an actual fallback value.

[Oberon00]

The requirement in question is a SHOULD-requirement. So if Java has good reasons to deviate (slightly), I think it is fine to do so with the current spec.

[tedsuo]

It looks like this issue is caused by an unnecessary side effect in the PR. The original issue was to define a canonical tracer name when an invalid name is given. Returning the original invalid name of the tracer seems like incorrect behavior - we should return the default name, and log the error.

[carlosalberto]

cc @bogdandrutu

[ghost]

Reading the spec (In case an invalid name (null or empty string)) I believe that what we can do in Java, in order to avoid all of the extra null-checks is:

• check if the name is valid (non-empty string)
• if it's null, use an empty string (as a fallback)
  This way both backend will be aware that the name provided was invalid and the code won't need to be null-protected.

[carlosalberto]

After discussing it in today's SIG call, we decided to go with an empty string instead of null and log the error. Assigning this issue to me, and will present a PR with the aforementioned changes.