Re: HashMap get/put

According to Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>:


Class A defines method foo() which is final. Class B extends A and
inherits foo(). Compile both classes into files A.class and B.class.

Class C includes code like this:
  A a = new B();
  a.foo();

Compile class C into C.class, while A.class and B.class are in the
classpath.

Now modify A.java to remove the 'final', and add an implementation
of B.foo() which overrides the now non-final A.foo(). Recompile
A and B into A.class and B.class without touching C or C.class.

Then run. Things work: the C.class, even though compiled with regards to
the old A.class and B.class, can use the new versions, and the foo()
method actually invoked is the one from B, not A.

That it works that way is clear enough when you look at the classfile
format. Calls are by name, and the 'final' modifier is not part of
the information stored in the call site.


Having virtual methods by default means that when you write your class,
whenever a method is called, then it is your own. E.g., you write
an AccountingOutputStream which counts how many bytes are written:

public class AccountingOutputStream extends OutputStream {

    private OutputStream sub;
    private long count = 0;

    public AccountingOutputStream(OutputStream sub)
    {
        this.sub = sub;
    }

    public void write(int b)
        throws IOException
    {
        sub.write(b);
        count ++;
    }

    public void write(byte[] buf, int off, int len)
        throws IOException
    {
        sub.write(buf, off, len);
        count += len;
    }

    public void flush()
        throws IOException
    {
        sub.flush();
    }

    public void close()
        throws IOException
    {
        try {
            flush();
        } catch (IOException ioe) {
            // ignored
        }
        sub.close();
    }
}

This code works because whenever all the methods are virtual (in C++
terminology): the AccountingOutputStream instance knows that every
single data byte necessarily goes through its methods, even if the
caller knows the instance under the generic OutputStream type.

That is the kind of safety which Java designers were looking for.


Actually not. This is a misnomer: the notion of "virtual" in C# is not
what is meant by "virtual" in C++. C#, like Java, does not have what
is a non-virtual method in C++.

In C#, you cannot override a method unless the base method was
explicitly tagged with the 'virtual' keyword, and the override uses the
'override' keyword. This is the dual of Java's 'final' method: every
method is final unless stated otherwise. Yet, neither C# nor Java
features the method resolution by static expression type, which is the
hallmark of C++ non-virtualness: when class Z has a specific
implementation of method foo(), and some code invokes foo() on an
instance which happens to be of class Z, then this is Z.foo() which is
called, regardless of the type under which the caller knows the
instance.

In brief, in C++ terminology, all C# methods are virtual, just like
Java methods. The 'virtual' keyword of C# does not have the semantics
of the 'virtual' keyword in C++; it is more like the antithesis of
Java's 'final'.

As a side note, if you write class A and method foo() which calls method
bar() on the same class, and you worry about another class overridding
bar() and intercepting your call, then the usual workaround involves
using 'private', not 'final': you rename bar() into barInternal() and
make it private, and call barInternal() from foo(). Then you define a
public wrapper bar() which simply calls barInternal().

    --Thomas Pornin