Java is commonly known to be a very backwards compatible language. While the language itself has seen major changes over the years, almost all the changes have been additions to the language, while still retaining the functionality of the older versions. Let's say you picked up a Java codebase written with Java 1.3 and you compiled and ran it with Java 8. Would you be surprised if it ran without issues? Probably not! That's precisely because of the reputation Java has of being backward compatible. And it's a great thing in my opinion, because it gives adopters the confidence that there's not a lot of effort and rewrites required for every major upgrade. This is an aspect where Java has an edge over a few other development platforms.

This backward compatibility comes with a cost, especially when you consider the lack of encapsulation of internal APIs. What if there is an internal API that developers have inadvertently used because of the lack of encapsulation? To maintain backward compatibility, the language team is compelled to not make breaking changes to those internal APIs even though they are, by definition, internal. So, the burden of backward compatibility gets worse for the language--not only do public APIs have to be backward compatible, even the internal runtime classes need to be as well!