One of the most useful features of an object-oriented language is the ability to declare a class that defines how to use the class without having to declare the methods. This is useful when the implementation is going to be specific to each user, but each user should use the same methods.

Example: Suppose (just suppose) you wanted to have a bunch of graphics objects. Consider a Shapes Class

abstract class Shapes extends Object { protected Point lowerLeft; // lower left of bounding box protected Point upperRight // upper right of bounding box ... ... public void setPosition(Point ll, Point ur) { lowerLeft = ll; upperRight = ur; } } abstract void drawMyself() { //not an abstract method - why? } abstract void drawMyself(); // correct }

setPosition() method is declared public void since it can be implemented here for all

Abstract classes should generally not have private methods (why? ) nor can they have static methods. (private methods will compile though)

Packages in Java are a way of grouping together related classes and interfaces (dot (.) separated)

They

• enable modular groups of classes to be available
  
• eliminate potential conflicts between class names in different groups

Declaration

package myFirstPackage;

Then you define your classes. These classes (the ones declared with this same package name) are grouped together. These other classes are usually located in separate source files

Packages can be further organized into a hierarchy:
java.awt.image.ColorModel

Import and Ambiguity

Look into the Date.java file see
package java.util;
at the top. This identifies that it is in that package.
You might note also that there is a java.sql.Date class in the package java.sql

The classes in the java package are guaranteed to be available in any Java implementation, and are the only classes guaranteed to be available across different platforms. Classes in other packages (sun, netscape) may be available only for specific implementations.

By default, your Java classes have access to only the classes in java.lang To use classes from any other package, you have to either

• refer to them explicitly by package name
  java.util.Date today = new java.util.Date();
• import them in your source file

If two packages each have classes with the same name, you can't import them both. Try it and see what happens ...

Also, you can only use * to import multiple classes in a package. In fact, normally importing all classes is simpler, and if has no negative effect on compile time or code size, so there is generally no reason not to do it. (Remember that import is not the same as #include in C ... java does dynamic class loading.)

The use of * cannot be used for multiple packages, i.e., import java.* won't work

-p        With this option, mkdir creates dir  by  creating
          all  the  non-existing  parent  directories first.
         

So if a class is not defined as public, then only other classes in the same package can access it. This is often OK at first since you are defining all of your classes in the same directory (by defaults, same package).

For methods, you should generally specify if you want them to be public or private (like setting protocols (accessors, etc) in Smalltalk). Core2 suggests that data (cv and iv) always be private (to promote encapsulation)

Note: every source file can contain, at most, one public class, which must have the same name as the file.

Many books suggest *every* class be defined in a separate file supporting the compiler convention that only one class should be located in each Java source file - actually the compiler cares only about every public class being a separate file

The above is a common cause of compiler error - hard to find if you don't know this convention!