interfaces

[manoj kumar]

can an interface have non-abstract methods?
------------------
[email][email protected][\email]

[Carl Trusiak]

Originally posted by manoj kumar:
can an interface have non-abstract methods?

Per the JLS - No
9.4 Abstract Method Declarations
AbstractMethodDeclaration:
AbstractMethodModifiersopt ResultType MethodDeclarator Throwsopt ;
AbstractMethodModifiers:
AbstractMethodModifier
AbstractMethodModifiers AbstractMethodModifier
AbstractMethodModifier: one of
public abstract
The access modifier public is discussed in �6.6. A compile-time error occurs if the same modifier appears more than once in an abstract method declaration.

Every method declaration in the body of an interface is implicitly abstract, so its body is always represented by a semicolon, not a block.

Every method declaration in the body of an interface is implicitly coderanch.

[Anonymous]

Just a question that has lingered and may be obvious but how does an interface provide any of its function if there is nothing but empty methods that must be implemented?
It seems like there's a simple answer but my logical powers are not going there.
Anyone?

[Khalid Bou-Rabee]

I guess that they are implemented in the Java Virtual Machine, or in the compiler via C or native language.

[Junaid Bhatra]

An interface in itself doesn't provide any functionality. The classes which implement an interface have to provide the implementation. You can think of an interface as a contractual agreement. The classes which implement an interface are bound by the contract to provide functionality for all of the methods declared in the interface (otherwise the class has to be declared abstract). Hope this helps!

[Anonymous]

If the interface doesn't provide any functionality then why not have your own original methods rather than overriding empty methods from it. You see my confusion? Its as if by contractual agreement, that I will implement all of the methods in the interface, that I am buying (by contracting) what I can simply give to myself for free. My understanding is that in an interface ALL methods are abstract. I can override (to implement it) an actionPerformed() method that runs or a run() method that actionPerforms (so to speak). It appears as though all that I get from an interface are names that I can use (that I MUST use!) for my own methods (which I could give myself without implementing an interface) and some constants. Do you see how there must be some grave misunderstanding on my part as to how a interface must be more than a constraint that forces you to use certain names for your methods? I know that it is more than that but this hole in my conceptual overview remains when I attempt to contemplate it based upon what I know.
I suppose I don't need to know as long as I can use them as necessary. Perhaps an interface does just provide a common method name for functions that other classes need to be able to identify such as the Thread class needing a run() method. Still why override a method and declare implementation of an interface rather than simply having a run() method in your class outright? It seems like I have a fundamental misunderstanding somewhere on this subject.

[rajsim]

For example given by you, if you don't implement Runnable
interface, how do you guarantee that you will supply "run"
method? You say, by just providing it.
But how will compiler verify that you have indeed supplied
"run" method? It can not. Now you can pass any object to
Thread constructor and it will not complain until it
starts executing but can not find "run" method supposed to
be provided.
This will lead to run time errors.

[Anonymous]

Hi Meadowlark_B,

Interfaces ?? ah! it takes time and patience to understand them. it did take time for me.
Part I:
Before 1.2 Collections u had Vector, and HashTable. How did u add and element to them. U used addElement for vectors and put for Hashtable. do u remember these when asked randomly in a future time. NO!!! u don't.
Now comes Collection interface. u know that all classes implementing collection interface have an add method. thus whether they be Hashset or LinkedList or ArrayList u know add is there. thus u use add in any collection.
Keeps things simple isn't it.
Part II.
Makes OOPS easier and posible. Let me give u an example
Collection i=new LinkedList();
i.add("X");
i.add("y");
i.add(z");
....
now in a later date i realize that Oh! i have made a mistake i should have used a HashMap instead. what do i do?.
change one line of code

Collection i= new HashMap();
that's it. everything else works perfectly. No other modifications are required. compare this with if i wanted to use a HashTable. ah!!! i have to remove all "add", and replace them with "put". make revelent changes to each and every place where some methods are invoked. compile and debug code all over again. I would die!!!.

Part III.
Interfaces are contracts as u already know. the implementing classes must implement the same signatures and return type. This is checked at compile time itself not at runtime. This is useful to the developer as any errors he makes are known before hand itself. thus if a class implements a WindowListener then if any of the abstract methods are missing then the compiler complains. The methods may be missing as the developer has not declared them or declared them wrongly.
Part IV
I believe that Java is nothing but interfaces. Sun is constantly giving us interfaces be it for JDBC, EJB or other areas. Vendors implement these interfaces to gives us the needed platform independence and vendor independence. thus one program created by JDBC on Oracle can be used on any other RDBMS just by changing the driver.
Part V
A programer too can use these interfaces to create classes that r specific to his needs. Another user can use these classes easily as he knows that they implement these interfaces.
for example u can create u r own collection class implementing the collection interface and give it to someone else to use. The user does not need to struggle to find out how to use as he already knows the add() method of collection or the remove() method.
Thus the implementation has changed but not the interface and causes no consequential changes to other code.
Hope i have clarified things abundantly. Do post for further queries.
Regds.
Rahul.

[This message has been edited by rahul_mkar (edited July 16, 2000).]

[Uthirapathi Prabu]

Implicitly ,All the methods in the interface are public and abstract.
Thanx.
Praboo.u