1:14 p.m.
On Tue, Mar 10, 2020 at 9:07 AM Matej Novotny <manovotn(a)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/wel...
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/10a1d11af8c815a2a4a8fc5a4061698215e602b...
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