10

Guava README says that @Beta or deprecated that CAN be changed, removed etc. It does not say clearly whether all remaining classes are binary compatible with previous versions (or I misread it). Although I have feeling that it is backwards compatible when not stated otherwise.

My concern is that some other library might work against new guava version (and compile as well). But it also might rely on some buggy behavior that new version might have changed/fixed which cannot be detected easily. Can I safely upgrade?

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
Rumca
  • 1,809
  • 12
  • 17

2 Answers2

21

I've prepared backward compatibility report for the Guava library versions here: http://abi-laboratory.pro/java/tracker/timeline/guava/

The report is generated by the japi-compliance-checker and japi-tracker tools.

enter image description here

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
8

We have steadfastly maintained binary and source compatibility for all non-@Beta APIs with every release, with the exception of removing methods that had been deprecated at least 18 months already.

We will continue this standard, although we are starting to acknowledge the possibility that the JDK 8 transition will give us unprecedented challenges in this regard, and it is possible we may be forced into a slightly-incompatible upgrade event in the future. I continue to hope it won't be necessary.

Kevin Bourrillion
  • 40,336
  • 12
  • 74
  • 87
  • 3
    why guava decides to remove methods remove deprecated `methods` ? even JDK don't do that. what is driving to this decision making ? – zinking Apr 28 '17 at 07:44