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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
