Portability - Revision history

JaroslavTulach at 11:02, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 11:02:00 GMT

←Older revision		Revision as of 11:02, 1 April 2023
Line 7:		Line 7:
	Writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases [[portability]].		Writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases [[portability]].
	However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].		However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].
		+
		+	Supporting the ancient [[JDK]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want.

	=== Transitivity of non-[[Portability]] ===		=== Transitivity of non-[[Portability]] ===

-	Supporting the ancient [[JDK]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want. However there's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.	+	There's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.

	Btw. [[NetBeans]] is facing this non-portability issues with [[Lucene]]. The [[Lucene]] team decided to stop supporting [[JDK]]8 in newest versions. That puts all [[Lucene]] users into a dilemma:		Btw. [[NetBeans]] is facing this non-portability issues with [[Lucene]]. The [[Lucene]] team decided to stop supporting [[JDK]]8 in newest versions. That puts all [[Lucene]] users into a dilemma:

JaroslavTulach at 11:00, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 11:00:17 GMT

←Older revision		Revision as of 11:00, 1 April 2023
Line 8:		Line 8:
	However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].		However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

		+	=== Transitivity of non-[[Portability]] ===

	Supporting the ancient [[JDK]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want. However there's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.		Supporting the ancient [[JDK]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want. However there's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.

JaroslavTulach at 10:58, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 10:58:50 GMT

←Older revision		Revision as of 10:58, 1 April 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems~~. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability~~.	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems.

	=== [[Portability]] of [[Java]] [[Libraries]] ===		=== [[Portability]] of [[Java]] [[Libraries]] ===

		+	Writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases [[portability]].
	However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].		However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 10:58, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 10:58:08 GMT

←Older revision		Revision as of 10:58, 1 April 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability.
		+
		+	=== [[Portability]] of [[Java]] [[Libraries]] ===
		+
		+	However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 10:56, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 10:56:48 GMT

←Older revision		Revision as of 10:56, 1 April 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 10:55, 1 April 2023

JaroslavTulach — Sat, 01 Apr 2023 10:55:48 GMT

←Older revision		Revision as of 10:55, 1 April 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example as that prevents your library to run on [[Unix]]-like systems. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 04:33, 9 February 2023

JaroslavTulach — Thu, 09 Feb 2023 04:33:26 GMT

←Older revision		Revision as of 04:33, 9 February 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be aspire to be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 04:32, 9 February 2023

JaroslavTulach — Thu, 09 Feb 2023 04:32:41 GMT

←Older revision		Revision as of 04:32, 9 February 2023
Line 1:		Line 1:
	When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.		When designing frameworks and libraries that shall be widely adopted it is important to increase [[portability]] as much as possible. If an [[API]] can be used on different systems, different configurations, the amount of users including such [[API]] in their applications grows.

-	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ~~support~~ JDK version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].	+	The best way to hurt [[portability]] is to depend on a 3rd party [[API]] that isn't [[portability\|portable]]. Depending on Win32 [[API]] is one such example. Of course, writing in [[Java]] (a [[language]] designed to ''write once and run everywhere'') greatly increases portability. However there is another axis hurting [[portability]] - the ''supported JDK'' version. Of course, should a library be widely used, it has to support as oldest JDK as possible. These days it is [[JDK]]8 - the primary reason being that [[Android]] supports [[JDK]]8 - as such, should a library be used on [[Android]] (as well as regular [[Java]]), it needs to stick to version eight. Btw. not that many years ago, [[Android]] only supported [[JDK]]6 and many libraries had to stay with [[JDK]]6 [[API]]s and [[language]].

JaroslavTulach at 19:55, 30 October 2022

JaroslavTulach — Sun, 30 Oct 2022 19:55:28 GMT

←Older revision		Revision as of 19:55, 30 October 2022
Line 18:		Line 18:

	What every non-masochist [[API]] writer wants is:		What every non-masochist [[API]] writer wants is:
-	* high portability with respect to supported range of [[JDK]]s	+	* high portability with respect to supported range of [[JDK]]s (maybe with help of [[AlternativeImplementation]]s)
	* decent version of [[Java]] language		* decent version of [[Java]] language
	* code against selected old [[JDK]] [[API]]s, but use the latest [[Java]] features		* code against selected old [[JDK]] [[API]]s, but use the latest [[Java]] features

JaroslavTulach at 18:14, 30 October 2022

JaroslavTulach — Sun, 30 Oct 2022 18:14:55 GMT

←Older revision		Revision as of 18:14, 30 October 2022
Line 4:		Line 4:


-	Supporting the ancient [[JDK]]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want. However there's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.	+	Supporting the ancient [[JDK]] gives the application writers using such library or framework a [[freedom]] to choose their [[JDK]]. The application writers can then run on oldest or newest [[JDK]]. That's the kind of [[freedom]] they want. However there's ''transitivity of non-portability'' - the [[portability]] of the final application cannot be bigger than [[portability]] of the least portable library used. This applies also to 3rd party dependencies a framework or library has: again their non-portability may negatively affect portability of such framework or library.

	Btw. [[NetBeans]] is facing this non-portability issues with [[Lucene]]. The [[Lucene]] team decided to stop supporting [[JDK]]8 in newest versions. That puts all [[Lucene]] users into a dilemma:		Btw. [[NetBeans]] is facing this non-portability issues with [[Lucene]]. The [[Lucene]] team decided to stop supporting [[JDK]]8 in newest versions. That puts all [[Lucene]] users into a dilemma: