[weld-dev] ProxyFactory#getProxyName() question

[Laird Nelson]

On Tue, Mar 10, 2020 at 9:07 AM Matej Novotny <manovotn at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20200310/c3dcc19f/attachment.html