On 5/25/2016 12:22 AM, Jochen Theodorou wrote:
so in earlier mails to this list I described a bit the problems I got
into with the way Groovy produces proxies and handles default methods
for those.
Pointer? The most relevant thread I could find was "Groovy with Jigsaw"
from September 2015 but even it didn't talk much about proxies.
I would like to see how the correct solution to this is supposed to be....
so we have code like m.sortReversed{a,b -> a.value <=> b.value}, where
sortReversed is getting a Comperator and will call reversed() on it.
This is not actual API, this is just an example! So far the logic has
been, that kind of lambda {a,b -> a.value <=> b.value}, is called for
every non-default, non-static method. If we are talking about functional
interfaces, there is only one such method. The problem now arises what
we are supposed to do if a default method is called.
What is m, some collection of reflection objects for methods?
Dynamic proxies and invocation handlers won't do the job, as they do not
provide an implementation of the interface I can call the default method
on.
Is this a general limitation of j.l.r.Proxy? At first glance it doesn't
seem like you're hitting an accessibility issue due to Jigsaw.
Which means I have to use LambdaMetaFactory or maybe
MethodHandleProxies. This may solve the problem...
A second usage is for a kind of mocking. which means we have either a
map of lambdas, or a lambda which can accept any kind of argument
constellation...and now multiple non-static, non-default methods to
proxy. We did use dynamic proxies for that in the past. I do not see how
that can work with either of the three.
So runtime generated classes is the only option left? Including all the
problems with class loaders....
This doesn't jibe with your closing comments in the "Groovy with Jigsaw"
thread, where you said "We use our own class loaders in several areas,
as well as runtime generated classes. ... generating classes using a new
classloader is the standard for us."
Alex
