Operators inner classes' Scannable#name is always "s"

[bsideup]

Reproducer:

assertThat(Scannable.from(Operators.emptySubscription()).name()).isEqualsTo("empty")

[simonbasle]

It would be fairly easy to fix by overriding the stepName() method of such classes.

[ericbottard]

Apart from the obvious fix via the override, isn't weird that the current heuristic uses the enclosing class name rather than the enclosed one?

		String name = toString();
		if (name.contains("@") && name.contains("$")) {
			name = name
				.substring(0, name.indexOf('$'))
				.substring(name.lastIndexOf('.') + 1);
		}
		String stripped = OPERATOR_NAME_UNRELATED_WORDS_PATTERN
			.matcher(name)
			.replaceAll("");

		if (!stripped.isEmpty()) {
			return stripped.substring(0, 1).toLowerCase() + stripped.substring(1);
		}
		return stripped;

First of all, it does special treatment iff we're dealing with a non-overridden toString() AND it's an inner class. Why not detect non-customized toString() in all cases?

Also, InnerConsumer has a copy-paste of this code but using getClass().getSimpleName(). Thus, the presence of @ in the resulting string is unlikely to happen.

Lastly, shouldn't Subscription be part of the replacing regex?

[ericbottard]

See also #2547

[simonbasle]

I think we can remove the special case for InnerConsumer by using getClass().getName() in Scannable directly rather than toString(). We'd then accommodate for stripping package and then removing the keywords most likely found in base class. This would effectively also fix #2547.

For the s aspect, ie inner Scannable classes defined inside a util parent class like Operators, the fix is to have these explicitly define stepName with a meaningful human readable value.

This includes:

• Scannable.Attr.NULL_SCAN
• Scannable.Attr.UNAVAILABLE_SCAN
• Operators.EmptySubscription
• Operators.CancelledSubscription
• Operators.ScalarSubscription