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"!.

Easy Learn Java: Programming Articles, Examples and Tips - Page 487


Previous 1060 Stories (530 Pages, 2 Per Page) Next

Easy Java Lecture 13-2 Inheritance in Java. Teach/learn online

Go to all tips in Java Lectures by Anatoliy Malyarenko

Inheritance

by: Anatoliy Malyarenko

Abstract

  • Contents of the lecture.
  • Understanding inheritance.
  • Overriding methods.
  • Being a descendent of Object.
  • Writing final classes and methods.
  • Writing abstract classes and methods.
  • Implementing nested classes.

Managing inheritance

Recall that the extends clause declares that your class is a subclass of another. You can specify only one superclass for your class (Java does not support multiple class inheritance), and even though you can omit the extends clause from your class declaration, your class has a superclass. So, every class in Java has one and only one immediate superclass. This statement leads to the question, "Where does it all begin?"


As depicted in the following figure, the top-most class, the class from which all other classes are derived, is the Object class defined in java.lang.


The Object class defines and implements behaviour that every class in the Java system needs. It is the most general of all classes. Its immediate subclasses, and other classes near top of the hierarchy, implement general behaviour; classes near the bottom of the hierarchy provide for more specialised behaviour.

Definition 1. A subclass is a class that extends another class. A subclass inherits state and behaviour from all of its ancestors. The term "superclass" refers to a class's direct ancestor as well as to all of its ascendant classes.

What members does a superclass inherit?

A subclass inherits all of the members in its superclass that are accessible to that subclass unless the subclass explicitly hides a member variable or overrides a method. Note that constructors are not members and are not inherited by subclasses. The following list itemises the members that are inherited by a subclass:

  • Subclasses inherit those superclass members declared as public or protected.
  • Subclasses inherit those superclass members declared with no access specifier as long as the subclass is in the same package as the superclass.
  • Subclasses don't inherit a superclass's member if the subclass declares a member with the same name. In the case of member variables, the member variable in the subclass hides the one in the superclass. In the case of methods, the method in the subclass overrides the one in the superclass.

Creating a subclass can be as simple as including the extends clause in your class declaration.

However, you usually have to make other provisions in your code when subclassing a class, such as overriding methods or providing implementations for abstract methods.

Hiding member variables

As mentioned before, member variables defined in the subclass hide member variables that have the same name in the superclass.

One interesting feature of Java member variables is that a class can access a hidden member variable through its superclass. Consider the following superclass and subclass pair:

Code:

class Super {
    Number aNumber;
}
class Subbie extends Super {
    Float aNumber;
}

The aNumber variable in Subbie hides aNumber in Super. But you can access Super's aNumber from Subbie with

Code:

super.aNumber

super is a Java language keyword that allows a method to refer to hidden variables and overridden methods of the superclass.

Overriding methods

The ability of a subclass to override a method in its superclass allows a class to inherit from a superclass whose behaviour is "close enough" and then override methods as needed.

For example, all classes are descendants of the Object class. Object contains the toString method, which returns a String object containing the name of the object's class and its hash code. Most, if not all, classes will want to override this method and print out something meaningful for that class.

Let's resurrect the Stack class example and override the toString method. The output of toString should be a textual representation of the object. For the Stack class, a list of the items in the stack would be appropriate.

Code:

public class Stack {
   private Vector items;
   // code for Stack's methods and constructor
   //not shown
   // overrides Object's toString method

   public String toString() {
      int n = items.size();
      StringBuffer result = new StringBuffer();
      result.append("[");
      for (int i = 0; i < n; i++) {
         result.append(items.elementAt(i).toString());
         if (i < n-1) result.append(",");
      }
      result.append("]");
      return result.toString();
   }
}

The return type, method name, and number and type of the parameters for the overriding method must match those in the overridden method. The overriding method can have a different throws clause as long as it doesn't declare any types not declared by the throws clause in the overridden method.

Also, the access specifier for the overriding method can allow more access than the overridden method, but not less. For example, a protected method in the superclass can be made public but not private.

Calling the overridden method

Sometimes, you don't want to completely override a method. Rather, you want to add more functionality to it. To do this, simply call the overridden method using the super keyword.
For example,

Code:

super.overriddenMethodName();

Methods a subclass cannot override

A subclass cannot override methods that are declared final in the superclass (by definition, final methods cannot be overridden). If you attempt to override a final method, the compiler displays an error message similar to the following and refuses to compile the program:

FinalTest.java:7: Final methods can't be overridden.
Method void iamfinal() is final in class ClassWithFinalMethod.
void iamfinal() {
^
1 error

Also, a subclass cannot override methods that are declared static in the superclass. In other words, a subclass cannot override a class method. A subclass can hide a static method in the superclass by declaring a static method in the subclass with the same signature as the static method in the superclass.

Being a descendent of Object

The Object class sits at the top of the class hierarchy tree in the Java platform. Every class in the Java system is a descendent, direct or indirect, of the Object class. This class defines the basic state and behaviour that all objects must have, such as the ability to compare oneself to another object, to convert to a string, to wait on a condition variable, to notify other objects that a condition variable has changed, and to return the class of the object.

Your classes may want to override the following Object methods. The equals/hashCode are listed together as they must be overridden together.

  • clone
  • equals/hashCode
  • finalize
  • toString

Your class cannot override these Object methods (they are final):

  • getClass
  • notify
  • notifyAll
  • wait

The clone method

You use the clone method to create an object from an existing object. To create a clone, you write:

Code:

aCloneableObject.clone();

Object's implementation of this method checks to see if the object on which clone was invoked implements the Cloneable interface, and throws a CloneNotSupportedException if it does not. Note that Object itself does not implement Cloneable, so subclasses of Object that don't explicitly implement the interface are not cloneable.

If the object on which clone was invoked does implement the Cloneable interface, Object's implementation of the clone method creates an object of the same type as the original object and initialises the new object's member variables to have the same values as the original object's corresponding member variables.

The simplest way to make your class cloneable then, is to add implements Cloneable to your class's declaration. For some classes the default behaviour of Object's clone method works just fine. Other classes need to override clone to get correct behaviour.

Consider the Stack class, which contains a member variable that refers to a Vector. If Stack relies on Object's implementation of clone, then the original stack and its clone will refer to the same vector. Changing one stack will change the other, which is undesirable behaviour.

Here then is an appropriate implementation of clone for our Stack class, which clones the vector to ensure that the original stack and its clone do not refer to the same vector (changes are indicated with a change in font):

Code:


public class Stack implements Cloneable {
   private Vector items;
   // code for Stack's methods and constructor not shown

   protected Object clone() {
      try {
         Stack s = (Stack)super.clone(); // clone the stack
            s.items = (Vector)items.clone(); // clone the vector
         return s; // return the clone
      } catch (CloneNotSupportedException e) {
         // this shouldn't happen because Stack is Cloneable
         throw new InternalError();
      }
   }
}

The implementation for Stack's clone method is relatively simple: It calls super.clone, which Stack inherits from Object and which creates and initialises an instance of the correct type. At this point, the original stack and its clone refer to the same vector. Next the method clones the vector.

Be careful: clone should never use new to create the clone and should not call constructors. Instead, the method should call super.clone, which creates an object of the correct type and allows the hierarchy of superclasses to perform the copying necessary to get a proper clone.

The equals and hashCode methods

You must override the equals and hashCode methods together.
The equals method compares two objects for equality and returns true if they are equal. The equals method provided in the Object class uses the identity function to determine if objects are equal (if the objects compared are the exact same object the method returns true).

However, for some classes, two distinct objects of that type might be considered equal if they contain the same information. Consider this code that tests two Integers, one and anotherOne, for equality:

Code:

Integer one = new Integer(1);
anotherOne = new Integer(1);

if (one.equals(anotherOne))
    System.out.println("objects are equal");

This program displays objects are equal even though one and anotherOne reference two distinct objects. They are considered equal because the objects compared contain the same integer value.

Your classes should only override the equals method if the identity function is not appropriate for your class. If you override equals, then override hashCode as well.

The value returned by hashCode is an int that maps an object into a bucket in a hash table. An object must always produce the same hash code. However, objects can share hash codes (they aren't necessarily unique). Writing a "correct" hashing function is easy -- always return the same hash code for the same object. Writing an "efficient" hashing function, one that provides a sufficient distribution of objects over the buckets, is difficult.

Even so, the hashing function for some classes is relatively obvious. For example, an obvious hash code for an Integer object is its integer value.

The finalize method

The Object class provides a method, finalize, that cleans up an object before it is garbage collected. This method's role during garbage collection was discussed previously. The finalize method is called automatically by the system and most classes you write do
not need to override it. So you can generally ignore this method.

The toString method

Object's toString method returns a String representation of the object. You can use toString along with System.out.println to display a text representation of an object, such as the current thread:

Code:

System.out.println(Thread.currentThread().toString());

The String representation for an object depends entirely on the object. The String representation of an Integer object is the integer value displayed as text. The String representation of a Thread object contains various attributes about the thread, such as its name and priority. For example, the previous line of code displays the following output:

Thread[main,5,main]

The toString method is very useful for debugging. It behooves you to override this method in all your classes.

The getClass method

The getClass method is a final method that returns a runtime representation of the class of an object. This method returns a Class object.

Once you have a Class object you can query it for various information about the class, such as its name, its superclass, and the names of the interfaces that it implements. The following method gets and displays the class name of an object:

Code:

void PrintClassName(Object obj) {
   System.out.println("The Object's class is " +
                        obj.getClass().getName());
}

One handy use of a Class object is to create a new instance of a class without knowing what the class is at compile time. The following sample method creates a new instance of the same class as obj, which can be any class that inherits from Object (which means that it could be any class):

Code:

Object createNewInstanceOf(Object obj) {
    return obj.getClass().newInstance();
}

Part II continues here...


15625 bytes more | comments? | Printer Friendly Page  Send to a Friend | Score: 0
Posted by jalex on Friday, November 24, 2006 (04:00:00) (9078 reads)

Java Security Hole: update your Java!

Go to all tips in Security

Security hole in Java Swing Library!

If you use Java older than 1.5 update 8 then you at big risk. 16 November 2006 SUN released the information that there is security hole in Java Swing Library. This security hole can be exploited by malicious people to bypass certain security restrictions. A remote applet can access other applet data. It causes an unspecified error in the Java Runtime Environment Swing library..

Note: SDK and JRE 1.4.2_xx and earlier, and 1.3.1_xx and earlier are not affected.

Solution: Update to JDK and JRE 5.0 Update 8 or later.

* JDK and JRE 5.0 Update 8 and later (for Solaris, Linux and Windows)

J2SE 5.0 is available for download at the following links:


J2SE 5.0 Update 9 for Solaris is available in the following patches:

  • * J2SE 5.0: update 9 (as delivered in patch 118666-09)
  • * J2SE 5.0: update 9 (as delivered in patch 118667-09 (64bit))
  • * J2SE 5.0_x86: update 9 (as delivered in patch 118668-09)
  • * J2SE 5.0_x86: update 9 (as delivered in patch 118669-09 (64bit))

The Sun advisory is available at:
http://blogs.sun.com/security/  (Links to External Site)


536 bytes more | comments? | Printer Friendly Page  Send to a Friend | Score: 0
Posted by jalex on Thursday, November 23, 2006 (16:00:00) (2306 reads)

Previous 1060 Stories (530 Pages, 2 Per Page) Next

530| 529| 528| 527| 526| 525| 524| 523| 522| 521| 520| 519| 518| 517| 516| 515| 514| 513| 512| 511| 510| 509| 508| 507| 506| 505| 504| 503| 502| 501| 500| 499| 498| 497| 496| 495| 494| 493| 492| 491| 490| 489| 488|
487
| 486| 485| 484| 483| 482| 481| 480| 479| 478| 477| 476| 475| 474| 473| 472| 471| 470| 469| 468| 467| 466| 465| 464| 463| 462| 461| 460| 459| 458| 457| 456| 455| 454| 453| 452| 451| 450| 449| 448| 447| 446| 445| 444| 443| 442| 441| 440| 439| 438| 437| 436| 435| 434| 433| 432| 431| 430| 429| 428| 427| 426| 425| 424| 423| 422| 421| 420| 419| 418| 417| 416| 415| 414| 413| 412| 411| 410| 409| 408| 407| 406| 405| 404| 403| 402| 401| 400| 399| 398| 397| 396| 395| 394| 393| 392| 391| 390| 389| 388| 387| 386| 385| 384| 383| 382| 381| 380| 379| 378| 377| 376| 375| 374| 373| 372| 371| 370| 369| 368| 367| 366| 365| 364| 363| 362| 361| 360| 359| 358| 357| 356| 355| 354| 353| 352| 351| 350| 349| 348| 347| 346| 345| 344| 343| 342| 341| 340| 339| 338| 337| 336| 335| 334| 333| 332| 331| 330| 329| 328| 327| 326| 325| 324| 323| 322| 321| 320| 319| 318| 317| 316| 315| 314| 313| 312| 311| 310| 309| 308| 307| 306| 305| 304| 303| 302| 301| 300| 299| 298| 297| 296| 295| 294| 293| 292| 291| 290| 289| 288| 287| 286| 285| 284| 283| 282| 281| 280| 279| 278| 277| 276| 275| 274| 273| 272| 271| 270| 269| 268| 267| 266| 265| 264| 263| 262| 261| 260| 259| 258| 257| 256| 255| 254| 253| 252| 251| 250| 249| 248| 247| 246| 245| 244| 243| 242| 241| 240| 239| 238| 237| 236| 235| 234| 233| 232| 231| 230| 229| 228| 227| 226| 225| 224| 223| 222| 221| 220| 219| 218| 217| 216| 215| 214| 213| 212| 211| 210| 209| 208| 207| 206| 205| 204| 203| 202| 201| 200| 199| 198| 197| 196| 195| 194| 193| 192| 191| 190| 189| 188| 187| 186| 185| 184| 183| 182| 181| 180| 179| 178| 177| 176| 175| 174| 173| 172| 171| 170| 169| 168| 167| 166| 165| 164| 163| 162| 161| 160| 159| 158| 157| 156| 155| 154| 153| 152| 151| 150| 149| 148| 147| 146| 145| 144| 143| 142| 141| 140| 139| 138| 137| 136| 135| 134| 133| 132| 131| 130| 129| 128| 127| 126| 125| 124| 123| 122| 121| 120| 119| 118| 117| 116| 115| 114| 113| 112| 111| 110| 109| 108| 107| 106| 105| 104| 103| 102| 101| 100| 99| 98| 97| 96| 95| 94| 93| 92| 91| 90| 89| 88| 87| 86| 85| 84| 83| 82| 81| 80| 79| 78| 77| 76| 75| 74| 73| 72| 71| 70| 69| 68| 67| 66| 65| 64| 63| 62| 61| 60| 59| 58| 57| 56| 55| 54| 53| 52| 51| 50| 49| 48| 47| 46| 45| 44| 43| 42| 41| 40| 39| 38| 37| 36| 35| 34| 33| 32| 31| 30| 29| 28| 27| 26| 25| 24| 23| 22| 21| 20| 19| 18| 17| 16| 15| 14| 13| 12| 11| 10| 9| 8| 7| 6| 5| 4| 3| 2| 1|


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