Introduce ProxyHints.registerJdkProxy(String...)

[sbrannen]

Since users might not have a concrete need to work with TypeReference, we should introduce ProxyHints.registerJdkProxy(String...) to simplify use of the API for registering a dynamic proxy based on fully qualified class names of the required interfaces.

[snicoll]

I don't think we should do this. If we do, then every place that accepts a TypeReference must add a String variant, and I don't think that we should do that either as it would bloat the API quite a bit.

If you don't have a class handy, then a TypeReference is the way to go.

[sbrannen]

I had already implemented the feature and committed it before I saw your comments, so I'm reopening this issue to discuss the topic within the team.

I don't think we should do this. If we do, then every place that accepts a TypeReference must add a String variant, and I don't think that we should do that either as it would bloat the API quite a bit.

If you don't have a class handy, then a TypeReference is the way to go.

I'd argue that TypeReference is more of an internal implementation detail that normal users need not be bothered with.

There may be some particular use cases where normal users need to work with TypeReference, but for the most common use cases users will be happier with supplying a Class or String. Furthermore, supporting String will remove lots of superfluous TypeReference.of(<string>) occurrences within user code.

Playing devil's advocate... we don't require users to supply a TypeReference for a Class, so why should we require them to supply a TypeReference for a String?

As a concrete example, this issue was a requirement for #28745 to improve the developer experience. The newly introduced AopProxyUtils.completeJdkProxyInterfaces(*) methods could of course be refactored to return TypeReference[] instead of Class<?>[] and String[], but that seemed unnatural and unnecessary.