But BC, per initial response. I said I needed more coffee :) On Wed, Jun 14, 2017 at 8:55 AM, Simon Spero <sesunc...@gmail.com> wrote:
> Oops -I missed that the method was already generic. Need bigger > tablet/more coffee / bigger caffeine tablet > > > On Jun 14, 2017 8:46 AM, "Simon Spero" <sesunc...@gmail.com> wrote: > > On Jun 14, 2017 4:28 AM, "Benedikt Ritter" <brit...@apache.org> wrote: > > I’d like to have feedback for CLI-277 [1], especially whether it will > affect BC. Clirr is happy with this changes, to I suppose it is fine to > merge this? > > [1] https://github.com/apache/commons-cli/pull/13 < > https://github.com/apache/commons-cli/pull/13> > > > The changes look like they ought to be ok, but I need to check on > something that isn't a tablet. > > In general, going from raw to generic is easy, since the type erasure are > the same, but changing things once they are generic gets harder. As des > Rivers et. al. (2007,2017) note: > > But, also bear in mind that there are severe constraints on how a type or > method that already is generic can be compatibly evolved with respect to > its type parameters (see the tables above). So if you plan to generify an > API, remember that you only get one chance (release), to get it right. In > particular, if you change a type in an API signature from the raw type " > List" to "List<?>" or "List<Object>", you will be locked into that > decision. The moral is that generifying an existing API is something that > should be considered from the perspective of the API as a whole rather than > piecemeal on a method-by-method or class-by-class basis. > > > https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Turning_ > non-generic_types_and_methods_into_generic_ones > > These guidelines are one of the best reference sources for information on > compatibility. Definitely more comprehensible than the JLS. > > >
