Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Non-virtual Methods in Java

JavaFAQ Home » Story by Dr. Kabutz Go to all tips in Story by Dr. Kabutz


Bookmark and Share 2001-05-31 The Java Specialists' Newsletter [Issue 021] - Non-virtual Methods in Java

2001-05-31 The Java Specialists' Newsletter [Issue 021]

Non-virtual Methods in Java

Author: Dr. Heinz M. Kabutz

JDK version:

Category: Language

You can subscribe from our home page: http://www.javaspecialists.co.za (which also hosts all previous issues, available free of charge Smile

Welcome to the 21st issue of "The Java(tm) Specialists' Newsletter". In South Africa the age of adulthood is 21, so I hereby declare this newsletter to be "grown up". No more childish jokes, running in the streets or teasing Sun for writing such a stupid language Wink

This newsletter serves to illustrate why you should always recompile ALL your code when you get a new build of someone's library. It also, as a side issue, demonstrates how you can write non-virtual methods in Java.

Before I get started, a word of thanks to Dr. Jung for giving me this idea on Monday. I persuaded him to promise me another of his excellent newsletters, which should have been due at least this week, but he managed to deflect my attention with an idea that led to this newsletter.

Please take a few minutes to think of who you know that would be interested in receiving this newsletter and forward it to them.

Non-virtual Methods in Java

In C++ you can mark a method to be virtual", which tells the compiler that you will want to use the most derived method in the object hierarchy. Virtual therefore means that if you have a class A with method f() and a subclass B with the method f(), and you call the method f() on a handle of A pointing to a B, then B's f() gets called. If you left out the "virtual" keyword, it would cause A's f() to get called, i.e. it is bound at compile time, rather than runtime.

In Java, on the other hand, ALL methods are virtual, i.e. the most derived method is always called, unless of course (read on). During many of the Java courses I presented, I was faced with the question from hardened criminals (oh no, I meant C++ programmers) of why Java does not support non-virtual methods (these questions usually get asked by the same guys who ask why Java doesn't support multiple implementation inheritance and operator overloading *groan*).

Let's look at some code:

//: A.java

public class A {
  public void f() { System.out.println("A's f()"); }
}

//: B.java
public class B extends A {
  public void f() { System.out.println("B's f()"); }
}


//: C.java
public class C {
  public static void main(String[] args) {
    A a = new A();
    a.f();
    ((A)new B()).f();
    B b = new B();
    b.f();
  }
}

When we run this, we get the result of:

A's f()
B's f()
B's f()

A typical question for the Sun Certified Java Programmer exam, and quite obvious to most of us.

The question is, if I have an object of instance B, is it possible to call its parent's f()? Consider class D:

//: D.java
import java.lang.reflect.*;
public class D {
  public static void main(String[] args) throws Exception {
    Method f = A.class.getDeclaredMethod("f", new Class[0]);
    f.invoke(new A(), new Object[0]);
    f.invoke((A)new B(), new Object[0]);
    f.invoke(new B(), new Object[0]);
  }
}

We are calling f() of class A, but still, the output remains:

A's f()
B's f()
B's f()

A few months ago, I was asked about this and after battling for a while, gave up and declared that it is not possible to run class C and get the output of:

A's f()
A's f()
B's f()

Now for a little trick that changes all that, we simply make f() private in A and recompile ONLY A:

//: A.java
public class A {
  private void f() { System.out.println("A's f()"); }
}

We have not recompiled B, C or D, so when we run C, we expect to get some warning or error, but alas, our output for C becomes:

A's f()
A's f()
B's f()

I tried this out using the JDK 1.3.0_01 and JBuilder 3.0 JDK 1.2 and it worked without problems. Please send me a note if you find a version of Java that somehow gives back a VerifyError or an AccessException.

Our class D does not work, but gives us a runtime error, because A.f() is now private. This is the first time where I've seen reflection resulting in safer code!

When should you use this idea? Please don't, but please at the same time be aware that if you get a new library, even if it's the same version number, you have to recompile every line of your Java code, just to be sure.

A better way of achieving the same goal of non-virtual methods is to use static methods which we then pass a handle to an instance of the class. This much clearer approach was suggested by a founding member of The Contractor's Guild.

//: A.java
public class A {
  public static void f(A a) { System.out.println("A's f()"); }
}


//: B.java
public class B extends A {
  public static void f(B b) { System.out.println("B's f()"); }
}

//: C.java
public class C {
  public static void main(String[] args) {
    A a = new A();
    a.f(a);
    a = new B();
    a.f(a);
    B b = new B();
    b.f(b);
  }
}

In summary, always remember to recompile all your classes, since you don't know which ones will be affected by someone else's change!

---
Warning Advanced:
In JDK 1.1.x, final methods were inlined at compile-time, further necessitating a complete compile if a library was changed.
---

Thanks for taking the time to read this newsletter, please also take the time to give me feedback, I always appreciate it.

Heinz


Copyright 2000-2004 Maximum Solutions, South Africa

Reprint Rights. Copyright subsists in all the material included in this email, but you may freely share the entire email with anyone you feel may be interested, and you may reprint excerpts both online and offline provided that you acknowledge the source as follows: This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information.

Java and Sun are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Maximum Solutions is independent of Sun Microsystems, Inc.

 Printer Friendly Page  Printer Friendly Page
 Send to a Friend  Send to a Friend

.. Bookmark and Share

Search here again if you need more info!
Custom Search



Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy