Runtime Aspects of APIs - Revision history

JaroslavTulach: /* Have You Ever Wondered...? */

2013-10-11T08:54:19Z

Have You Ever Wondered...?

←Older revision		Revision as of 08:54, 11 October 2013
Line 1:		Line 1:
	== Have You Ever Wondered...? ==		== Have You Ever Wondered...? ==

-	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.	+	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Are speed of method execution, the amount of allocated memory or [[WeakReference\|type of references]] important for API users? I guess they may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world (as for example [[MemoryAllocations]] hack demonstrates). But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.

	==== Related [[API Design Tips\|Podcast]] ====		==== Related [[API Design Tips\|Podcast]] ====

JaroslavTulach: /* Pitfalls of Java Monitors */

2009-09-07T08:48:21Z

Pitfalls of Java Monitors

←Older revision		Revision as of 08:48, 7 September 2009
Line 10:		Line 10:

	[[Runtime_Aspects_of_APIs\|This chapter]] also dedicates one section to discussion of problems one can face when dealing with [[Java Monitor]]s. Erwin Vervaet recently pointed out that the example is a little bit unclear and asked me to provide better explanation of the problem, where subclasses interfere with the parent class's [[monitor]]s. Please find the explanation at [[Java Monitor]] page.		[[Runtime_Aspects_of_APIs\|This chapter]] also dedicates one section to discussion of problems one can face when dealing with [[Java Monitor]]s. Erwin Vervaet recently pointed out that the example is a little bit unclear and asked me to provide better explanation of the problem, where subclasses interfere with the parent class's [[monitor]]s. Please find the explanation at [[Java Monitor]] page.
		+
		+	==== @Synchronized ====
		+
		+	{{:Synchronized}}

JaroslavTulach: /* = Related Podcast */

2009-05-18T17:41:00Z

= Related Podcast

←Older revision		Revision as of 17:41, 18 May 2009
Line 3:		Line 3:
	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.		Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.

-	==== Related [[API Design Tips\|Podcast]] ===	+	==== Related [[API Design Tips\|Podcast]] ====

	{{:Blogs:JaroslavTulach:Daily_Life:Podcast2}}		{{:Blogs:JaroslavTulach:Daily_Life:Podcast2}}

JaroslavTulach at 17:40, 18 May 2009

2009-05-18T17:40:48Z

←Older revision		Revision as of 17:40, 18 May 2009
Line 2:		Line 2:

	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.		Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.
		+
		+	==== Related [[API Design Tips\|Podcast]] ===
		+
		+	{{:Blogs:JaroslavTulach:Daily_Life:Podcast2}}

	==== Pitfalls of [[Java Monitor]]s ====		==== Pitfalls of [[Java Monitor]]s ====

	[[Runtime_Aspects_of_APIs\|This chapter]] also dedicates one section to discussion of problems one can face when dealing with [[Java Monitor]]s. Erwin Vervaet recently pointed out that the example is a little bit unclear and asked me to provide better explanation of the problem, where subclasses interfere with the parent class's [[monitor]]s. Please find the explanation at [[Java Monitor]] page.		[[Runtime_Aspects_of_APIs\|This chapter]] also dedicates one section to discussion of problems one can face when dealing with [[Java Monitor]]s. Erwin Vervaet recently pointed out that the example is a little bit unclear and asked me to provide better explanation of the problem, where subclasses interfere with the parent class's [[monitor]]s. Please find the explanation at [[Java Monitor]] page.

JaroslavTulach: /* Have You Ever Wondered...? */

2009-02-12T10:19:18Z

Have You Ever Wondered...?

←Older revision		Revision as of 10:19, 12 February 2009
Line 2:		Line 2:

	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.		Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.
		+
		+	==== Pitfalls of [[Java Monitor]]s ====
		+
		+	[[Runtime_Aspects_of_APIs\|This chapter]] also dedicates one section to discussion of problems one can face when dealing with [[Java Monitor]]s. Erwin Vervaet recently pointed out that the example is a little bit unclear and asked me to provide better explanation of the problem, where subclasses interfere with the parent class's [[monitor]]s. Please find the explanation at [[Java Monitor]] page.

JaroslavTulach at 20:51, 13 August 2008

2008-08-13T20:51:29Z

←Older revision		Revision as of 20:51, 13 August 2008
Line 1:		Line 1:
-	API ~~Signatures are definitely~~ the ~~only~~ API ~~we shall~~ be ~~interested~~ in.	+	== Have You Ever Wondered...? ==
		+
		+	Did you ever tried to find the border line between the API and its implementation? Is javadoc API? I guess, so. Do names of public classes and methods belong into the API? Are the checks for incorrect parameter types throwing ''IllegalArgumentException'' part of API? Are ''NullPointerException''s thrown from inside of the API method bodies part of API? And what about the order of callbacks to client code, order of event delivery, identity of threads the callbacks happen in? Is speed of method execution or the amount of allocated memory important for API users? I guess it may be, at least in the [[wikipedia::Real-time_computing\|real-time]] world. But then: Where is the border between API and its implementation!? The [[Runtime Aspects of APIs\|chapter 11]] shows why the APIs do not end at method and class signatures. It explains why these ''runtime'' APIs are important and what needs to be done to evolve them in the right way - evolve them compatibly. The [[Runtime Aspects of APIs\|chapter 11]] does not reveal the holy grail, but it presents a technique proven to work, capable to ensure runtime backward compatibility.

Apidesign: New page: API Signatures are definitely the only API we shall be interested in.

2008-06-14T06:05:22Z

New page: API Signatures are definitely the only API we shall be interested in.

New page

API Signatures are definitely the only API we shall be interested in.