K
Karsten Wutzke
Hello!
I looked at the dynamic proxy classes the JDK has to offer
(java.lang.reflect.Proxy and jlr.InvocationHandler etc.). The setup
with the generated proxy calling on the InvocationHandler via
reflection looks nice at first. However, I wonder what the advantages
of this approach are.
The generated proxy forwards all method calls to the invocation
handler. Like that not every method of the proxy's super interface/s
has/have to be implemented as with "standard" (self coded) proxies.
When implementing the invocation handler concrete class'
Object invoke(Object proxy, Method method, Object[] args)
method you get one method in which you have to (likely) implement all
method bodies anyway. Additionally, you have to do this in/with some
if or switch statement (which method got called?)
if ( method.getName().equals("getBla") )
{
}
else if ( method.getName().equals("setBle") )
{
}
and so on. Furthermore you need (ugly and probably unnecessary)
downcasts from Object (e.g. to get the parameters). I also don't like
the required interfaces thing with the generated proxies (I use many
abstract classes with common implementations).
So what's the advantage here? Why should anyone use those classes
instead of their own? (please note I won't be using RMI)
Were those classes just a step for improving the RMI API
implementation?
Karsten
I looked at the dynamic proxy classes the JDK has to offer
(java.lang.reflect.Proxy and jlr.InvocationHandler etc.). The setup
with the generated proxy calling on the InvocationHandler via
reflection looks nice at first. However, I wonder what the advantages
of this approach are.
The generated proxy forwards all method calls to the invocation
handler. Like that not every method of the proxy's super interface/s
has/have to be implemented as with "standard" (self coded) proxies.
When implementing the invocation handler concrete class'
Object invoke(Object proxy, Method method, Object[] args)
method you get one method in which you have to (likely) implement all
method bodies anyway. Additionally, you have to do this in/with some
if or switch statement (which method got called?)
if ( method.getName().equals("getBla") )
{
}
else if ( method.getName().equals("setBle") )
{
}
and so on. Furthermore you need (ugly and probably unnecessary)
downcasts from Object (e.g. to get the parameters). I also don't like
the required interfaces thing with the generated proxies (I use many
abstract classes with common implementations).
So what's the advantage here? Why should anyone use those classes
instead of their own? (please note I won't be using RMI)
Were those classes just a step for improving the RMI API
implementation?
Karsten