methods in graphics class are abstract?

[server_crash]

Take just this simple method from the graphics class: fillOval()....Why is it abstract? Or better yet, where does it become concrete? I know I've never had to create my own implementation of that method.

[jwenting]

Graphics is an abstract class, it's designed specifically for subclassing.
Subclasses of Graphics will provide the actual implementation of the method, and whereever you see a Graphics instance returned from a method what you're actually getting is an instance of a Graphics subclass.

[server_crash]

Ok, so when you override the paint method and send it an argument, it creates the subclass of the graphics class?

[jwenting]

No, paint() gets passed an instance of a subclass of Graphics as its argument.
This is created internally by the JVM for the actual client platform (and is most likely a big chunk of JNI code linking directly into the operating system screen painting routines).

If you notice examples, you NEVER call paint() or other methods requiring a Graphics instance directly (or if you do you do so from a method that gets passed one and does itself not get called directly).

[server_crash]

Oh oh, I got this. It's like this right? :

a = new b;

where a is a concrete fixture of b...Right? I know that's not exactly correct, but it's along that line. At first I was wondering why you would pass a parameter with the same name as the abstract class if it's concrete, but now I know. I probably made no sense just then.

[jwenting]

no, you'd do

AbstractBase a = new ConcreteBaseImplementation c();

This would create a new concrete instance which is used as an instance of the abstract class.

For example in my SCJD assignment I have the following code to initialise the database:

public void activateServer(ActionEvent e) {

        /*
         * Create and open database file, create lockmanager
         */
        DataFile file = new BSDataFile(dataFileName.getText());
        boolean success = file.open();
        if (!success) {
            JOptionPane.showMessageDialog(this, file.getMessages(true), "Error opening database", JOptionPane.ERROR_MESSAGE);
            return;
        }
        LockManager manager = new LockManager();

        DBRemote remote = new RemoteData(new Data(file, manager));
        Registry rmiRegistry = null;

        try {
            rmiRegistry = LocateRegistry.getRegistry(Registry.REGISTRY_PORT);
        } catch (RemoteException ex) {
            // registry didn't exist yet, so create it
            try {
                rmiRegistry = LocateRegistry.createRegistry(Registry.
                    REGISTRY_PORT);
                rmiRegistry.rebind("BSDatabaseService", remote);

            } catch (RemoteException rex) {
                Logger.getLogger("suncertify.server.bs").severe(
                    "Error creating RMI registry: " + rex.getMessage());
            }
        }
        dataFileName.setEditable(false);
        modeSwitch.setEnabled(false);
        modeSwitch.setVisible(false);
    }

DataFile is an abstract baseclass for the actual database files offering functions to open and close the file.
BSDataFile is the implementation class which provides the actual record reading, writing, etc. functionality.

It works exactly the same as writing to interfaces where you define a variable as being of the interface type and then instantiate a class implementing that interface.

[server_crash]

I love you Mr. Wenting.. :eek: (you know I'm joking right?)... Thanks for the help. I don't think anyone else could have explained as well as you have. Now, there is one more thing I don't understand: It's abtract, it's obviously made for implementation somewhere else in it's own form. But where is these different implementations, besides the one? Is it just for good design practice taking in mind potential growth in the future? Or is there actually more than one implemenation of the graphics class somewhere?

[jwenting]

I decided on this architecture indeed to allow for future flexibility.
In the context of the immediate requirements in this case a single class would have sufficed.

As to Graphics, there is likely one implementation per JVM, but remember there are many JVMs for different operating systems (and often several for a single OS).
It's also conceivable for Sun to have provided different Graphics implementations for a single JVM, for example one that uses hardware accelleration and one that doesn't, the actual one to use getting chosen depending on the hardware capabilities.

In each case, the abstract class provides certain functionality which will always have identical coding, thus saving work as compared to implementing an interface (if the work is trivial it may depending on the system under development make more sense to use an interface anyway, if the design paradigm calls for it).