Dependencies - Revision history

JaroslavTulach at 18:06, 22 June 2025

2025-06-22T18:06:57Z

←Older revision		Revision as of 18:06, 22 June 2025
Line 36:		Line 36:

	{{:RangeDependencies}}		{{:RangeDependencies}}
-
-



	[[Category:APITypes]]		[[Category:APITypes]]

JaroslavTulach at 12:05, 7 January 2012

2012-01-07T12:05:44Z

←Older revision		Revision as of 12:05, 7 January 2012
Line 31:		Line 31:
	Then one needs to express the incompatibility in the versioning. Usually there is some ''major'' version number that, once increased means that the new version is no longer compatible with the previous one. This shall be used rarely, but each [[module system]] needs to provide some way of expressing incompatible versions.		Then one needs to express the incompatibility in the versioning. Usually there is some ''major'' version number that, once increased means that the new version is no longer compatible with the previous one. This shall be used rarely, but each [[module system]] needs to provide some way of expressing incompatible versions.

-	Common way to implement this is to associate with each version an implicit upper bound. So when one writes <math>some.library >= 1.4.3</math> one actually means any give me some library at least in version 1.4.3 but not 2.0 or higher. From here there is just a little step towards [[RangeDependencies]].	+	Common way to implement this is to associate with each version an implicit [[upper bound]]. So when one writes <math>some.library >= 1.4.3</math> one actually means any give me some library at least in version 1.4.3 but not 2.0 or higher. From here there is just a little step towards [[RangeDependencies]].

	=== [[RangeDependencies]] ===		=== [[RangeDependencies]] ===

JaroslavTulach: /* Dependencies */

2011-10-24T05:09:35Z

Dependencies

←Older revision		Revision as of 05:09, 24 October 2011
Line 1:		Line 1:
	== Dependencies ==		== Dependencies ==

-	Not many [[API]]s can live alone, without support from other parts of the system. Every [[C]] library needs [[wikipedia::Libc\|libc]], every [[Java]] code needs some version of [[JDK]]. As each library, also [[API]]s have own environment, which defines what needs to be available around to allow the [[API]] to function properly. Each user of such shared library needs to recreate proper environment, that means to satisfy its dependencies, before its [[API]] can be used. This implies, that the ''dependencies of a library'' form an important [[API]] of the shared library itself.	+	Not many [[API]]s can live alone, without support from other parts of the system. Every [[C]] application or library needs [[wikipedia::Libc\|libc]], every [[Java]] code needs some version of [[JDK]]. As each library, also [[API]]s have own environment, which defines what needs to be available around to allow the [[API]] to function properly. Each user of such shared library needs to recreate proper environment, that means to satisfy its dependencies, before its [[API]] can be used. This implies, that the ''dependencies of a library'' form an important [[API]] of the shared library itself.

	These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an [[API]] change. Imagine, that users of your API are using your library in some version and it works fine with just plain [[JDK]]. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.		These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an [[API]] change. Imagine, that users of your API are using your library in some version and it works fine with just plain [[JDK]]. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.

JaroslavTulach: /* Need for Incompatible Version */

2009-10-16T18:51:15Z

Need for Incompatible Version

←Older revision		Revision as of 18:51, 16 October 2009
Line 31:		Line 31:
	Then one needs to express the incompatibility in the versioning. Usually there is some ''major'' version number that, once increased means that the new version is no longer compatible with the previous one. This shall be used rarely, but each [[module system]] needs to provide some way of expressing incompatible versions.		Then one needs to express the incompatibility in the versioning. Usually there is some ''major'' version number that, once increased means that the new version is no longer compatible with the previous one. This shall be used rarely, but each [[module system]] needs to provide some way of expressing incompatible versions.

		+	Common way to implement this is to associate with each version an implicit upper bound. So when one writes <math>some.library >= 1.4.3</math> one actually means any give me some library at least in version 1.4.3 but not 2.0 or higher. From here there is just a little step towards [[RangeDependencies]].

		+	=== [[RangeDependencies]] ===
		+
		+	{{:RangeDependencies}}

JaroslavTulach: /* Greater Than */

2009-10-16T18:37:45Z

Greater Than

←Older revision		Revision as of 18:37, 16 October 2009
Line 19:		Line 19:
	Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.		Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.

-	=== Greater ~~Than~~ ===	+	=== Greater Or Equal ===

-	For modules deployed individually one needs to allow certain freedom. The ''equality'' dependency is too restricting. ~~Usually~~ people use ''equal or greater than'' dependency. ~~It is~~ usually ~~expected~~ that if program runs on [[Java]] 1.3, it will also run (relatively) fine on [[Java]] 1.5.	+	For modules deployed individually one needs to allow certain freedom. The ''equality'' dependency is too restricting. Often people use ''equal or greater than'' dependency. This follows the usually accepted expectation that if program runs on [[Java]] 1.3, it will also run (relatively) fine on [[Java]] 1.5.

	This of course requires the vendor of the library to follow rules of [[BackwardCompatibility]] - e.g. really design and especially [[evolution\|evolve]] the [[API]] well. However most people designing commonly used libraries understand this and thus we can mostly rely on ''>='' dependencies.		This of course requires the vendor of the library to follow rules of [[BackwardCompatibility]] - e.g. really design and especially [[evolution\|evolve]] the [[API]] well. However most people designing commonly used libraries understand this and thus we can mostly rely on ''>='' dependencies.
		+
		+	=== Need for Incompatible Version ===
		+
		+	In life of every [[API]] comes a moment when its provider needs to make an incompatible change. There is no way around it. Even [[Solaris]], the most compatible software project I am aware of, needs to make an incompatible change in some published interface from time to time. Moreover [[BackwardCompatibility]] in [[Solaris]] is the most important mantra, in regular libraries, it may not be adhered to so strongly. Of course, it is better to find a way to provide [[AlternativeBehaviour]], but sometimes there is really no [[BackwardCompatibility\|backward compatible]] way around.
		+
		+	Then one needs to express the incompatibility in the versioning. Usually there is some ''major'' version number that, once increased means that the new version is no longer compatible with the previous one. This shall be used rarely, but each [[module system]] needs to provide some way of expressing incompatible versions.
		+
		+
		+
		+
		+
		+

	[[Category:APITypes]]		[[Category:APITypes]]

JaroslavTulach: /* Equality */

2009-10-16T16:54:01Z

Equality

←Older revision		Revision as of 16:54, 16 October 2009
Line 15:		Line 15:
	=== Equality ===		=== Equality ===

-	One can depend on exact certain version of other library. This is however very restricting. If there is a part of application that needs [[Java]] 1.3 and another that needs [[Java]] 1.5, will you run each part of the application in different [[~~Hotspot~~\|VM]]?	+	One can depend on exact certain version of other library. This is however very restricting. If there is a part of application that needs [[Java]] 1.3 and another that needs [[Java]] 1.5, will you run each part of the application in different [[HotSpot\|VM]]?

	Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.		Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.

JaroslavTulach: /* Equality */

2009-10-16T16:53:50Z

Equality

←Older revision		Revision as of 16:53, 16 October 2009
Line 15:		Line 15:
	=== Equality ===		=== Equality ===

-	One can depend on exact certain version of other library. This is however very restricting. If there is a part of application that needs [[Java]] 1.3 and another that needs [[Java]] 1.5, will you run each part of the application in different [[VM]]?	+	One can depend on exact certain version of other library. This is however very restricting. If there is a part of application that needs [[Java]] 1.3 and another that needs [[Java]] 1.5, will you run each part of the application in different [[Hotspot\|VM]]?

	Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.		Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.

JaroslavTulach: /* Specifying Dependencies */

2009-10-16T16:53:38Z

Specifying Dependencies

←Older revision		Revision as of 16:53, 16 October 2009
Line 9:		Line 9:
	=== Specifying [[Dependencies]] ===		=== Specifying [[Dependencies]] ===

-	[[Dependencies]] are usually specified as set of pairs. First element in each pair contains unique identification of needed [[API]] and also some specification of the [[API]] versions.	+	[[Dependencies]] are usually specified as set of pairs. First element in each pair contains unique identification of needed [[API]] and also some specification of the [[API]] versions. Depending on the actual [[module system]], the dependencies may be equality, greater than or even specified as a [[RangeDependencies\|range]].
		+
		+	It is important to mention that [[dependencies]] are almost always simplification of the real environment required. People often say: ''my library needs [[Java]] version 1.3'', or ''version 1.5'', while in fact then may mean: ''my application needs class'' '''JNDI''' (introduce as part of [[Java]] 1.3). Or ''my application requires annotations'' (added in version 1.5). That is more precise, however such exact description of own's [[dependencies]] is very complex and verbose. Much easier to simplify each dependency to just one number (with some interpretation).
		+
		+	=== Equality ===
		+
		+	One can depend on exact certain version of other library. This is however very restricting. If there is a part of application that needs [[Java]] 1.3 and another that needs [[Java]] 1.5, will you run each part of the application in different [[VM]]?
		+
		+	Thus this kind of dependency is useful only for modules which can be used separately, but are built and deployed together.
		+
		+	=== Greater Than ===
		+
		+	For modules deployed individually one needs to allow certain freedom. The ''equality'' dependency is too restricting. Usually people use ''equal or greater than'' dependency. It is usually expected that if program runs on [[Java]] 1.3, it will also run (relatively) fine on [[Java]] 1.5.
		+
		+	This of course requires the vendor of the library to follow rules of [[BackwardCompatibility]] - e.g. really design and especially [[evolution\|evolve]] the [[API]] well. However most people designing commonly used libraries understand this and thus we can mostly rely on ''>='' dependencies.

	[[Category:APITypes]]		[[Category:APITypes]]

JaroslavTulach at 16:06, 16 October 2009

2009-10-16T16:06:11Z

←Older revision		Revision as of 16:06, 16 October 2009
Line 1:		Line 1:
	== Dependencies ==		== Dependencies ==

-	Not many [[API]]s can live alone, without support from other parts of the system. As each library, also [[API]]s have own environment, which defines what needs to be available around to allow the [[API]] to function properly. Each user of ~~the~~ shared library needs to recreate proper environment, that means to satisfy ~~library~~ dependencies, before ~~the~~ [[API]] can be used. This implies, that the ''dependencies of a library'' form an important [[API]] of the shared library itself.	+	Not many [[API]]s can live alone, without support from other parts of the system. Every [[C]] library needs [[wikipedia::Libc\|libc]], every [[Java]] code needs some version of [[JDK]]. As each library, also [[API]]s have own environment, which defines what needs to be available around to allow the [[API]] to function properly. Each user of such shared library needs to recreate proper environment, that means to satisfy its dependencies, before its [[API]] can be used. This implies, that the ''dependencies of a library'' form an important [[API]] of the shared library itself.

	These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an [[API]] change. Imagine, that users of your API are using your library in some version and it works fine with just plain [[JDK]]. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.		These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an [[API]] change. Imagine, that users of your API are using your library in some version and it works fine with just plain [[JDK]]. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.
Line 7:		Line 7:
	As the [[Determining What Makes a Good API\|Chapter 3]] defines [[API]]s as everything that is externally visible, it makes sense to include ''shared library dependencies'' into the family of various types of [[API]]s. In spite the fact, that it is very hidden kind of [[API]], it is in fact one of the highest level kind and the [[API]] that we deal with the most during our day to day work.		As the [[Determining What Makes a Good API\|Chapter 3]] defines [[API]]s as everything that is externally visible, it makes sense to include ''shared library dependencies'' into the family of various types of [[API]]s. In spite the fact, that it is very hidden kind of [[API]], it is in fact one of the highest level kind and the [[API]] that we deal with the most during our day to day work.

-	--[[~~User:JaroslavTulach\|JaroslavTulach~~]] ~~10:47, 16 June 2008 (UTC)~~	+	=== Specifying [[Dependencies]] ===
		+
		+	[[Dependencies]] are usually specified as set of pairs. First element in each pair contains unique identification of needed [[API]] and also some specification of the [[API]] versions.

	[[Category:APITypes]]		[[Category:APITypes]]

JaroslavTulach: /* Dependencies */

2009-10-16T12:59:13Z

Dependencies

←Older revision		Revision as of 12:59, 16 October 2009
Line 1:		Line 1:
	== Dependencies ==		== Dependencies ==

-	Not many ~~APIs~~ can live alone, without support from other parts of the system. As each library, also ~~APIs~~ have own environment, which defines what needs to be available around to allow the API to function properly. Each user of the shared library needs to recreate proper environment, that means to satisfy library dependencies, before the API can be used. This implies, that the ''dependencies of a library'' form an important API of the shared library itself.	+	Not many [[API]]s can live alone, without support from other parts of the system. As each library, also [[API]]s have own environment, which defines what needs to be available around to allow the [[API]] to function properly. Each user of the shared library needs to recreate proper environment, that means to satisfy library dependencies, before the [[API]] can be used. This implies, that the ''dependencies of a library'' form an important [[API]] of the shared library itself.

-	These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an API change. Imagine, that users of your API are using your library in some version and it works fine with just plain JDK. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.	+	These dependencies may not even be visible in external signatures (more about that in [[TypesOfDependencies]])! They may only be needed during the runtime, internally, still changing them constitutes an [[API]] change. Imagine, that users of your API are using your library in some version and it works fine with just plain [[JDK]]. Suddenly, in newer release, you decide to change the library internals and depend on some other library, for example [[wikipedia::Jakarta_Commons\|Jakarta Commons]]. That immediately means every user, who migrates to new version of your library, needs to include a version of [[wikipedia::Jakarta_Commons\|Jakarta Commons]] in own application as well. This may or may not be a problem, however this is quite an externally visible change.

-	As the [[Determining What Makes a Good API\|Chapter 3]] defines ~~APIs~~ as everything that is externally visible, it makes sense to include ''shared library dependencies'' into the family of various types of ~~APIs~~. In spite the fact, that it is very hidden kind of API, it is in fact one of the highest level kind and the API that we deal with the most during our day to day work.	+	As the [[Determining What Makes a Good API\|Chapter 3]] defines [[API]]s as everything that is externally visible, it makes sense to include ''shared library dependencies'' into the family of various types of [[API]]s. In spite the fact, that it is very hidden kind of [[API]], it is in fact one of the highest level kind and the [[API]] that we deal with the most during our day to day work.

	--[[User:JaroslavTulach\|JaroslavTulach]] 10:47, 16 June 2008 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 10:47, 16 June 2008 (UTC)

	[[Category:APITypes]]		[[Category:APITypes]]