In fact, changing the return type does break binary compatibility (binary compatibility is different from source compatibility), since the return type of a method is part of is java signature. This means that if someone would want to use the new jar (with changed return type) as a drop-in replacement, without recompiling anything else, the code would not execute (without NoSuchMethodError thrown).
There are already been similar issues here at commons: http://apache-commons.680414.n4.nabble.com/io-LockableFileWriter-close-ignores-exceptional-return-value-of-java-io-File-delete-td3795977.html http://mail-archives.apache.org/mod_mbox/commons-dev/201112.mbox/%3CCAOGo0VbVZCPqQeFR=xdu8fh+goecnovee9xkh5cooofojbm...@mail.gmail.com%3E HTH, Regards, Julien 2012/7/9 Benedikt Ritter <[email protected]> > Hi Sebastien, > > have a look at: > > http://wiki.eclipse.org/Evolving_Java-based_APIs > http://wiki.eclipse.org/Evolving_Java-based_APIs_2 > http://wiki.eclipse.org/Evolving_Java-based_APIs_3 > > In section Evolving API classes - API methods and constructors it says: > Change result type (including void) - Breaks compatibility > > Can anyone verify that? > > Regards, > Benedikt > > 2012/7/9 Sébastien Brisard <[email protected]>: > > All, > > in Commons-Math, class RealVector has a method unitize() which divides > > each component of this by the norm. The vector is changed in place. > > The current signature of this method is > > public void unitize() > > > > Most methods in class RealVector implement a fluent API. I would like > > unitize() to follow the same paradigm. In other words, I would like to > > change the signature to > > public RealVector unitize() > > this method now returning this. > > > > Question is: does this break binary compatibility? Although clirr > > reports an error, I fail to see how this change can cause any problem. > > > > Thanks in advance for your advice, > > Sébastien > > > > > > --------------------------------------------------------------------- > > 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] > >
