Hello, first and foremost, these are purely internal mechanics. There is no guarantee in CDI spec or Weld docs on how the proxies should look like. Or even on the proxies being identical from one run to another, they are an abstraction that is hidden for the most part and can be unwrapped if needed. So, looking at the method, the "middle" part of the name seems to be good, there is sorting done. See https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... What seems to be inconsistent is the proxy prefix - the package. The set in TypeInfo isn't sorted anyhow. However, within one application run, I don't think you can realistically end up having two proxies for the same bean, since you can hardly invoke this method for the same bean and pass it its bean type set ordered differently. That being said, sorting wouldn't hurt. For proxy purposes, it doesn't really matter if the proxy will be "java.io.Cloneable$Serializable$$Proxy$" or "java.lang.Cloneable$Serializable$$Proxy$". The code path that doesn't produce this is when you use a bean class (non-Object) and instead of type closure use empty set. In such case, it would leave out the second dollar sign, at least from what I gathered. I don't think there is a strong argument for having one/two dollar signs but consistency is a nice behavioral pattern to stick with so we could align that. I cannot really imagine a justification for having different number of dollar signs for proxies with certain type set. Last but not least, this class (ProxyFactory) is mostly used for subclasses used for interceptor/decorator logic, there could be something similar in ClientProxyFactory which is what handles actual bean proxies. If you want, go ahead and create a Weld issue so this doesn't get forgotten again :) Regards Matej ----- Original Message ----- > From: "Laird Nelson" <ljnelson(a)gmail.com&gt; > To: weld-dev(a)lists.jboss.org > Sent: Sunday, March 8, 2020 6:41:57 AM > Subject: [weld-dev] ProxyFactory#getProxyName() question > > Hello; it's me again, deep/close reading ProxyFactory.java to understand > everything I can about proxies in Weld. > > > For example, in a test that I wrote to further understand how proxy names are > constructed: > > > > > final Method getProxyName = > ProxyFactory.class.getDeclaredMethod("getProxyName", String.class, > Class.class, Set.class, Bean.class); > getProxyName.setAccessible(true); > final Set<Type> typeSet = new LinkedHashSet<>(); > > > > // Let's add two disparate interfaces in an arbitrary, but predictable, > 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); // ?! > Whoa. Not what I expected. > > > And are the double dollar signs ( $$ ) in this case intentional as well? > (There are certainly paths through this method that won't result in double > dollar signs, so I'm not sure if this is a bug or a feature.) To my eyes, > this is suspicious: > https://github.com/weld/core/blob/10a1d11af8c815a2a4a8fc5a4061698215e602b... > Shouldn't that happen only if there aren't any more interface names to add? > So are the two dollar signs just a symptom of a bug? > > By contrast, in case it matters, my naïve expectation, following what seems > to me the intended logic of the method, would have been for proxyName to > contain " java.lang.Cloneable$Serializable$Proxy$ ". > > Best, > Laird > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

On Tue, Mar 10, 2020 at 11:14 AM Laird Nelson <ljnelson(a)gmail.com&gt; wrote: (Just a quick correction: org.jboss.weld.io.Cloneable$Serializable$$Proxy$_$$_Weld$Proxy$.) Best, Laird

Thanks. Few more comments. The reason the package is changed is because Java forbids you to define new classes (even if you hack into CL) into any package starting with "java.*". Hence we detect those and replace "java" with "org.jboss.weld". Apparently this also affects "javax" prefixes since "javax" contains "java" substring. Not sure if this is intended or needed but it will soon vanish since we will live in a Jakarta world ;-) The "getProxyName()" method returns what we would consider a working proxy name. The fact that we change the package later is due to java limitations. It's true that it could probably reside in one method, but there is not much harm done in this I suppose. Also notably, if you operate on proxies from classes in user applications, you will end up with much more "natural" proxy class names. E.g. even without the sorting most beans have some sort of type closure that is several types deep but linear (as opposed to serializable and cloneable having nothing in common). With that the proxy will look more sensibly. You also won't need to replace package names as any class coming from user app will be legit (of course they can still have producers on java.* types though). Still, your example is a good one as it demonstrates the inconsistency that can happen :) Matej ----- Original Message -----