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.
Yep; I completely understand. (That's why I'm writing on the weld-dev list instead of the cdi-dev list.)
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/weld/bean/proxy/ProxyFactory.java#L280
Right; if I implement Cloneable and Serializable, their simple names are sorted so that Cloneable comes before Serializable. (They aren't sorted on their full type names; if they were then Serializable would come first.)
What seems to be inconsistent is the proxy prefix - the package. The set in TypeInfo isn't sorted anyhow.
That's right. The package is computed before the simple class names are sorted.
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.
And that's fine; I'm just trying to understand the code.
> proxyName contains " java.io.Cloneable$Serializable$$Proxy$ ". Is that by
> design? Or is the " java.io.Cloneable " part a mistake?
For proxy purposes, it doesn't really matter if the proxy will be "java.io.Cloneable$Serializable$$Proxy$" or "java.lang.Cloneable$Serializable$$Proxy$".
I agree that the name is internal and no one should care. I care only because I am working to understand everything about proxies that I can in Weld.
> 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.)
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.
Right; I think there's just a missing "if (iterator.hasNext())" in there somewhere. No problem, just wanted to know if this was intentional or a small oversight. It looks like it wasn't intentional and it just doesn't matter very much.
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.
Right; me neither.
I think it's also worth pointing out that the proxy name is not actually finished when this method completes.
So the final proxy class name in this case would be org.jboss.weld.io.Serializable$$Cloneable$Proxy$_$$_Weld$Proxy$.
(Also somewhat weirdly, something starting with javax would get turned into org.jboss.weldx.)
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.
Yep; haven't gotten that far in my code reading yet. :-)
If you want, go ahead and create a Weld issue so this doesn't get forgotten again :)
OK; sure.
I think my own personal takeaway from all this is:
- A best effort is made to make proxy names unique.
- Proxy names are opaque and their format can obviously change at any time since they aren't specified by the CDI specification.
- Proxy names are (as of this writing) not deterministic since TypeInfo constructs are not sorted.
- There isn't really a lot of logic around what all the dollar signs mean (sometimes they're doubled, sometimes they're not; they just sort of separate things in the otherwise opaque name).
Best,
Laird