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
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> 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
Dr. Who wrote:
> 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
On 21 Mar, 19:11, Lew <····@nospam.lewscanon.com> wrote:
> Dr. Who wrote:
> > 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.
Jim Burton wrote:
> Or you could stop feeding the trolls.
Does not apply. The OP was not being trollish, they were being spammish.
-- Lew
From: Sherm Pendley
Subject: Re: On Java's Interface (the meaning of interface in computer programing)
Date:
Message-ID: <m2slbxbg57.fsf@local.wv-www.com>
Lew <···@nospam.lewscanon.com> writes:
> Jim Burton wrote:
>> Or you could stop feeding the trolls.
>
> 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--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Sherm Pendley wrote:
> Lew <···@nospam.lewscanon.com> writes:
>
>> Jim Burton wrote:
>>> Or you could stop feeding the trolls.
>> 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.
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
From: Sherm Pendley
Subject: Re: On Java's Interface (the meaning of interface in computer programing)
Date:
Message-ID: <m2lkhna902.fsf@local.wv-www.com>
Lew <···@nospam.lewscanon.com> writes:
> 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--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jim Burton wrote:
> 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
On 22 Mar, 12:45, Lew <····@nospam.lewscanon.com> wrote:
> Jim Burton wrote:
> > 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
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.
From: Slartibartfast
Subject: Re: On Java's Interface (the meaning of interface in computer programing)
Date:
Message-ID: <ArxMh.10950$Ng1.3575@newsfe19.lga>
"jim burton" <··········@gmail.com> wrote in message
·····························@n59g2000hsh.googlegroups.com...
> On 22 Mar, 12:45, Lew <····@nospam.lewscanon.com> wrote:
>> Jim Burton wrote:
>> > 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
>
> 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.
>
Why oh why does anyone even bother to respond to Xah Lee? See the true Xah
at:
http://node60091.multiply.com/photos/album/1
WARNING: Nudity!!! Not family- or work-friendly!!!
From: Nigel Wade
Subject: Re: On Java's Interface (the meaning of interface in computer programing)
Date:
Message-ID: <etudbe$gbf$1@south.jnrs.ja.net>
Lew wrote:
> Jim Burton wrote:
>> 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?
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.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : ···@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
From: Markus E Leypold
Subject: Re: On Java's Interface (the meaning of interface in computer programing)
Date:
Message-ID: <l9mz26ivaq.fsf@hod.lan.m-e-leypold.de>
Lew <···@nospam.lewscanon.com> writes:
> Xah Lee wrote:
>> 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