On Java's Interface (the meaning of interface in computer programing)

X

Xah Lee

On Java's Interface

Xah Lee, 20050223

In Java the language, there's this a keyword “interfaceâ€.

In a functional language, a function can be specified by its name and
parameter specs. For example:
f(3)
f(3, [9,2])
f("some string")

are usage examples of 3 functions all having the same name, but having
different number and type of arguments. In this way, a function is
essentially known to outsiders by its name and parameter specs. The
gist in this concept is that the user don't need to know the
implementation details of the function. All she needs to know is the
function's name, and parameter specs and return value spec. (and of
course what the function is supposed to do.) In this way, interface
and implementation are separated. The implementation can change or
improve anytime, and users don't need to know.

In Java, the above concept of function name and parameter spec is
called a method's signature.

For another example, usually a program needs to talk to another
software such as a database software. The database software may have a
set of functions for the purpose of communicating to other software.
In essence, making the database useful to other software. Such a list
of function spec is often called API, which stands for Application
Programing Interface.

The API terminology is abused by the marketing-loving Sun Microsystems
by calling the Java language's documentation as “The Java APIâ€, even
though Java the language and its paraphernalia of libraries and
hardware-emulation system (all together jargonized as “the Java
Platformâ€) isn't a Application nor Interface. (a API implies that
there are two disparate entities involved, which are allowed to
communicate thru it. In the case of “The Java APIâ€, it's one entity
talking to itself.).

In general, the interface concept in programing is a sort of
specification that allows different entities to call and make use of
the other, with the implication that the caller need not know what's
behind the facade.

In the Object Oriented Programing Paradigm, a new concept arose, that
is the “interface†aspect of a class.

As we've seen, a function has parameter spec that is all there it is a
user needs to know for using it. In Java, this is the method's
“signatureâ€. Now, as the methodology of the OOP experience multiplies,
it became apparent that the interface concept can be applied to
Classes as well. Specifically: the interface of a class is the class's
methods.

This concept is then turned into a OOP machinery, in hope of
extracting usefulness in software engineering. That is to say, now in
the Java language, a programer can actually write a piece of code,
whose sole purpose is to define what methods and variables a class
contains. This, is done with the keyword “interfaceâ€. Once a interface
is defined, other classes can say which interfaces they implement, so
that if class C implement interface I, then programers don't need to
know the details about C. All they need to know is the interface I.
(which specifies all the methods, constructors, variables, a class
must have.)

(the Java's interface, is essentially the “signature†of a class, in
Java's own jargon.)

A programer may ask, what's the big deal anyway? Since in Java,
classes are well documented anyway. What difference does it make to
know the documentation of C versus the documentation of interface for
C?

The thing about interface in Java is that the complexity grows. A Java
interface, can be inherited, just as classes. The idea is that
interfaces can also form a hierarchy just like classes.

In pure OOP such as Java, the object entities used to solve computing
problems are thought to form a relation as of a tree, thus we have the
class hierarchy. In a similar way, it is thought that interface, can
also form a hierarchy fruitfully. A good example is the list data
type. The explanation follows.

In computing languages, often there's a data concept variously known
as lists, aggregate, sequences, array, vector, tuple, set, matrix,
trees... The basic idea is that it is just a list of things. This list
may not allow repetitions, elements may be lists themselves, may have
certain dimension stipulations (e.g. matrix), may have certain
computational properties such as speed of retrieving a element or
adding a element or memory footprint... etc and so on. Different
requirement and different computational properties have given them
various names to go by. One can however organize them by the interface
perspective. In Java, they are known as Collection, and all have the
interface of Collection. (See http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html
http://java.sun.com/docs/books/tutorial/collections/interfaces/index.html
)

Consider a Set and List. One does not allow repetitions, while the
other allows. Other than that, both concepts are the same. They both
need methods like adding elements, deleting, inserting, sorting etc.
Therefore, from interface point of view, they share a parent. In Java,
both Set and List are interfaces, inherited from the parent interface
Collection.

So now, in Java, we have two hierarchies of separate category: Classes
and Interfaces. The Classes hierarchy is one single giant tree.
However, the interfaces are not all together as one tree. They are
more like forests, of many trees. It is important to remember that
interfaces and classes are separate entities. A class can implement a
interface. A interface can never inherit from a class.

In Java, it so happens that a class can implement more than one
interfaces. When a class C implements interfaces I1 and I2, C is
guaranteed to have all methods declared by interface I1 and I2. For
example, in Java, class Integer has interfaces Comparable and
Serializable. And the class ArrayList has these interfaces: Cloneable,
Collection, List, RandomAccess, Serializable.

The interface in Java, from a simple useful idea, has mutated into a
incomprehensible complexity.

In Java, Interface is no longer the sole thing a programer needs to
know about a class or function. It is no longer a concept that
separates a function's user spec from implementation detail.

For example, the ArrayList class has these interfaces: Cloneable,
Collection:List, RandomAccess, Serializable. As one can infer from the
names, they are more about what properties ArrayList has, than a
syntax facade that hides implementation irrelevances.

For example, see the Java documentation on these interfaces: •
interface RandomAccess http://java.sun.com/j2se/1.5.0/docs/api/java/util/RandomAccess.html

• interface Serializable http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html

• interface Comparable http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Comparable.html

One can see that these “interfaces†are really not interface in
nature, but properties. One might ask, in “interfaces†such as
RandomAccess that doesn't have a single variable or method, in what
technical definition that a class is said to satisfy such interfaces?
And, given the existence of these property-like interfaces, can a
programer define their own arbitrary computational property contract?
For example, suppose i want a property ConstantTime for the classes in
game i'm developing. Once i declared a class to have “interfaceâ€
ConstantTime, apparently my class is not going to magically become
constant time. How do i define arbitrary properties to the compiler,
and how's the compiler going to check? The following are the answers.
20050224

Java's Interface has mutated so much from the interface concept that
it also functions as a pure label. If a interface does not have any
variables or methods, any class can declare it as a interface. There
is no restraint whatsoever. For example, the RandomAccess interface in
Java does not have any variables or methods. Any class can declare it
as a interface, randomly accessible or not. When interface is used as
a label, it is called a “marker interface†by the Java documentation.
For example, see http://java.sun.com/j2se/1.5.0/docs/api/java/util/RandomAccess.html

Because the multi-inheritance nature of Java interface, and its double
role as a label, it no longer function as a communication facade that
is the meaning of interface. If a Java class have interfaces A, B, C,
D, E, one cannot be sure just exactly what methods or variables the
class have. (it will be a union of them, and some of them do not serve
any function with respect to the language.) Further, using interface
as a inert label to indicate computational properties (e.g.
RandomAccess) is a egregious incompetence in the design of a language
for computation. The gist of the problem is that it is a piece of
mathematical irrelevance in the language. As a labeling mechanism in a
language, for the possible benefit from the software engineering
perspective, then it should not be designed as part of the Class
Interface, since labeling and programing interfaces are semantically
disparate.
On the Inanity of Standard Java Tutorials

The standard Java tutorials out there are often inane, in that none of
them actually tried to teach what the language actually manifestly do,
but instead, often talk in some purportedly good engineering
perspective.

For a incomprehensible metaphysical intro to interface using bicycle,
see this page of the Official Java Tutorial:
http://java.sun.com/docs/books/tutorial/java/concepts/interface.html.
For a more detailed account of Interface using baffling financial
stocks, see this page of the Official Java Tutorial:
http://java.sun.com/docs/books/tutorial/java/interpack/createinterface.html.
(the official Java Tutorial has went into major changes in 2006. For
the version of the above two pages, see local copy as of 2005

PS the official Java tutorial thru its update history has changed its
stance about what's a interface:

before 2005:
Definition: An interface is a named collection of method definitions
(without implementations). An interface can also declare constants.

sometimes after 200501:
Definition: An interface is a device that unrelated objects -- objects
that are not related by class hierarchy -- can use to interact with
each other. An object can implement multiple interfaces.

Complexer and complexer. Note its use of the word “deviceâ€.

In its current incarnation (as of 2006-08-14) of the tutorial
http://java.sun.com/docs/books/tutorial/java/IandI/index.html,
interface is not particularly given a definition.

References:
Java lang spec, 2nd ed, 8.4.2 on Method Signature,
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#38649
Official Java documentation page for 1.5.0, where it calls itself API.
http://java.sun.com/j2se/1.5.0/docs/api/overview-summary.html

------------
This post is archived at:
http://xahlee.org/java-a-day/interface.html

Xah
(e-mail address removed)
∑ http://xahlee.org/
 
L

Lew

Xah said:
In a functional language, a function can be specified by its name and

Are you sure you know what a "functional language" is?
parameter specs. For example:
f(3)
f(3, [9,2])
f("some string")

This is not really "typical" syntax for a functional language. LISP, for
example, has the "function name" as an element of a list. (Some might argue
that LISP isn't exactly a functional language.)

Also, since you are commenting on Java, you should use "Java-like" syntax
rather than "[9,2]". What is "[9,2]" intended to represent? The range of
integers decreasing from 9 to 2, inclusive?
For another example, usually a program needs to talk to another
software such as a database software.

Interesting use of the word "software".
In essence, making the database useful to other software.

This is not a sentence.
Such a list of function spec is often called API, which stands for Application
Programing Interface.

"an API"
The API terminology is abused by the marketing-loving Sun Microsystems
by calling the Java language's documentation as “The Java APIâ€, even
though Java the language and its paraphernalia of libraries and
hardware-emulation system (all together jargonized as “the Java
Platformâ€) isn't a Application nor Interface. (a [sic] API implies that
there are two disparate entities involved, which are allowed to
communicate thru [sic] it. In the case of “The Java APIâ€, it's one entity
talking to itself.).

This is incorrect in every factual detail. And what's with the editorial
comment in the middle of the exposition ("marketing-loving", "jargonized")?
How does that help explain the concepts, even if it were supportable by the
evidence?

Sun calls the API documentation "the Java API documentation", not "the Java
API", and not the language documentation, and the API is indeed an interface.
An API need not be, and quite often is not, an application - being an
application is in no wise part of being an API. And why in the world did you
capitalize "Application" and "Interface"?

It's "an API", not "a API". It's "through", not "thru".

The statement about an "API" having to do with "two disparate entities" makes
no sense. There is certainly nothing in the API that one can characterize as
"one entity talking to itself". What "entities" do you imagine are involved?
In general, the interface concept in programing is a sort of
specification that allows different entities to call and make use of
the other [sic], with the implication that the caller need not know what's
behind the facade.

There is no antecedent for "the other", and you haven't defined "entities",
and the word "interface" has a number of meanings "in general ... in
programming". You should focus on the Java meaning (and your grammar).
In the Object Oriented Programing Paradigm [sic], a new concept arose, that
is the “interface†aspect of a class.

Historical citation needed. And an interface is not an "aspect of a class".
As we've seen, a function has parameter spec [sic] that is all there it [sic] is a
user needs to know for using it. In Java, this is the method's
“signatureâ€. Now, as the methodology of the OOP experience multiplies,
it became apparent that the interface concept can be applied to
Classes as well. Specifically: the interface of a class is the class's
methods.

OK, I've had enough. I'd say you need a good editor to clean up the grammar,
but then all you'd have is a better-written incorrect explanation.

-- Lew
 
M

Markus E Leypold

Lew said:
Xah said:
In a functional language, a function can be specified by its name and

Are you sure you know what a "functional language" is?
parameter specs. For example:
f(3)
f(3, [9,2])
f("some string")

This is not really "typical" syntax for a functional language. LISP,
for example, has the "function name" as an element of a list. (Some
might argue that LISP isn't exactly a functional language.)


And nobody really cares, since syntax doesn't make a functional language anyways ...

Regards -- Markus
 
L

Lew

Dr. Who said:
Don't Feed The Trolls :)

But, but - you fed me!?

Oh, wait, I'm only a half-troll, on my father's side.

Thanks for the attention.

Kidding aside, a post like the OP's is useful as an exercise in finding the
errors, grammatical and factual. It's like a math book I had in my first year
at university. Its theorems were riddled with typographical errors, mixing the
us, vs and ws all around. I'd be up for hours figuring out if I was wrong or
the book was wrong. In the end it gave me a lot more exercise than the
homework problems did.

Also, I wanted to protect the innocent.

We could put up a contest - whoever finds and corrects the most errors in the
post wins. Ties broken by the quality of the correct explanations. Incorrect
explanations count against the entry.

-- Lew
 
J

Jim Burton

Dr. Who said:
Don't Feed The Trolls :)

But, but - you fed me!?
[blah]

We could put up a contest - whoever finds and corrects the most errors in the
post wins. Ties broken by the quality of the correct explanations. Incorrect
explanations count against the entry.

-- Lew

Or you could stop feeding the trolls.
 
L

Lew

Jim said:
Or you could stop feeding the trolls.

People need to stop saying that. The original post was a detailed if incorrect
exposition of Java information. How in the world do you rate that trollish?

I have absolutely no reason to rate the OP as a troll or their post as trollish.

-- Lew
 
S

Sherm Pendley

Lew said:
Does not apply. The OP was not being trollish

You obviously don't know Xah. He's been doing this for years, cross-
posting to various language groups trying to start an argument between
them. He even brags about being a troll on his web site.

sherm--
 
J

jim burton

People need to stop saying that. The original post was a detailed if incorrect
exposition of Java information. How in the world do you rate that trollish?

I have absolutely no reason to rate the OP as a troll or their post as trollish.

-- Lew

Oh, in that case welcome to usenet. Take a while to settle in. There's
this guy here called Xah and he is a troll.
 
N

Nigel Wade

Lew said:
People need to stop saying that. The original post was a detailed if incorrect
exposition of Java information. How in the world do you rate that trollish?

a) Xah's posting history.
b) the cross-posting
c) the advocacy of the contents
I have absolutely no reason to rate the OP as a troll or their post as trollish.

In time you will learn...

It wasn't even a good troll. To be a good troll the message actually needs to be
interesting enough to get people to read it.
 
L

Lew

Sherm said:
You obviously don't know Xah. He's been doing this for years, cross-
posting to various language groups trying to start an argument between
them. He even brags about being a troll on his web site.

OK - that last is telling. I believe in the possibility of redemption: if a
troll posts non-trollishly then I am willing to give them the benefit of the
doubt.

But if Xah were being trollish, why didn't they jump on my response and call
me names?

I still think that analysis of the original post is a useful exercise to learn
Java. It's one thing to know what's right - it's another to know what's wrong
and exactly why. The more subtle Xah or other minions of Satan get in their
presentations, the more interesting the forensic exercise to dig out the truth.

Perhaps I am just trying to make a silk purse out of a sow's ear.

-- Lew
 
J

John W. Kennedy

Lew said:
But if Xah were being trollish, why didn't they jump on my response and
call me names?

I'm not sure he's a proper troll. Unfortunately, he seems to be the kind
of person who thinks that reading "Java for Dummies" makes one a
self-sufficient expert on Java and philosopher of programming languages
to boot, and who is very eager to bestow upon the world all his
brilliant insights.

At least, that explanation is consistent with his historic behavior.

--
John W. Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the throne
of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"
* TagZilla 0.066 * http://tagzilla.mozdev.org
 
S

Sherm Pendley

Lew said:
But if Xah were being trollish, why didn't they jump on my response
and call me names?

Xah never replies to the threads he starts. At least, I've never known him
to do so.
I still think that analysis of the original post is a useful exercise
to learn Java.

Maybe so - I don't know enough Java to comment on that. But there's nothing
useful to cross-posting the original to a fistful of non-Java lists.
The more subtle Xah or other
minions of Satan get in their presentations, the more interesting the
forensic exercise to dig out the truth.

The truth is that Xah wants to start an argument. He cross-posts for that
reason, so that the "forensic exercise" you're speaking of then becomes an
argument among proponents of the various languages about which language is
closer to the "truth".

Don't take my word for it though - check Google Groups. You'll find he's
been doing this for a long time.

sherm--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top