commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Aymé <julien.a...@gmail.com>
Subject Re: [all] Does this break binary compatibility?
Date Mon, 09 Jul 2012 07:49:43 GMT
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+GoEcnovEe9XKh5CooofOjBMUwg@mail.gmail.com%3E


HTH,
Regards,
Julien

2012/7/9 Benedikt Ritter <beneritter@gmail.com>

> 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 <sebastien.brisard@m4x.org>:
> > 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: 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message