Can You Write Virtual Functions/Methods in Java

Can you write virtual functions / methods in Java?

From wikipedia

In Java, all non-static methods are by
default "virtual functions." Only
methods marked with the keyword final,
which cannot be overridden, along with
private methods, which are not
inherited, are non-virtual.

Java - Virtual Methods

Yes, virtual methods are treated differently by the compiler and the runtime. The JVM specifically utilizes a virtual method table for virtual method dispatch:

An object's dispatch table will
contain the addresses of the object's
dynamically bound methods. Method
calls are performed by fetching the
method's address from the object's
dispatch table. The dispatch table is
the same for all objects belonging to
the same class, and is therefore
typically shared between them. Objects
belonging to type-compatible classes
(for example siblings in an
inheritance hierarchy) will have
dispatch tables with the same layout:
the address of a given method will
appear at the same offset for all
type-compatible classes. Thus,
fetching the method's address from a
given dispatch table offset will get
the method corresponding to the
object's actual class.

Virtual Functions in C++ and Java

Yes.. the role of virtual comes into picture if and only if you have are trying to access the derived class object with a base class pointer.

With you example:-

#include <iostream>

class base{
    public : 
        virtual void function1(){
            std::cout<<"BaseVirtual"<<std::endl;
        }

        void function2(){
            std::cout<<"Base NonVirtual"<<std::endl;
        }
};

class derieved: public base
{
    public : 
        void function1(){
            std::cout<<"Derieved Virtual"<<std::endl;
        }

        void function2(){
            std::cout<<"Derieved NonVirtual"<<std::endl;
        }
};

int main()
{
    base *b1;
    derieved d1;

    b1=&d1;

    b1->function1();
    b1->function2();    
    return 0;
}

output:-

Derieved Virtual
Base NonVirtual

Why should virtual functions not be used excessively?

You've posted some blanket statements that I would think most pragmatic programmers would shrug off as being misinformed or misinterpreted. But, there do exist anti-virtual zealots, and their code can be just as bad for performance and maintenance.

In Java, everything is virtual by default. Saying you shouldn't use virtual functions excessively is pretty strong.

In C++, you must declare a function virtual, but it's perfectly acceptable to use them when appropriate.

I just read that we should not use virtual function excessively.

It's hard to define "excessively"... certainly "use virtual functions when appropriate" is good advice.

People felt that less virtual functions tends to have fewer bugs and reduces maintenance.
I'm not able to get what kind of bugs and disadvantages can appear due to virtual functions.

Poorly designed code is hard to maintain. Period.

If you're a library maintainer, debugging code buried in a tall class hierarchy, it can be difficult to trace where code is actually being executed, without the benefit of a powerful IDE, it's often hard to tell just which class overrides the behavior. It can lead to a lot of jumping around between files tracing inheritance trees.

So, there are some rules of thumb, all with exceptions:

• Keep your hierarchies shallow. Tall trees make for confusing classes.
• In c++, if your class has virtual functions, use a virtual destructor (if not, it's probably a bug)
• As with any hierarchy, keep to a 'is-a' relationship between derived and base classes.
• You have to be aware, that a virtual function may not be called at all... so don't add implicit expectations.
• There's a hard-to-argue case to be made that virtual functions are slower. It's dynamically bound, so it's often the case. Whether it matters in most of the cases that its cited is certainly debatable. Profile and optimize instead :)
• In C++, don't use virtual when it's not needed. There's semantic meaning involved in marking a function virtual - don't abuse it. Let the reader know that "yes, this may be overridden!".
• Prefer pure virtual interfaces to a hierarchy that mixes implementation. It's cleaner and much easier to understand.

The reality of the situation is that virtual functions are incredibly useful, and these shades of doubt are unlikely coming from balanced sources - virtual functions have been widely used for a very long time. More newer languages are adopting them as the default than otherwise.

Abstract/Virtual Functions in java

As I mentioned in my comment private functions are not virtual and I want to demonstrate it using following example:

class A {
    public void foo() {
        System.out.println("A#foo()");
    }

    public void bar() {
        System.out.println("A#bar()");
        qux();
    }

    private void qux() {
        System.out.println("A#qux()");
    }
}

class B extends A {
    public void foo() {
        System.out.println("B#foo()");
    }

    private void qux() {
        System.out.println("B#qux()");
    }
}

Now lets run following code:

A foobar = new B();
foobar.foo(); // outputs B#foo() because foobar is instance of B
foobar.bar(); // outputs A#bar() and A#qux() because B does not have method bar 
              // and qux is not virtual

Why not have all the functions as virtual in C++?

There are good reasons for controlling which methods are virtual beyond performance. While I don't actually make most of my methods final in Java, I probably should... unless a method is designed to be overridden, it probably shouldn't be virtual IMO.

Designing for inheritance can be tricky - in particular it means you need to document far more about what might call it and what it might call. Imagine if you have two virtual methods, and one calls the other - that must be documented, otherwise someone could override the "called" method with an implementation which calls the "calling" method, unwittingly creating a stack overflow (or infinite loop if there's tail call optimization). At that point you've then got less flexibility in your implementation - you can't switch it round at a later date.

Note that C# is a similar language to Java in various ways, but chose to make methods non-virtual by default. Some other people aren't keen on this, but I certainly welcome it - and I'd actually prefer that classes were uninheritable by default too.

Basically, it comes down to this advice from Josh Bloch: design for inheritance or prohibit it.

Why isn't hiding of virtual functions/methods allowed in Java and C++?

You guessed correctly, "polymorphic" is the key word :)
Polymorphism means that, if Y is a subclass of X, then Y effectively is X, and can be used as X anywhere.

Now, that means, if X has a method void k(), then Y must also have the same method (otherwise, you would not be able to use it as X). But you cannot have two different methods with the same signature, and therefore Y.k() must also return void (otherwise, it would be a different method).

In C++ case, non-virtual functions aren't polymorphic: A.k and B.k are two completely different methods in that case, and therefore there is no restriction.

To put it simply, let's change your example a little bit: suppose, that you defined X.k to return int, and Y.k() as void. Imagine a function like this:

     int plusOne(X x) {
        return x.k() + 1
     }

This should compile and work, right? But what about plusOne(new Y())?
This must also work, because Y is X ... but, if it was possible for Y.k() to return a void, what would plusOne do with it?

Virtual Functions during Construction. Why Java is different than C++

Java has a very different object model from C++. In Java, you cannot have variables which are objects of class type -- instead, you can only ever have references to objects (of class type). Therefore, all members of a class (which are only references) start out trivially as null until the entire derived object has been set up in memory. Only then do the constructors run. Thus by the time a base constructor calls a virtual function, even if that function is overridden, the overridden function can at least correctly refer to members of the derived class. (Those members may not themselves be assigned yet, but at least they exist.)

(If it helps, you can also consider that every class without final members in Java is technically default-constructible, at least in principle: Unlike in C++, Java has no such things as constants or references (which must be initialized in C++), and in fact there are no initializer lists at all. Variables in Java simply don't need to be initialized. They're either primitives which start as 0, or class type references which start as null. One exception comes from non-static final class members, which cannot be rebound and must actually be "initialized" by having precisely one assignment statement somewhere in every constructor [thanks to @josefx for pointing this out!].)

---

Related Topics