|
Authored by: calris74 on Friday, April 20 2012 @ 07:15 PM EDT |
First, an API is the set of rules about what to pass and how
to
pass it between the Application Program and the
(functional) item(s) in the
Library that the Application
Program wants to use;
That is the
Specificiation
then it's the protocol for what is passed back and
how it is
passed back from the (functional) item(s)in the Library to
the
Application Program.
Again, this is part of the Specificiation -
But this part
may be pre-determined by the underlying architecture. For
example the 'how' is slightly different under Linux than it
is under
Windows.
And this is where Java's 'Write Once, Run Anywhere' comes to
the fore. The creators of Java saw that even though C and
C++ were standard
languages you still had to compile the
program for each architecture (because
the ABI for each is
different).
Also, C and C++ define standard ways
of getting text input
from and output to the user (and to some extend files),
but
what about drawing an image on the screen. You have
different APIs in
Windows, Linux and Mac for doing that. So
a program that draws images on a
screen written for Windows
CANNOT be compiled for Linux or OSX without
modifying it.
So Java defines a larger set of standard APIs than C and
C++
(but not as big as Linux, Windows of OSX) which include
graphics and sound
(and much more). And because Java is
interpreted (rather than the users
compiled program being
run directly on the CPU) much of the ABI issues no
longer
exist
NOTEI think the Dalvik ABI is different from the
standard Java ABI. So a program compiled by a Java
compiler cannot run on a
Dalvik VM (and visa-versa)
The actual act of passing information
back and forth is an
*application* of the API.
Technically, it's
called invocation (you invoke an
interface) but application (as a verb)
is close enough
[ Reply to This | Parent | # ]
|
|
|
|
|