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

=== 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:

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

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]] ===

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

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.

 

 

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

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

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

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

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

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

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: