Why extends HashMap and implements Map?

Hi,
I browsed the source of HashMap in JDK 5.0.
The declaration of the class puzzled me.
Declaration of HashMap:public class HashMap<K,V>
extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, SerializableDeclaration of AbstractMap:public abstract class AbstractMap<K,V> implements Map<K,V>Puzzle:
Now that AbstractMap has been declared to implement Map interface, and HashMap extends AbstractMap,
why HashMap is declared to implement Map interface again?
I don't think that's necessary.
a cup of Java, cheers!
Sha Jiang

I don't think it makes any difference that this code is part of the standard libraryAbsolutely, I agree on the view.
I think it was declared as such for clarity only.I just be curious with the little topic.
"clarity" may be the answer.
Thanks!

Similar Messages

Why extended Classic is implemented

Hi Everybody,
I was working in SAP SRM for past 3 years and only Support Experience. Yesterday attended an interview and he asked me why your client has implemented Extended Classic why not Classic Scenario?
I know it depends to client-to-client.
Can any one let me know the list of points need to be discussed to support this question. My answer was not impressive.
Sree

Hi Sree,
You are right here it depends on the client whether to configure the system for extended classic and classic scenario.
The extended classic scenario suits customer who wants to
their purchasing department to save time and money by using the streamlined purchasing functionality of SAP SRM
use the full sourcing capabilities offered by SAP SRM, yet who also want to be able to confirm and invoice direct materials
the flexibility of being able to pre-enter confirmations and invoices
Where the classic scenario suits the customer who wants:
wide user group, for example employees not necessarily working in the purchasing department, to be able to enter their requirements quickly and easily. SAP SRM’s functionality and ease of navigation allow this, as it requires only minimal training
their purchasing department to operate solely with the functionality offered by the backend system(s)
For whom a transfer of purchasing activities to SAP SRM is not viable in SAP SRM
You can use both the classic and extended classic capabilities by configuring the product categories
Please let me know if the above answer is helpful.
Best Regards,
Ankit Jain

Extending JEditorPane And Implementing Custom Attributes

I was experimenting with the following code :
class MyEditorPane extends JEditorPane
     private String str="";
     private boolean status=false;
     MyEditorPane(String str, boolean value)
          this.str=str;
          this.status=value;
     public String getString()
          return this.str;
     public boolean getStatus()
          return this.status;
}now I wanted to instantiate this class and then get the values by calling the get methods in the following manner :
MyEditorPane editor=new MyEditorPane("hii...",true);
System.out.println(editor.getString());
System.out.println(editor.getStatus());but the problem is that the instance *'editor'* doesn't seem to identify those two manually coded methods..........
can anyone please enlighten me as to what I have done wrong and is there any other way of implementing this concept of having my own attributes attached with a java component?
awaiting ur response.......

Are you getting a compile error? Or a runtime problem?
Are you sure that the MyEditorPane in the accessing code is the same MyEditorPane as in your example?
This works fine for me:
import javax.swing.JEditorPane;
class MyEditorPane extends JEditorPane {
    private String str = "";
    private boolean status = false;
    MyEditorPane(String str, boolean value) {
     this.str = str;
     this.status = value;
    public String getString() {
     return this.str;
    public boolean getStatus() {
     return this.status;
    public static void main(String[] args) {
     MyEditorPane editor = new MyEditorPane("hii...", true);
     System.out.println(editor.getString());
     System.out.println(editor.getStatus());
}Piet

We are using extends thread and implements runnable which class first calli

hi

Yes, the language allows it, but your JSL quote is the 3rd edition, and Java 1.4 is based on the 2nd edition (the 2nd edition of the JSL does not go into such a deep explanation of the example shown, so thanks for that pointer). In any case, since the JSL does not address my specific issue, it is only superficially relevant (IMHO). The language allows it, but the behavior is unpredictable. I think that's what is sticking in my craw. I'm not sure what the behavior should be, but if I had to, I would propose that the behavior should not change when I change the inheritance qualifiers (again, in this particular case), but there may be other considerations.
HibernateUtil is a snippet that can be found in the Hibernate tutorial/reference at [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html|http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html]
The basic idea is a cached session factory, because session factories are expensive to build. We use multiple databases, so our incarnation of HibernateUtil compares the requested database to the one in a static factory variable. If they match, that factory is used. If they don't match, the thread switches to the requested factory and creates sessions from it.
The odd thing is that with the aforementioned inheritance "typo", it either detects that the requested database is the same as the one in the static factory (which is not true), or it returns the wrong factory (which is wrong). I want to emphasize that no other code changes were made (zero, zip, none, really, I mean it), and lots of other classes extend C1 (from the example) and they have never had this problem.

Parameterized inheritance and implementation

I'm learning generics, and I'm having a problem getting the following to work
I have a base class with some data/behavior
public abstract Base<E> {
//...Then there is a concrete class that extends Base and implements Map
public Concrete<E extends Object & Map<K,V>> extends Base<E extends Object & Map<K,V>> implements Map<K, V>{
//...I cannot seem to specify that the type for Base must be a Map<K, V>.
I've thought about containing and delegating, but really Concrete IS-A Base and Concrete IS-A Map.
Am I missing something about inheritance and generics?
Any suggestions?

James,
Based on your previous posts I think you understand generics as well as I do, and in some aspects, probably better.
I was trying to capture my thought processes (and that is quite hard since mostly this happens sub-consciously - its quite hard to drag it up into consciousness then document it, but the effort was worthwhile for me and hopefully for others as well).
In this particular case, E is Map<K,V>, but there could be all sorts of relationships between the type variables, the idea is to identify these and back substitute them, slowly getting rid of type variables until you can't get rid of any more. The ones you are left with are the ones that need to be type parameters.
take the other post from yesterday
http://forum.java.sun.com/thread.jsp?thread=554360&forum=316&message=2719355
as another worked example...
from
"And I'm trying to create a special generic container (List) which would only take elements that
implement the Keyable interface above. For example:
public class ListOfKeyables <E extends Keyable> extends AbstractList<E>{..."
and
"Now, besides standard List methods that use type varable 'E' in their definitions, I would also
like to have a special method like this:
   public E getByKey(Object key)   {   ... "
I would start with (ignoring their "E extends Keyable" suggestion, its too premature for that).
public class ListOfKeyables < ???? > extends AbstractList<E> {
    public E getByKey(Object key) { ... }
} but "only take elements that
implement the Keyable interface" suggests replacing E with Keyable<K> thus
public class ListOfKeyables < ???? > extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(Object key) { ... }
Note In this case the substitution getting rid of E introduced another type variable (K), thats OK, its still a step toward a solution.
Then the original poster said "But I would like to constrain the 'key' argument in this method to be of type that is specified as a type parameter to the Keyable interface"
So after implementing this requirement we have
public class ListOfKeyables < ???? > extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(K key) { ... }
}At this point there is no more substitutions or requirements to fulfill.
So we look through and see what type variables are still unresolved. These (in this case there is only one K), are then the type parameters of the class, and thus we have what I suggested in that post
public class ListOfKeyables <K> extends AbstractList<Keyable<K>> {
    public Keyable<K> getByKey(K key) { ... }
}As a final step, we need to look at the type parameters and decide if they need any constraints (K extends something), These might come from some use of the type parameter ( such as if Keyable constrained its K parameter, we would need to do the same), or from the application requirements. But in this case, there are not any.
At a certain level of abstraction, this process is not a whole lot different to the process you use when working out what parameters a method or constructor needs (and that process also tends to happen below the consciusness threshold).
In really simplistic terms, the answer to both "what parameters do I need" questions is "all the ones you can't get from somewhere else or derive from the ones you already have".
Bruce

Why the HashMap implements the Map interface twice

See the type hierarchy below:
HashMap<K,V>
┃
┣AbstractMap<K,V>
┃┃
┃┗Map<K,V>
┗Map<K,V>
The HashMap extends AbstractMap, which implements Map. So the HashMap has already implements Map, and has the Map type. But the HashMap's declaration still contains "implements Map".
So why the HashMap implements the Map interface twice?
Thanks in advance.

georgemc wrote:
Maybe the guy who wrote HashMap wanted to make it clear that HashMap implemented Map, rather than rely on you looking further up the hierarchy to find outYes, it does make the Javadoc clearer. If they hadn't done that then there would have been legions of newbies who couldn't tell that HashMap implemented Map and thousands of "I have a doubt, does HashMap implement Map" questions here.

Concrete classes implement abstract class and implements the interface

I have one query..
In java collection framework, concrete classes extend the abstract classes and implement the interface. What is the reason behind extending the class and implementing the interface when the abstract class actually claims to implement that interface?
For example :
Class Vector extends AbstractList and implements List ,....
But the abstract class AbstractList implements List.. So the class Vector need not explicitly implement interface List.
So, what is the reason behind this explicit definition...?
If anybody knows please let me know..
Thanx
Rajendra.

Why do you post this question again? You already asked this once in another thread and it has been extensively debated in that thread: http://forum.java.sun.com/thread.jsp?forum=31&thread=347682

Extends and implements

"extends" => inheritance?
and "implements" => interface?
or the opposite?
and what is the difference between an
abstract class and interface?
Thanks in advance
Jack

EXTENDS
Yes, "extends" means inheritance.
E.g.:
public class Chihuahua extends Dog {
}So, from the moment you use "extends" we can say that Chihuahua IS-A Dog.
IMPLEMENTS
We use "implements" keyword when a class must implement one or more interfaces.
E.g.:
public class Chihuahua extends Dog implements SmallDog, NiceDog{
}Interfaces are a way to simulate multiple inheritance in Java language.
Now we also can say that a Chihuahua IS-A Dog, IS-A SmallDog and IS-A NiceDog. Yes, interfaces also causes IS-A relationships.
ABSTRACT CLASSES x INTERFACES
Well, some book authors says that interfaces are a more "pure version" of a abstract class. If you don't know yet, all methods of a interface are abstract, that is: the class that implements an interface MUST (with no exceptions) implements (override) all his methods. Is also important to know that all methods in a interface has a header only (no implementation), for instance:
public interface SmallDog {
public abstract void walkFast( );
public abstract void hiddenBelowTheDesk( );
}But why all methods of an interface must not be implemented? Simply because they are abstract.
An abstract class can contain OR NOT abstract methods. In mention of the abstract methods the behavior of a class that inherits from a abstract class is the same. Look this example:
Dog.java
public abstract class Dog{
   private String raceName;
   public abstract void bark();
   public abstract void run();
   public String getRaceName(){
      return this.raceName;
}You can see that we have two abstract methods: bark and run. It means that if a class extends from Dog it MUST override the methods bark and run methods. getRaceName is a method, but it isn't an abstract abstract method.
Now let's see the Chihuahua class again:
public class Chihuahua extends Dog{
private BigEye leftEye;
private BigEye rightEye;
private BigEar leftEar;
private BigEar rightEar;
public void bark(){
public void run(){
INTERFACES INHERITS FROM OTHER INTERFACES
Yes, it can sound crazy, but it is possible in Java. An interface can inherits from other interfaces. It ins't hard to understand. Based on the two interfaces SmallDog and NiceDog we will see how an interface can inherits from another one:
public interface CompleteCoolDog extends SmallDog, Nicedog{
}The interface CompleteCoolDog contains all methods from SmallDog and Nicedog, but is not obbligatory to implement them because an interface can not implement methods, only declare them. And who must implement them? The first concrete class that implements CompleteCoolDog interface.
You can see very nice informations about interfaces and abstract classes in the books of Kathy Sierra and Bert Bates (Study guides for SCJP).
I hope I helped you a little. Some doubt please, mail me.
See you =)

Extending and implementing

Is there a way to tell the compiler: this variable is of this class and implements that interface.
Say for instance a Component that implements ActionListener
extending component with an abstract class that implements ActionListener and then extend this class wouldn't work since then i can'T as well extend button textArea ect.

if(variable instanceof Component) {
//do something
if(variable instanceof ActionListener) {
//do something else
if( (variable instanceof Component) &&
(variable instanceof ActionListener) ) {
// really do something else
}

Difference between Extend and Implement

Hello guys, I still dont get it, i'm confuse, when to use Extend and when to use Implement . What's the big diference? Can anyone give me an idea?

I keep getting an error with this class which states: "Type parameter RectangleOperand is not within it's bounds"
import java.util.*;
public class RectangleOperand extends Rectangle2D.Double implements Addable<RectangleOperand>
    public RectangleOperand (double w, double h)
       super(0.0,0.0,w,h);
public static RectangleOperand readRectangle(Scanner scan)
    double doubleValue;
    doubleValue = scan.nextDouble();
    RectangleOperand rectangle;
    return rectangle = new RectangleOperand(w,h);
public boolean equalTo(RectangleOperand opnd2)
     boolean equal = true;
     if(this.width == opnd2.width && this.height == opnd2.height)
         equal = true;
     else
         equal = false;
     return equal;
public RectangleOperand plus(RectangleOperand opnd2)
     double newWidth, newHeight, width, height;
     newWidth = (this.width) + (opnd2.width);
     newHeight = (this.height) + (opnd2.height);
     RectangleOperand rectanglePlus = new RectangleOperand(newWidth,newHeight);
     return rectanglePlus;
}

Difference between extends and implements

hi
i am new to java. i need to know the difference between extends class implement class.
can anybody explain in simple words? i am new too oops concept also?
what are the conditions to use extends class, implement and interface?
class b extends a implements c
i know class a is a super class and class b is a sub class.
if class b extends class a means how should be the class a, what about the methods?
and class a implements class c means what should be the conditions?
i searched in Internet but the explanation is not very to me.can body explain me please?
thank you

sarcasteak wrote:
Your class can implement an interface, which means it must use the methods defined in the interface.No, it doesn't need to use them. It needs to implement them. Or be declared abstract.
Note that the methods in the interface are empty,No, they're not. They're abstract.
// empty method
void foo() {}
// abstract method
abstract void foo();(The abstract keyword is optional for interface methods, since they're all abstract.
and you have to define what they do in your class that implements the interface.Just like they have to for abstract methods in a class you extend, if the child class is not declared abstract.
There really isn't any difference between "extends" and "implements." There is no situation where you can choose. Any case where one is legal, only that one is legal. They could just as easily be a single keyword.
Presumably the OP's real question is, "When do I use a class for a supertype vs. using an interface for a supertype?" The answer to that, of course, is:
Use a class when at least some of the methods have valid default implementations. Use an interface when that is not the case. And of course the two are not mutually exclusive. It's quite common to do both.
At the end of the day, an interface is really nothing more than a class that has no non-final or non-static member variables and whose instance methods are all abstract, and from which you can multiply inherit.
Edited by: jverd on Feb 4, 2010 1:56 PM

Problem storing object extend HashMap

With Coherence 3.3.1/389 using extend TCP client.
We have our own customized HashMap implementation which extend java.util.HashMap<String,Object>.
The class are something like this :
public class SimpleMapStorage<T,V> extends HashMap<T,V> {
public SimpleMapStorage() {
super();
public SimpleMapStorage(Map<T, V> initMap) {
super(initMap);
However, if I put this object into a DistributedCache and try to get it back. The object return from get() operation will be a HashMap instead of SimpleMapStorage.
NamedCache cache = CacheFactory.getCache("Test");
SimpleMapStorage ss = new SimpleMapStorage();
cache.put("key", ss);
Object obj = cache.get("key"); // this object will be a HashMap object.
Any reason for this behavior? Or it's a bug?
Regards,
Chen

Hi Chen,
This is an expected behavior for the default POF serialization (used by the extend client).
Let me elaborate this bit. Let's assume that your did not extend HashMap at all. Then, unless you make Coherence aware of your class (most commonly, by registering it), you would not be able to put it into the cache at all.
Since you did not registered your SimpleMapStorage, the POF serializer only knows that it is a Map and uses a corresponding implementation (HashMap).
The simplest way to resolve the issue is to (i) make your class to implement PortableObject interface; (ii) register your class in a custom POF configuration descriptor; (iii) point to that descriptor in cache configuration descriptors: "initiator-config/serializer" (on the client side) and "acceptor-config/serializer" (on the proxy side).
Regards,
Gene

Class-Map and Policy-Map Configuration in CM Confusion

Hi,
I'm implementing a green field WAAS deployment for a customer. We currently have a Proof-of-Concept up and running.
I've got some questions regarding custom class-map and policy-map configuration in the CM. I'd like to nail-down the custom class-map and policy-map configuration (and understanding) in the PoC before cutting over the PoC branches to the production WAAS environment.
Assuming a typical WAAS Deployment using WCCP for off-path interception, branch to DC.
==> 61 in LAN (BRANCH ROUTER) <== 62 in WAN (WAN CLOUD) ==> 61 in WAN (DC ROUTER) <== 62 in LAN
We are using two distinct device groups, BRANCH and DATA CENTER.
If the customer has traffic that we need to classify in order to provide TFO only optimisation, should the single class-map include the traffic in both directions? Ie., (assume the SERVER is 10.1.1.1 TCP Port 443). Should the class-map be configured as:
Class-Map
Line 1: DST IP 10.1.1.1 DST Port 443
Line 2: SRC IP 10.1.1.1 SRC Port 443
Or in this case is only the DST line required? And in which Device Group should the custom policy be applied? Or should it be applied to both Device Groups? If it should be applied to both Device Groups, then would it make more sense to have the policy-map in the Branch DG configured to match the DST traffic, and on the Data Center DG have a different class-map match the SRC traffic?
My confusion is how to classify the traffic (SRC or DST or Both - Separate classes for each or different lines within the same class-map), and where to apply the appropriate policy (both Device Groups, just Branch, just DC) and why...
I tried to apply a custom policy and the impact in the PoC was that the TCP Summary report stopped reporting the individual traffic classes showed 'other traffic' only. Can anyone explain why this may have occurred?
I hope this makes sense.

for instance like this:
policy-map police-in
class class-default
police rate 10 mpbs <optionally set burst>
policy-map shape-out-parent
class class-default
shape 10 mpbs <optional burst config>
service-policy shape-out-child
policy-map shape-out-child
class class-default
queue-limit 10 packets
int g 0/0/0/0
service-policy police-in in
service-policy shape-out-parent out
also have a look at CL 2013/2014 (orlando/sanfran) ID 2904 for more QOS details
and the support forum article of "asr9000 quality of service architecture"
xander

Role, Extended Name and WSCI name

Hi all,
When adding an application component to an integration scenario, it is possible to configure the above three pieces of data, namely Role, Extended Name and WSCI name.
I was wondering what exactly the usage of these fields are. I was hoping to configure values for them and use them at runtime, but even when set they do not appear, so far as I can tell, in the runtime cache or the message header itself. Does anyone know
a) what they are used for and why they are configurable
b) if the values set in these fields are available (specifically in the Adapter Framework) at runtime?
Another way of solving the same issue I am having would be to use the Alternative Identifier concept for Service, in the same manner as can be done for Communication Party, allowing for normalization. But whilst the Normalization tools allow for lookup of alternate id's for Service, I can see nowhere at all where these can be set... So I could retrive the information if only I could actually create it!
Does anyone therefore also know where and alternative identifier for Service may get set??
Many thanks,
Chris
Message was edited by: Chris Probert

Steve,
Thanks for the reply, and confirms what I was seeing that that info never reaches AF. I guess it is just there for use in the BPM? Or is it purely for display purposes in the integration scenario?
As for what I want to do, basically I want to "normalize" the Party and Service fields for outbound - that is outbound from XI - direction (I am writing a custom adapter which calls a third-party tool which itself uses a different format from XI for Service Identifiers and Party Identifiers.)
The Party normalization works perfectly for this, and I am able to successfully use it. But Service is slightly different. The AF provides lookup methods (e.g com.sap.aii.af.service.cpa.NormalizationManager.getAlternativeServiceIdentifiers) for alternative Service Identifier, the same as it does for Party, leading me to believe that it should be possible to treat Service ID the same as Pary Id's when Normalizing. But it seems that this may just be a blip in the API rather than anything else as there seems nowhere can this be set, nor does it appear in the message header the way that it does for Party. So I looked at the other Identifers for anything that would provide me with an ID for the Service which could be set at configuration time but which was not the actual service name used in XI (the third party tool uses a Service ID format that XI rejects as service name).
So I am now trying to use Header Mapping in the receiver instead to acheive this which I think will solve my problem but it would be nice if I could treat the Party and Service the same rather than have two different methodologies for achieving essentially the same end, i.e to map internal XI identifiers to External identifiers.
Cheers,
Chris

Help with generics - extending hashmap

I'm trying to extend the HashMap class to accept multiple values per key. I'd like .put(key,value) to put a single key/value pair. I'd like .get(key) to return a Vector<V> of all the values associated with key, and .get(key, index) to return a single value of type V for that key. I am using Eclipse 3.2 and Java 1.5.
The problem I am having is my .put(K key,V value) method won't compile, I get the error:
Name clash: The method put(K,V) of type OneToManyHashMap<K,V> has the same erasure as put(K,V> of type HashMap<K,V> but does not override it
My code (roughly):
public class OneToManyHashMap<K,V> extends HashMap<K, Vector<V>> {
    public V get(Object key, int index) { return get(key).get(index); }
    public V put(K key, V value) { ... }
    public V remove(Object key, int index) { return get(key)
}Yes, I know there is an extra > in the code. It's wasn't there when I typed the message and it's not there when I try and edit the message to remove it :(
Message was edited by:
jiggersplat

This is what was meant by a "has-a" relation:
public class OneToManyHashMap<K, V extends List<V>> {
    public Map<K, List<V>> map;
    public OneToManyHashMap() { map = new HashMap<K, List<V>>(); }
    public V get(K key, int index) { return map.get(key).get(index); }
    public void put(K key, V value) { map.get(key).add(value); }
    public void remove(K key, int index) { map.get(key).remove(index); }
}Needless to say, you will have to perform some checks to handle eventual NPE's.

Why extends HashMap and implements Map?

Similar Messages

Maybe you are looking for