ScienceOfAPIDesign

From APIDesign

Current revision

This post contains reflections on BinaryCompatibleDefaultMethods article and discussion that have emerged from it.

On Being too Demanding

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 cannot write a program that would break. Does that sound imposible? No, it is not, just try to play an APIFest (or ask me to organize one for you) and you will learn the tricks!

Of course 100% compatible evolution may sound a bit too demanding for regular beings and their projects. True, but that's how science works! Science 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 Euclids geometry. Some get closer (Newton's dynamic) some don't (biology, medicine, social sciences, etc.).

The ScienceOfAPIDesign shall provide such sharp answers! Whether one uses them or not, is a different story.

On Policies

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 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.

What matters is to have some consistent policy. However writing policies down and formulating them is tough. Often the decision makers just use their gut sense and oscillate between rationalism (call for perfectness) and pragmatism (let's allow some compromises) based on their momentary feelings. At the end they end up without any policy/method at all!

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

It is true that adding new language/JVM feature 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% BackwardCompatibility. Let's run a mental experiment.

I am not absolutely sure what was the primary motivation for adding CharSequence.isEmpty() - was it meant as a ClientAPI, 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 (like in the Kotlin language) to the CharSequence interface. That would be purely ClientAPI (e.g. not SPI) addition - no impact on existing implementations - e.g. it would be 100% compatible.

True, improving language features can help improve BinaryCompatibility.