abstract method

I found that abstract method can't be implemented in the same class it defined.
But I see in java.awt.Graphics the following functions

fillOval....

Abstract classes CAN and most often do have concrete methods like that. Just because it's an abstract class doesn't mean it has to have only abstract methods.

I don't get the question here.


Yes Graphics is an abstract class, and fillOval is an abstaract method. So you can not make an instance of the Graphics file your self. But widgets can make it for you, like in the paint method.


- ØØ -

Hmm, so fillOval() IS an abstract method...That's confusing to me. Somewhere along the line this method is made concrete, and is given the code to perform it's operation, but where? It's not in the Graphics class? And you surely aren't required to come up with your own implementation.

The graphics in Java and it events is the two things that bugs me the most except the speed with Java. I am not sure if it is me never taking the time to understand it, or if it is just very weird.


I guess there is some casting or some trick there that I have never looked into. But at least you can't make your own instance of the graphics object. At least not straight forward.


[Edit] As a wild guess without looking into it any furuther, I guess they do something like this. Lets say A is a base class, and B inheriths from A. Then they do something like:

A g = new B();

and then send you g. That is a pointer of type a (or a graphics object) but actualy is an object furuther down the hierarchy.

- ØØ -

You can always grab a graphics contecxt via getGraphics() if you want. Pretty sure it's defined in java.awt.Component

The paint() method gives you a Graphics reference, but the actual type is probably com.sun.awt.graphics.Graphics or whatever - the thing is, you just don't care as long as it works.

I see java.awt.Graphics only extends Java.lang.Object.
And it is defined there procedures like
public abstract void fillOval()
then where are the implements of the procedures?

In classes you'll never know about. I believe the Sun JRE implements them in, for example, com.sun.awt.win32.Graphics2d. The Kaffee project elsewhere, as does the GNU Classpath project. But that's not your concern. Your concern is that, upon calling Component.getGraphics(), you receive an instance of a subclass of Graphics, which you can do stuff with.