commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <>
Subject Re: [proxy] Moving Proxy to Commons Proper
Date Wed, 19 Oct 2005 14:35:56 GMT
On 10/19/05, James Carman <> wrote:
> > i would also like to reiterate stephen's warning: if you use interfaces,
> > be very sure that you are not going to need to change them in any
> > fashion. i would very strongly suggest implementing the key
> > ProxyFactory logical interface as an abstract class. this isn't bias (i
> > love interfaces when coding applications) but a hard lesson painfully
> > learnt.
> Robert,
> I understand the concerns here, but I am really torn between changing the
> API and leaving it like it is.  IMHO, it is *very* unlikely that a user of
> Commons Proxy is even going to implement ProxyFactory on their own.  If I
> had to ballpark it, I would be surprised if 1 out of every 100 (I might even
> go 1000) people who use Commons Proxy implement ProxyFactory.  That's the
> whole point of using Commons Proxy in the first place.  You don't have to
> write the proxying logic yourself!  So, what is our target here?  Are we
> looking for 100% backward compatibility with *all* projects?  Or, are we
> happy with keeping something more like 90% or 95% of our users happy?  Maybe
> we could tell them in the documentation that if they have a proxying
> technology that they wish Commons Proxy supported that they can submit a
> request to the mailing list or into Bugzilla for it and we can take care of
> it (of course, any code that gets us going would help).  As long as we
> decide between AOP Alliance vs. "rolling our own" interfaces, I'm pretty
> happy with the ProxyFactory interface.  Besides, there's really nothing you
> can't do with Invokers.  That's sort of the "common denominator."

In Eclipse APIs it is common practice that interfaces are never
changed -- hence new interfaces have to be added when new changes are
required -- and abstract classes are used where changes (in form of
new methods) are expected (see

As you say the Invokers are the "common denominator". So ProxyFactory
could be implemented as an abstract base class with the
createInvokerProxy() method declared as abstract and the other proxy
factory methods defined in terms of that. Concrete implementaions
would although do best in overriding these other methods for
performance reasons.

Although, as you say, there are probably not many users who will want
to implement this interface anyways. So maybe it's best left as it is.

I'm torn on this one. Any other thoughs?


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

View raw message