'. '

ScienceOfAPIDesign

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(On Enhancing the Java Language)
Current revision (10:30, 10 October 2020) (edit) (undo)
(On Enhancing the Java Language)
 
(24 intermediate revisions not shown.)
Line 1: Line 1:
-
This post contains reflections on [[BinaryCompatibleDefaultMethods]] article.
+
[[ScienceOfAPIDesign|This post]] contains reflections on [[BinaryCompatibleDefaultMethods]] article and discussion that have emerged from it.
-
==== On Being too Demanding and Policies ====
+
==== On Being too Demanding ====
-
[[I]] have a mathematical background. I am interested in [[APIDesign]] from a point
+
[[I]] have a [[IsGodAMathematician|mathematical background]]. I am interested in [[APIDesign]] from a point
of provably correct [[evolution]]. My [[APIDesignPatterns]] aim at 100% [[BackwardCompatible]]
of provably correct [[evolution]]. My [[APIDesignPatterns]] aim at 100% [[BackwardCompatible]]
[[evolution]] - e.g. even if one knows what will happen in the future,
[[evolution]] - e.g. even if one knows what will happen in the future,
-
one can't write a program that breaks.
+
one cannot write a program that would break. Does that sound imposible? No, it is not, just
 +
try to play an [[APIFest]] (or ask [[I|me]] to organize one for you) and you will learn the tricks!
-
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.).
+
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 [[Platonic|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
I am not a behavioral scientist. Discussing whether keeping 100% compatibility
Line 17: Line 24:
Overall I prefer to not make incompatible changes. At critical places I aim at
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/
+
100%, at situations with more [[proximity]] I am fine with "99%". Should the [[BinaryCompatibleDefaultMethods|CharSequence.isEmpty() problem]]
-
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
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.
above, it is a matter of policy: both decisions can be justified.
 +
 +
{{#ev:youtube|03JXTuFGYWE}}
 +
 +
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 [[pragmatic|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 ====
==== On [[SourceCompatibility]] in Java ====
Line 29: Line 40:
wants to be a parsing and grammar guru). I also believe it is more important
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
to be able to compile against some fixed "-release" and then run on multiple
-
versions of JVM than to compile on many "-release"s.
+
versions of [[JVM]] than to compile on many "-release"s.
==== On Enhancing the [[Java]] Language ====
==== On Enhancing the [[Java]] Language ====
-
You are right that adding new language/JVM features can often mitigate
+
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
+
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
+
(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
+
even easier to keep 100% [[BackwardCompatibility]]. Let's run a mental experiment.
-
primary motivation for adding `CharSequence.isEmpty()` - was it meant as an
+
 
-
API, e.g. to let people call:
+
I am not absolutely sure what was the primary motivation for adding [[BinaryCompatibleDefaultMethods|CharSequence.isEmpty()]] - was it meant as a [[ClientAPI]], e.g. to let people call:
<source lang="java">
<source lang="java">
Line 47: Line 58:
or was it rather meant as a [[ProviderAPI|Service Provider Interface]]? E.g. allow implementors to effectively reply
or was it rather meant as a [[ProviderAPI|Service Provider Interface]]? E.g. allow implementors to effectively reply
-
`isEmpty() == false` in case computing exact `length()` is costly? Let's
+
'''isEmpty() == false''' in case computing exact '''length()''' is costly?
-
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
+
Let's assume the primary motivation was the [[ClientAPI]] case - e.g. calling. Rather than using default methods, one could add a [https://kotlinlang.org/docs/reference/extensions.html compile time extension] (like in the [[Kotlin]] language) to the
-
language](https://kotlinlang.org/docs/reference/extensions.html) to the
+
{{JDK|java/lang|CharSequence}} interface. That would be purely [[ClientAPI]] (e.g. not [[SPI]]) addition - no impact on existing implementations - e.g. it would be 100% compatible.
-
`CharSequence` interface. That would be purely API (not SPI) addition - no
+
 
-
impact on existing implementations - e.g. it would be 100% compatible. True,
+
True, improving language features can help improve [[BinaryCompatibility]].
-
improving language features can help improving binary compatibility.
+
 
 +
 
 +
[[Category:Video]]

Current revision

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

Contents

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.

Personal tools
buy