On Tue, Mar 10, 2020 at 9:07 AM Matej Novotny <manov...@redhat.com> wrote:
> 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 once we end up with java.io.Cloneable$Serializable$$Proxy$, that gets passed to getProxyClass() and this comes into play: https://github.com/weld/core/blob/10a1d11af8c815a2a4a8fc5a4061698215e602b0/impl/src/main/java/org/jboss/weld/bean/proxy/ProxyFactory.java#L353-L360 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
_______________________________________________ weld-dev mailing list weld-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev