wood burning stoves*
The moose likes Beginning Java and the fly likes explanation of Interface concept Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "explanation of Interface concept" Watch "explanation of Interface concept" New topic
Author

explanation of Interface concept

John Davis
Ranch Hand

Joined: Nov 02, 2000
Posts: 183
I have read the explanation of what a Java Interface is and consequently understand that it is a template for a class and as such cannot be implemented.
But given this, how is the Java statement


to be understood? On the surface, it looks like the code instantiates an object named
queue
from a interface. If this Java program were to run, where would it find the implementation of the methods defined (and required) by
??
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

It declares a variable of the Queue type, and assigns the null reference to the variable. No object is created.
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

If this Java program were to run...

Almost forgot: if no other changes are made and the code attempts to call a method using the 'queue' variable, the JVM will exit with a NullPointerException.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

But let me answer your next question: soon you'll find a piece of code like

javax.jms.Queue queue = getQueueFromSomewhere();

and now "queue" does point to something. Very often the Padawan will ask, "Well how can that be, as an interface can't be instantiated?" The answer is that this is really the whole point of interfaces. getQueueFromSomewhere() claims to return a Queue, but what it will really return is an instance of a class that implements the Queue interface. The actual name of this class is of no importance to you. All you know -- all you need to know -- is that that object has all the methods in the Queue interface available on it; therefore, it is a Queue.

This is used very often in provider frameworks like JMS. There are many different Queue implementations provided by different vendors. But you can write vendor-neutral code simply by programming to the interface. You don't need to know the actual class names used by the vendor.


[Jess in Action][AskingGoodQuestions]
John Davis
Ranch Hand

Joined: Nov 02, 2000
Posts: 183
OK. Thanks for that reply.

So what if the statement is:





?

This would create an object, right? But where would the implementation come from? Both javax.jms.Queue and Queue are interfaces which cannot be implemented in themselves.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

That code is illegal, as Queue is an interface, not a class. You can't construct a Queue -- you can only construct an instance of a class that implements Queue. So, for example, this is legal:



Aren't javax.jms.Queue and Queue the same interface, or is this discussion more complex than I'm realizing?
John Davis
Ranch Hand

Joined: Nov 02, 2000
Posts: 183
Thanks Ernest, your reply got me started.

However, questions remain.

#1. since both javax.jms.Queue and Queue are interfacia, does the resulting object represent a superset of data/methods from both, or is it limited to javax.jms.Queue.

#2. does the implementation of GetQueueFromSomewhere() return an instance of a class which knows the limitations and requirements of javax.jms.Queue?
(I guess that this is obviously "yes")

#3. What is a Padawan? I trust that I am one, but haven't found this word in a dictionary.

#4. In my jms code, it appears GetQueueFromSomewhere () is a method from yet another interface (javax.jms.QueueSession). Apparently, it is normal practice to hide implementations within hierarchies of interface indirections. I guess this is desirable behavior, but in the JMS case that I am working on, it is frustrating. The interfaces I am working with do not provide exposure methodology for data which is obviously hidden within an object deep inside the interface hierachy. Is it the grand plan for me (and developers in general) to just give up trying to find out what is going on?
John Davis
Ranch Hand

Joined: Nov 02, 2000
Posts: 183
Ernest,

Thanks again for your reply. Of course, again, I am wrong for
javax.jms.Queue and Queue refer to the same interface.

I'm just having difficulty understanding where the buck stops and if I'm ever going to be in a position to see an implementation.

Thanks for your patience.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

Originally posted by John Davis:
Thanks Ernest, your reply got me started.
#2. does the implementation of GetQueueFromSomewhere() return an instance of a class which knows the limitations and requirements of javax.jms.Queue?
(I guess that this is obviously "yes")


Yes, exactly; in particular, it could return an instance of the "MyQueue" class I sketched out above.


#3. What is a Padawan? I trust that I am one, but haven't found this word in a dictionary.


A Jedi apprentice. Sorry. Just a nicer way to say "newbie."


#4. In my jms code, it appears GetQueueFromSomewhere () is a method from yet another interface (javax.jms.QueueSession). Apparently, it is normal practice to hide implementations within hierarchies of interface indirections. I guess this is desirable behavior, but in the JMS case that I am working on, it is frustrating. The interfaces I am working with do not provide exposure methodology for data which is obviously hidden within an object deep inside the interface hierachy. Is it the grand plan for me (and developers in general) to just give up trying to find out what is going on?


Excellent question. The answer is both yes, and no. On the one hand, yes, you're not supposed to write code that depends on these details, because by definition, there are multiple implementations of an interface, and each one is going to be different. If you only write code that works with the interface, then your code works with all the implementations. Something like JMS is designed, as I said, so that different vendors can provide different plug-in implementations, and you can write code which works with any of them. WHereas one vendor's implementation may have the data you seek, another might not -- and of course, the mechanism of getting it would be different for each implementation. JDBC (the database API) is another perfect example of this kind of setup.

But the answer is "no", also -- if you're interested in how an implementation works, them you need to get the source for an implementation, and study it. Just remember that at runtime, your code might be using some other implementation, so all you should take from this exercise is insight, rather than specific coding details.
[ October 28, 2005: Message edited by: Ernest Friedman-Hill ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: explanation of Interface concept
 
Similar Threads
Collections..
JMS::Websphere6.1::Problem with context lookup the Queue
Problem in Deploying MDB bean
Configure/Access remote Message Queue (Sun's Open MQ) on Nework
access jms queue from different servers