ScienceOfAPIDesign

From APIDesign

Revision as of 09:25, 10 October 2020

This post contains reflections on BinaryCompatibleDefaultMethods article.

On Being too Demanding and Policies

I have a mathematical background. I am interested in APIDesign from a point of provably correct evolution. My APIDesignPatterns aim at 100% BackwardCompatible evolution - e.g. even if one knows what will happen in the future, one can't write a program that breaks.

This may be a bit too demanding, but that's how science works. It is supposed to be sharp, predictable, provide clear answers. The ideal science of all times is geometry. All other human attempts to create a science mimic the principles, axioms and style of Euclides geometry. Some get closer (Newton's dynamic) some don't (medicine, social sciences, etc.).

I am not a behavioral scientist. Discussing whether keeping 100% compatibility at a particular situation or not is a matter of policy. Setting up policies is a social process and it is not a task for outsiders, but for decision makers. I am not in a position to propose policies for the OpenJDK project and as such I decided to avoid such discussion in the BinaryCompatibleDefaultMethods post.

Overall I prefer to not make incompatible changes. At critical places I aim at 100%, at situations with more [proximity](http://wiki.apidesign.org/wiki/ Proximity) I am fine with "99%". Should the `CharSequence.isEmpty()` problem have been known in advance, I'd avoid adding that method. However, as stated above, it is a matter of policy: both decisions can be justified.

On SourceCompatibility in Java

My focus is BinaryCompatibility (and functional compatibility), but not SourceCompatibility. JVM bytecode is much more strictly specified and more narrow field to study than analyzing source incompatibilities (unless one wants to be a parsing and grammar guru). I also believe it is more important to be able to compile against some fixed "-release" and then run on multiple versions of JVM than to compile on many "-release"s.

On Enhancing the Java Language

You are right that adding new language/JVM features can often mitigate compatibility issues. JDK team is in a unique position to make such changes (regular library API designers can't change the language), so it should be even easier to keep 100% compatibility. I am not absolutely sure what was the primary motivation for adding `CharSequence.isEmpty()` - was it meant as an API, e.g. to let people call:

if (cs.isEmpty()) return;
// rather than
if (cs.length() == 0) return;

or was it rather meant as a Service Provider Interface? E.g. allow implementors to effectively reply `isEmpty() == false` in case computing exact `length()` is costly? Let's assume the primary motivation was the ClientAPI case - e.g. calling. Rather than using default methods, one could add a compile time extension in a [competing language](https://kotlinlang.org/docs/reference/extensions.html) to the `CharSequence` interface. That would be purely API (not SPI) addition - no impact on existing implementations - e.g. it would be 100% compatible. True, improving language features can help improving binary compatibility.