Whole document tree

1.3 Backward Compatibility and Platform Independence

The Java 2D^TM API maintains backward compatibility with JDK 1.1 software. It is also architected so that applications can maintain platform-independence.

1.3.1 Backward Compatibility

To ensure backward compatibility, the functionality of existing JDK graphics and imaging classes and interfaces was maintained. Existing features were not removed and no package designations were changed for existing classes. The Java 2D API enhances the functionality of the AWT by implementing new methods in existing classes, extending existing classes, and adding new classes and interfaces that don't affect the legacy APIs.

For example, much of the Java 2D API functionality is delivered through an expanded graphics context, Graphics2D. To provide this extended graphics context while maintaining backward compatibility, Graphics2D extends the Graphic s class from the JDK 1.1 release.

The usage model of the graphics context remains unchanged. The AWT passes a graphics context to an AWT Component through the following methods:

• paint
• paintAll
• update
• print
• printAll
• getGraphics

A JDK 1.1 applet interprets the graphics context that's passed in as an instance of Graphics. To gain access to the new features implemented in Graphics2D, a Java 2D API-compatible applet casts the graphics context to a Graphics2D object:

	public void paint (Graphics g) {

	   Graphics2D g2 = (Graphics2D) g;
	   ...
	   ...
	  g2.setTransform (t);
	}

In some cases, rather than extending a legacy class, the Java 2D API generalizes it. Two techniques were used to generalize legacy classes:

• One or more parent classes were inserted in the hierarchy, and the legacy class was updated to extend the new parent classes. This technique is used to add general implemented methods and instance data to the legacy class.
• One or more interface implementations were added to the legacy class. This technique is used to add general abstract methods to the legacy class.

For example, the Java 2D API generalizes the AWT Rectangle class using both of these techniques. The hierarchy for rectangle now looks like:

	java.lang.Object
	|
	+-------java.awt.geom.RectangularShape
             	|
             	+---------java.awt.geom.Rectangle2D
                          |
                          +-------java.awt.Rectangle

In the JDK 1.1 software, Rectangle simply extended Object. It now extends the new Rectangle2D class and implements both Shape and Serializable. Two parent classes were added to the Rectangle hierarchy: RectangularShape and Rectangle2D. Applets written for JDK 1.1 software are unaware of the new parent classes and interface implementations, but are unaffected because Rectangle still contains the methods and m embers that were present in earlier versions.

The Java 2D API adds several new classes and interfaces that are "orthogonal" to the legacy API. These additions do not extend or generalize existing classes--they are entirely new and distinct. These new classes and interfaces embody conc epts that had no explicit representation in the legacy API.

For example, the Java 2D API implements several new Shape classes, including Arc2D, CubicCurve2D, and QuadCurve2D. Although early versions of the AWT could render arcs using the drawArc and fillA rc methods, there was no general curve abstraction and no discrete classes that embodied arcs. These discrete classes could be added to the Java 2D API without disrupting legacy applets because drawArc and fillArc are still sup ported through the Graphics class.

1.3.2 Platform Independence

To enable the development of platform-independent applications, the Java 2D API makes no assumptions about the resolution, color space, or color model of the target rendering device. Nor does the Java 2D API assume any particular image file format.

Truly platform-independent fonts are possible only when the fonts are built-in (provided as part of the JDK software), or when they are mathematically or programmatically generated. The Java 2D API does not currently support built-in or mathematically gen erated fonts, but it does enable the programmatic definition of entire fonts through their glyph set. Each glyph can in turn be defined by a Shape that consists of line segments and curves. Many fonts of particular styles and sizes can be deriv ed from a single glyph set.