BinaryCompatibleDefaultMethods - Revision history

JaroslavTulach: /* Future Benefits */

JaroslavTulach — Thu, 15 Oct 2020 05:59:29 GMT

Future Benefits

←Older revision		Revision as of 05:59, 15 October 2020
Line 125:		Line 125:
	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Evolution]]		[[Category:APIDesignPatterns:Evolution]]
		+
		+
		+	Reactions to some input obtained after publishing this essay are [[ScienceOfAPIDesign\|available here]]...

JaroslavTulach: /* Why now? Why not then? */

JaroslavTulach — Tue, 29 Sep 2020 12:12:17 GMT

Why now? Why not then?

←Older revision		Revision as of 12:12, 29 September 2020
Line 81:		Line 81:
	</source>		</source>

-	No problem happened back then. No clash ~~happened~~. How come? Was it just a pure luck?	+	No problem happened back then. No clash appeared. How come? Was it just a pure luck?

	No! It wasn't a luck. The '''JDK8''' addition of '''chars()''' and '''codePoints()''' was [[BinaryCompatible]]! Because adding new methods into an existing type cannot create a clash, if ''one of the arguments, or the return type is a newly introduced type''!		No! It wasn't a luck. The '''JDK8''' addition of '''chars()''' and '''codePoints()''' was [[BinaryCompatible]]! Because adding new methods into an existing type cannot create a clash, if ''one of the arguments, or the return type is a newly introduced type''!

JaroslavTulach: /* Dispatch Directly */

JaroslavTulach — Tue, 29 Sep 2020 12:11:16 GMT

Dispatch Directly

←Older revision		Revision as of 12:11, 29 September 2020
Line 70:		Line 70:
	</source>		</source>

-	Such fix has to be made across all affected places. Then all applications using affected libraries need to update to their latest versions. Only then such applications can run on '''JDK15'''. ~~That~~ no longer sounds as ''simple'', right? Clearly [[DefaultMethods]] aren't a heaven sent solution, they have some cost! If you are starting to write a new [[API]] and you want to avoid your customers paying that cost, then [[APIvsSPI\|separate API from SPI]] and don't mix the [[APIvsSPI\|two concepts]] (especially in types that are frequently subclassed/implemented by users of your [[API]]).	+	Such fix has to be made across all affected places. Then all applications using affected libraries need to update to their latest versions. Only then such applications can run on '''JDK15'''. While the fix is ''simple'', the organizational effort no longer sounds as ''simple'', right? Clearly [[DefaultMethods]] aren't a heaven sent solution, they have some cost! If you are starting to write a new [[API]] and you want to avoid your customers paying that cost, then [[APIvsSPI\|separate API from SPI]] and don't mix the [[APIvsSPI\|two concepts]] (especially in types that are frequently subclassed/implemented by users of your [[API]]).

	=== Why now? Why not then? ===		=== Why now? Why not then? ===

JaroslavTulach: /* Dispatch Directly */

JaroslavTulach — Tue, 29 Sep 2020 12:10:07 GMT

Dispatch Directly

←Older revision		Revision as of 12:10, 29 September 2020
Line 59:		Line 59:
	=== Dispatch Directly ===		=== Dispatch Directly ===

-	It is unfortunate that a code that used to run on older [[JDK]]s, doesn't ~~even link~~ and ~~results in~~ a linkage error on '''JDK15'''. The fix is however ''simple'' - just override the method and dispatch manually:	+	It is unfortunate that a code that used to run on older [[JDK]]s, doesn't run and leads to a linkage error on '''JDK15'''. The fix is however ''simple'' - just override the method and dispatch manually:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Future Benefits */

JaroslavTulach — Tue, 29 Sep 2020 10:05:20 GMT

Future Benefits

←Older revision		Revision as of 10:05, 29 September 2020
Line 114:		Line 114:
	record Status(boolean empty, boolean large, boolean asciiOnly);		record Status(boolean empty, boolean large, boolean asciiOnly);

-	default Status ~~status~~() {	+	default Status is() {
	return Status(length() == 0, length() > 255, codePoints().allMatch((ch) -> ch <= 127);		return Status(length() == 0, length() > 255, codePoints().allMatch((ch) -> ch <= 127);
	}		}

JaroslavTulach: /* Apply the Knowledge */

JaroslavTulach — Tue, 29 Sep 2020 10:04:55 GMT

Apply the Knowledge

←Older revision		Revision as of 10:04, 29 September 2020
Line 104:		Line 104:
	</source>		</source>

-	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.is().empty()'' instead of simpler ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% ~~compatible~~ or the lack of it.	+	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.is().empty()'' instead of simpler ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% [[BinaryCompatible]] or the lack of it.

	=== Future Benefits ===		=== Future Benefits ===

JaroslavTulach: /* Apply the Knowledge */

JaroslavTulach — Tue, 29 Sep 2020 10:04:09 GMT

Apply the Knowledge

←Older revision		Revision as of 10:04, 29 September 2020
Line 104:		Line 104:
	</source>		</source>

-	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.is().empty()'' instead of ~~simple~~ ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% compatible or the lack of it.	+	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.is().empty()'' instead of simpler ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% compatible or the lack of it.

	=== Future Benefits ===		=== Future Benefits ===

JaroslavTulach: /* Apply the Knowledge */

JaroslavTulach — Tue, 29 Sep 2020 10:03:48 GMT

Apply the Knowledge

←Older revision		Revision as of 10:03, 29 September 2020
Line 98:		Line 98:

	/** @since 15 */		/** @since 15 */
-	default Status ~~status~~() {	+	default Status is() {
	return Status(length() == 0);		return Status(length() == 0);
	}		}
Line 104:		Line 104:
	</source>		</source>

-	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.~~status~~().empty()'' instead of simple ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% compatible or the lack of it.	+	That'd be completely [[BinaryCompatible]] evolution. People would have to write ''seq.is().empty()'' instead of simple ''seq.isEmpty()''. But does that matter? Not from a [[performance]] perspective - every [[good]] [[JIT]] compiler eliminates any overhead. Then it is just about the will to be 100% compatible or the lack of it.

	=== Future Benefits ===		=== Future Benefits ===

JaroslavTulach at 09:56, 29 September 2020

JaroslavTulach — Tue, 29 Sep 2020 09:56:07 GMT

←Older revision		Revision as of 09:56, 29 September 2020
Line 1:		Line 1:
-	[[DefaultMethods]] are useful when one desperately needs to add a method into an existing '''interface'''. There are reasons to [[DefaultMethods#Can_you_disagree.3F\|strive to avoid doing that]], however sometimes there is just no way around [[DefaultMethods\|doing so]]. ~~That~~ it ~~comeshandy~~ that [[DefaultMethods]] are available since '''JDK8'''. However, use with care. It has recently been demonstrated that adding [[DefaultMethods]] can compromise [[BinaryCompatibility]].	+	[[DefaultMethods]] are useful when one desperately needs to add a method into an existing '''interface'''. There are reasons to [[DefaultMethods#Can_you_disagree.3F\|strive to avoid doing that]], however sometimes there is just no way around [[DefaultMethods\|doing so]]. Then it comes handy that [[DefaultMethods]] are available since '''JDK8'''. However, use with care. It has recently been demonstrated that adding [[DefaultMethods]] can compromise [[BinaryCompatibility]].

	=== Binary Incompatibility in CharSequence ===		=== Binary Incompatibility in CharSequence ===

JaroslavTulach at 09:55, 29 September 2020

JaroslavTulach — Tue, 29 Sep 2020 09:55:50 GMT

←Older revision		Revision as of 09:55, 29 September 2020
Line 1:		Line 1:
-	[[DefaultMethods]] are useful when one desperately needs to add a method into an existing '''interface'''. There are reasons to [[DefaultMethods#Can_you_disagree.3F\|strive to avoid doing that]]), however sometimes there is just no way around [[DefaultMethods\|doing so]]. That it comeshandy that [[DefaultMethods]] are available since '''JDK8'''. However, use with care. It has recently been demonstrated that adding [[DefaultMethods]] can compromise [[BinaryCompatibility]].	+	[[DefaultMethods]] are useful when one desperately needs to add a method into an existing '''interface'''. There are reasons to [[DefaultMethods#Can_you_disagree.3F\|strive to avoid doing that]], however sometimes there is just no way around [[DefaultMethods\|doing so]]. That it comeshandy that [[DefaultMethods]] are available since '''JDK8'''. However, use with care. It has recently been demonstrated that adding [[DefaultMethods]] can compromise [[BinaryCompatibility]].

	=== Binary Incompatibility in CharSequence ===		=== Binary Incompatibility in CharSequence ===