Portability
From APIDesign
| (11 intermediate revisions not shown.) | |||
| 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 | + | 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]] === | ||
| + | |||
| + | 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]]. | ||
| + | |||
| + | 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]] === | ||
| + | |||
| + | 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: | ||
| + | * drop support for [[JDK]]8 too | ||
| + | * stick with old versions | ||
| + | * backport new fixes/features into [[Lucene]] that still runs on [[JDK]]8 | ||
| + | |||
| + | Btw. [[Spring]] framework is said to drop support for [[JDK]]8 as well. Why it works for them? Majority of the market. Nature of micro services? | ||
[[TBD]] | [[TBD]] | ||
| - | Of course, writing portable libraries is harder. It requires more work from the [[API]] author, more self-control, more suffering. However such suffering is justifiable. There is usually a single [[API]] writer, but there are [[3SidesToEveryAPI#Mine|many users]] to it. What matters is to simplify and improve experience of those [[API]] users - own author suffering doesn't matter that much. | + | Of course, writing portable libraries is harder. It requires more work from the [[API]] author, more self-control, more suffering. However such suffering is justifiable. There is usually a single [[API]] writer, but there are [[3SidesToEveryAPI#Mine|many users]] to it. What matters is to simplify and improve experience of those [[API]] users - own author suffering doesn't matter that much. On the other hand, there is no need to suffer needlessly. Even [[API]] writers shall have a decent life! What does that mean in [[Java]]? While an [[API]] writer wants to target the oldest [[JDK]] possible, there is no point in sticking with ancient [[Java]] syntax! Just use [[Frgaal]]! |
| + | |||
| + | What every non-masochist [[API]] writer wants is: | ||
| + | * high portability with respect to supported range of [[JDK]]s (maybe with help of [[AlternativeImplementation]]s) | ||
| + | * decent version of [[Java]] language | ||
| + | * code against selected old [[JDK]] [[API]]s, but use the latest [[Java]] features | ||
| + | |||
| + | This all can easily be achieved with [[Frgaal]]. | ||
| - | |||
[[Frgaal]] is the [[Java]] compiler for framework and library authors! | [[Frgaal]] is the [[Java]] compiler for framework and library authors! | ||
Current revision
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 portable. Depending on Win32 API is one such example as that prevents your library to run on Unix-like systems.
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 JDK8 - the primary reason being that Android supports JDK8 - 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 JDK6 and many libraries had to stay with JDK6 APIs 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
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 JDK8 in newest versions. That puts all Lucene users into a dilemma:
- drop support for JDK8 too
- stick with old versions
- backport new fixes/features into Lucene that still runs on JDK8
Btw. Spring framework is said to drop support for JDK8 as well. Why it works for them? Majority of the market. Nature of micro services?
Of course, writing portable libraries is harder. It requires more work from the API author, more self-control, more suffering. However such suffering is justifiable. There is usually a single API writer, but there are many users to it. What matters is to simplify and improve experience of those API users - own author suffering doesn't matter that much. On the other hand, there is no need to suffer needlessly. Even API writers shall have a decent life! What does that mean in Java? While an API writer wants to target the oldest JDK possible, there is no point in sticking with ancient Java syntax! Just use Frgaal!
What every non-masochist API writer wants is:
- high portability with respect to supported range of JDKs (maybe with help of AlternativeImplementations)
- decent version of Java language
- code against selected old JDK APIs, but use the latest Java features
This all can easily be achieved with Frgaal.
Frgaal is the Java compiler for framework and library authors!
Follow
