commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [net] binary compatibility be damned
Date Fri, 15 Apr 2011 17:11:08 GMT
If your are going to break binary compatibility then a major release
is the time to do it. Is there any question that the design is wrong?


On Apr 15, 2011, at 10:49, "Daniel F. Savarese" <> wrote:

> Prior to the 3.0 release, I'm trying to review recent code changes and
> test the code in what little spare time I have available.  I noticed that
> ProtocolCommandSupport __commandSupport was moved into SocketClient.
> I disagree with this change.  SocketClient isn't meant to serve only
> Commons Net classes, nor is it meant only for implementing clients for
> IETF protocols; and only a limited number of clients actually need
> to use ProtocolCommandSupport.  Having a private member variable that is
> initially null that must be initialized outside of the base class via calling
> createCommandSupport to initialize is fragile.  That's what constructors
> are for.  Even though Java doesn't have destructors, avoiding initialization
> protocols and using RAII is still a good rule of thumb for resource creation.
> A more robust and flexible separation of concerns would place the
> ProtocolCommandSupport member in a ProtocolClient abstract class that
> subclasses SocketClient and initializes __commandSupport (which should
> be protected, not private, obviating the need for getCommandSupport())
> in its constructor.  Then the protocol clients that require
> ProtocolCommandSupport can be changed to subclass ProtocolCommandSupport.
> That won't break compilation of any user code, but breaks binary compatibility.
> Emphasizing binary compatibility at the expense of design doesn't make sense
> to me.  Commons Net is enough of a Rube-Goldberg machine as it is.
> Is there some overriding reason why binary compatibility absolutely must
> be maintained or may I open an issue and make the above change?
> daniel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message