API的非向后兼容性无论如何通常代表着一种比较差的设计

不管一个类库或者工具方法实现多么的好，如果无法做到向后兼容性，通常会给用户带来很大的升级成本，很多对此的依赖如果希望在后续的升级和维护期间使用该类库的其他新增特性或者好处，将不得不推迟升级亦或是被迫接受改变。

无论这个类库实现的多么完美或者流行，如果版本升级意味着大量API或者包名的变更，我认为很大程度上是因为设计者意识到从维护的角度来说，这个类库的实现非常的糟糕，以至于已经非常的难以维护下去了。

在开源的社区，做这种变更或者说犯这种错几乎不需要付出任何成本，所以很多的类库甚至非常流行的类库都有发生大版本间API的完全重构，如果是商业类库，除非有适配API，恐怕用户都跑光了。常见的类库有如下：

jackson：

1.x：org.codehaus.jackson

2.x：com.fasterxml.jackson

由此带来的是大量类路劲的变化，spring HttpMessageConverter针对1.x和2.x的分别实现；到了spring 4.x，MappingJacksonHttpMessageConverter又被spring给删除了。

dbcp：

1.x：

2.x：

apache.common.lang：

2.x：

3.x：

log4j ：

1.x：

2.x：

common.pool

1.x：

2.x：

netty：

4.x：

3.x：

不过主流的容器和应用服务器以及数据库则做的好的多，比如tomcat/nginx/mysql/postgresql/rabbitmq。