commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject [proxy] Proxy & Generics...
Date Sun, 06 Apr 2008 12:09:37 GMT
I have created a branch to start working on a genericized Proxy API.
However, I'm running into an issue that I'm not quite sure how I
should deal with.  I want to make the methods on ProxyFactory use the
varargs language feature.  For example:

public Object createDelegatorProxy( ObjectProvider delegateProvider,
Class... proxyClasses );

However, I also want to add in a nice helper method like this:

public <T> T createDelegatorProxy( ObjectProvider<T> delegateProvider,
Class<T> proxyClass );

Now, it's advised to not override varargs methods, but this is a
special case.  It doesn't really matter which version the compiler
picks.  The second method's implementation merely delegates to the
first method.  It's "syntactic sugar."  So, if I want to do this in my

Echo echo = proxyFactory.createDelegatorProxy(echoProvider, Echo.class);

Then, I won't have to do any casting at all since I'm using the
single-class version of the method.  However, if I add another class:

Echo echo = proxyFactory.createDelegatorProxy(echoProvider,
Echo.class, Serializable.class);

This won't compile.  You need to cast the return type.

It looks like implementing it this way is actually o.k. as far as the
compiler is concerned, but I just wanted to get some input from some
other folks.  Should I just leave the method names the same and folks
who use just a single class instance get the type safety for free?
Or, do you guys see some ambiguity here that folks might not


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message