commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [proxy] Changing the API to an interface (AGAIN)...
Date Thu, 15 Jul 2010 03:12:09 GMT

On Jul 14, 2010, at 9:21 PM, James Carman wrote:

> All,
>
> One of the biggest complaints I've received from folks about the proxy
> library is that it's not based on interfaces.

What is the typical basis of a complaint?  I.e., what problem does  
the abstract class cause?

> The main class is the
> ProxyFactory class and it's a concrete class which implements all
> proxying logic using JDK proxies.  We did this for maintainability
> (adding stuff to the interface breaks binary compatibility as opposed
> to adding a method to a concrete superclass with an implementation).
> I would like to re-structure proxy so that it contains a few
> modules...
>
> 1.  Commons Proxy Core - the API itself containing the ProxyFactory  
> *interface*
> 2.  Commons Proxy JDK - the JDK proxies implementation
> 3.  Commons Proxy CGLIB - the CGLIB implementation
> 4.  Commons Proxy Javassist - the Javassist Library
>
> With the new paradigm of just bumping major version numbers (and
> package names) allowing us to break compatibility, I don't think the
> interface issue is that much of an issue anymore.  What do you guys
> think?

I personally don't feel strongly about the interface vs. abstract  
class issue; I can understand both sides of the debate.  I am curious  
as to the nature of folks' dissatisfactions with the abstract class  
approach, however.  I do take your point regarding package renaming  
allowing the expansion of an interface without having to version  
interfaces e.g. ProxyFactory2, ProxyFactory3, etc...

I would support [proxy] becoming a multi-module project; among other  
things we could selectively have a larger set of dependencies this  
way.  How would you feel about the module that contains the recording  
functionality depending on [lang] 3.x for type utilities?

-Matt

>
> Thanks,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message