(I created this issue partially at the request of Matej Novotny: https://lists.jboss.org/pipermail/weld-dev/2020-March/003768.html) This is a minor bug with no practical impact but I wanted to capture it so it doesn't get lost. The getProxyName() method can produce different proxy names for the same inputs. This is due in part to the fact that Proxies.TypeInfo does not sort its Set instances. In addition, the getProxyName() method does not actually produce the final proxy name that is used. The getProxyClass() method adds additional computation. The net result is that this kind of thing produces slightly bizarre proxy names:
final Method getProxyName =
ProxyFactory.class.getDeclaredMethod("getProxyName", String.class,
Class.class, Set.class, Bean.class);
getProxyName.setAccessible(true);
final Set<Type> typeSet = new LinkedHashSet<>();
order.
typeSet.add(Serializable.class);
typeSet.add(Cloneable.class);
final String proxyName = (String)getProxyName.invoke(null, null,
Object.class, typeSet, null);
assertEquals("java.io.Cloneable$Serializable$$Proxy$", proxyName);
(The actual proxy name used in this case is further computed by the getProxyClass() method and so will be, in fact, if I'm reading the code right, org.jboss.weld.io.Cloneable$Serializable$$Proxy$_$$_Weld$Proxy$. It's also worth noting that if I were proxying something starting with javax, the package prefix would be org.jboss.weldx.) Additionally, I believe that the first occurrence of $$ above is a mistake due to there not being any checking for the last iteration of this loop: https://github.com/weld/core/blob/10a1d11af8c815a2a4a8fc5a4061698215e602b0/impl/src/main/java/org/jboss/weld/bean/proxy/ProxyFactory.java#L283 I'm fully aware these are opaque internal constructs that users shouldn't have to care about; the background is only that I'm doing close code reading and trying to understand as fully as I can how proxies work. This name computation confused me. |