HashMap's Map.Entry interface

Hello and good day to you all!

I was confused about some Map theory and was hoping someone could help me sort it out.

I have been reading the older 1.4 version of Ivor Horton�s Beginning Java, and am on the section about HashMaps. Now, he talks about one can get a Set of entries from the HashMap using the entrySet() method.

Now, here�s the rub. The contents of this set are objects of type Map.Entry. But here is what threw me:

�The key/object pairs are of type Map.Entry because Entry is an interface declared within the Map interface.�

Interface?! But Horton says in Chapter 06:

�The declaration of the class as abstract is mandatory when you don't implement all of the methods that are declared in an interface.�

It seems that Map.Entry is abstract, since it appears that the five methods contained in the class (http://java.sun.com/j2se/1.4.2/docs/api/java/util/Map.Entry.html) have not been implemented. Or have they�

In Horton�s HashMap section, Horton refers to the Set elements as Map.Entry objects.

In addition, look at this code from Oracle (http://www.oracle.com/technology/pub/articles/maps1.html) :

Iterator keyValuePairs1 = aMap.entrySet().iterator();
for (int i = 0; i < mapsize; i++)
{
Map.Entry entry = (Map.Entry) keyValuePairs1.next();
Object key = entry.getKey();
Object value = entry.getValue();
...
}

Again, we use an interface to create an object? So, here is the million dollar question:

** Did HashMap likely implement the Map.Entry interface?

My thinking goes like this: Map is an interface, which also nests another interface within it: Map.Entry. However, Map.Entry is static, so we don't need to implement Map.Entry with a Map implementation.

Also, a corollary:

** Could the five methods be overridden by either extending HashMap or by creating a class with a HashMap member, thereby potentially controlling access to the HashMap?

Much obliged!
-gabe

Welcome to the Ranch.

Have you looked in the official source? Here, for Map, HashMap, and Map.Entry?

Map is an interface which defines which methods each Map type has to implement; how they are implemented is in the HashMap documentation, where you find how it implements the entrySet() method. This returns a Set, which provides an Iterator.
Use the Iterator in the normal fashion and it provides an object of a class (probably anonymous) which implements the Map.Entry interface from its next() method, as usual. You have already shown how you can get the Value and Key from the entry objects. Try the other three methods, equals, hashCode and setValue, and see whether they work. They must have been implemented, otherwise the compiler wouldn't have compiled the class in the first place.

Yes, HashMap implements the Map interface and also implements its nested interface Map.Entry.
Yes, you could extend HashMap, or control access by making it a private member of another class and using delegate methods to allow access. Ditto the nested Entry interface.

But you can't override the public methods to become private methods. Java overriding and inheritance tries to maintain the Liskov substitution principle, that the methods of a subclass must provide the functionality of the superclass so that the calling method doesn't "know" whether the superclass or subclass method is being called. Restricting access of a public superclass method would violate this principle and the compiler won't allow it. And you must make sure that all the methods fulfill the requirements of the original Map interface, otherwise you aren't really implementing them.

I presume you are familiar with the anonymous class? You can writeYou can even add fields and a constructor.

Originally posted by Campbell Ritchie:
Yes, HashMap implements the Map interface and also implements its nested interface Map.Entry.

Well technically HashMap does not implement Map.Entry itself. It does have some, unknown* internal class that does implement Map.Entry. The thing is, you don't need to know the exact class - all you need to know is that it does implement Map.Entry, and therefore implements those 5 methods. If you call getKey(), it returns the key. If you call getValue(), it returns the value. If you call setValue(), it sets the value and returns the old value.

This principle is used throughout the Java API (and many other APIs). The iterator() methods of collections returns an object of some unknown class that implements Iterator. keySet(), entrySet() and values() in maps return some set or collection. Most of the JDBC model is based on this principle.

Also note that the return type does not need to be an interface - it can be an abstract class as well. All you need to know is that it implements the interface or extends the abstract class, and you therefore know what methods (and possibly fields) are available for certain.

* Well, except when you look in the source of HashMap

Thank you both for your technical knowledge. After doing some more reading and cogitating over your responses, I believe I am beginning to understand these topics a bit better, complex though they are.

The other thing in Ivor Horton's source code was his assignation of variables to the generic, unimplemented Map.Entry interface! Then, after looking back in the book, I found this gem:

..you [can] use [an interface] to store a reference to an object of any class type that implements [the interface].

Complex, yet powerful. I am finishing my undergraduate CS degree this winter, and I am trying to familiarize myself with basic data structures since I might be using them.

The responses again were great - much obliged. I'm already poking my nose in other boards to learn new things. Great stuff!