The new Java Development Kit (JDK)
application programming interfaces (APIs) provide a full complement
of new features and functionality for creating reliable
Java enterprise programs. The
JDK 1.2 APIs cover many areas of Java enterprise programming,
and this article presents an eagle-eye view of what you can expect
to find.
This list shows the JDK 1.2 areas that are either new or enhanced. The descriptions following the list describe each area in terms of what the area is, and its new or enhanced features and functionality.
In JDK 1.2, the Java1 Virtual Machine (Java VM) performance is enhanced to provide a more efficient execution environment:
Security is the state of being free from risk or danger. New JDK releases continue to enhance the security features inherent in the Java language and built into the Java platform. JDK 1.0.2 restricts applets to a sandbox so they cannot access local system resources outside their sandbox, and JDK 1.1 provides digitally signed Java ARchive (JAR) files to sign and verify the signature on applet and application files.
JDK 1.2 introduces a strong security model and accompanying tools that let end users and system administrators extend the security policy to applications and determine how much access to system resources an applet or Java application can have. The JDK 1.2 security policy is easy to configure, provides fine-grained access control, and applies to all Java applets and applications.
JDK 1.2 security tools:
JDK 1.1 provides APIs for digital signatures and message digests. Digital signatures are an authentication tool that verifies the origin of a message and the identity of the sender and receiver. Message digests are a mechanism to ensure that the message received by way of the network exactly matches the message that was sent.
JDK 1.2 Java Cryptography Architecture (JCA) framework builds on these features to provide a full range of cryptographic services and algorithms to keep messages sent over the network secure. The JCA has been significantly extended with additional classes and methods to support the new policy-oriented architecture, and introduce a wider range of cryptographic functionality including third-party cryptographic services and key management. JDK 1.2 also upgrades the certificate management infrastructure to support X.509 v3 certificates.
The Java Foundation Classes (JFCs) extend the Abstract Windowing Toolkit (AWT) by adding a comprehensive set of graphical user interface (GUI) class libraries that is completely portable and compatible with all AWT-based applications. In JDK 1.2, the JFC consists of Swing 1.0, Drag and Drop, and Java 2D class libraries. This section highlights the new JDK 1.2 JFC features.
JDK 1.2 includes Swing 1.0. Swing 1.0 includes GUI Components and Services, Pluggable Look and Feel, and Accessibility class libraries. Swing is 100 percent pure Java, and relies on the AWT for basic drawing and event support, so the Swing API can now support icons and colors.
The GUI Components and Services class libraries introduce many new components, and Swing versions of old AWT components. These class libraries let you easily customize the entire look and feel of an application without relying on the native windowing system.
The pluggable look and feel class libraries let you, and perhaps your users, control the platform look of the user interface. For example, if you want a cross-platform look and feel, you can program that in from the beginning, and if you expect the application to run only on a certain platform, you can program that look and feel in as well. You can also set your application so the user chooses the preferred look and feel.
The Pluggable Look and Feel class libraries also let you design your application so the user can choose how to interact with data on the screen by selecting an audio, visual, or tactile presentation without restarting the application.
The Accessibility class libraries and utility classes support assistive technologies such as screen readers, screen magnifiers, and speech recognition devices. If a Java application fully supports the Accessibility API, no offscreen model is necessary because the API provides all the information normally contained in an offscreen model. The Accessibility utility classes do such things as locate objects that implement the Accessibility APIs, load the Java VM, and track events.
The Accessibility APIs also provide a bridge between the accessibility available in the Java VM and accessibility technologies already available on host operating systems such as Macintosh, OS/2, and Windows. This bridge will be slightly different for each platform. Sun is currently developing both the Java programming language side of this bridge, and the Win32 side, and intends to make similar bridges available for other platforms over time.
Java and non-Java applications can readily share data using an extensible data type system based on the Multipurpose Internet Mail Extension (MIME) standard. JDK 1.2 drag and drop works with Accessibility APIs and is extensible to support diverse input devices.
JDK 1.2 significantly extends the 2D capabilities available in earlier JDK releases. You get an expanded set of 2D APIs for designing interesting and more usable user interfaces, handling color, processing images, addressing multilingual requirements, and using stylized text. The new features have been added into the AWT so that you can use JDK 1.2 Java 2D functionality in existing applications without rewriting old code.
The java.awt and java.awt.image packages are enhanced, and the java.awt.color, java.awt.font, java.awt.geom, and java.awt.print packages are new.
java.awt includes the new Graphics2D class for better geometry, transformation, color, and text rendering, and has enhanced color and font capabilities. The Color class supports a full range of color spaces, and the Font class supports any font on the system. You also get more texture map and fill pattern options, image compositing and transparency capabilities, more line widths, end caps, line styles, dash patterns, and a flexible device model.
java.awt.color supports high-quality color output using profiles and a full array of color spaces for defining device-dependent and device-independent color attributes.
java.awt.font supports glyphs and text with multiple fonts that can be transformed and drawn into a graphics context.
java.awt.geom lets you create a wide range of shapes including arbitrary and point-by-point paths, perform affine transformations (transformations that maintain parallel lines), and allows float and/or double precision in most cases.
java.awt.image supports a full-range of image processing capabilities including affine transformation, amplitude scaling, lookup-table modification, color conversions, and convolutions. The BufferedImage class describes an image with an accessible buffer of image data consisting of color model and data layout information.
java.awt.print introduces a printing model for the Windows and Solaris platforms where the printing system drives the printing process to give you more control, power, and flexibility in application-level printing. The Java 2D printing system can print all Java 2D regular and composited graphics, and supports soft collating, reverse order printing, and booklet printing.
The JDBC API makes it possible to send SQL statements to a database and to process the results that are returned. The API provides uniform access to a wide range of relational databases, and it provides a common base upon which database tools can be built.
The JDBC API implementation includes a driver manager to support multiple drivers that mediate the connections between the JDBC API and different databases. A driver can be written entirely in the Java language so it can be downloaded as part of an applet, or in a mixture of the Java language and Java Native Interface (JNI) native methods if it needs to bridge to existing database access libraries.
In JDK 1.2, the java.sql package builds on the existing SQL functionality to include:
Java IDL adds CORBA (Common Object Request Broker Architecture) capability to the Java platform to provide standards-based interoperability and connectivity. Java IDL is new with JDK 1.2 so distributed Web-enabled Java applications can transparently invoke operations on remote network services using the industry standard Object Management Group (OMG) interface definition language (IDL) and Internet Inter-ORB Protocol (IIOP) defined by the OMG. Runtime components include a fully-compliant Java ORB for distributed computing using IIOP communication.
The two main Java IDL packages are:
The org.omg.CORBA package supplies the mapping of the OMG CORBA 1.0 APIs to the Java programming language. An implementation of the ORB class is included so a programmer can use it as a fully functional Object Request Broker (ORB). An ORB object handles (or brokers) method invocations between a client and the method's implementation on the server. Because the client and server can be anywhere on a network and the invocation and implementation can be in different languages, an ORB object does a lot of behind-the-scenes work to enable the communication.
The org.omg.CosNaming package specifies the naming service for Java IDL. The package and all its classes and interfaces were generated by running the idltojava tool on the file nameservice.idl, which is a module written in OMG IDL.
A Java Bean is a reusable and interchangeable software component that can be visually manipulated in builder tools. JavaBeans can be simple like pushbuttons or dialog boxes, or more complex like spreadsheets and calendars. The primary purpose of Beans is to enable the visual construction of applications using a command-line or graphical user interface (GUI) Builder tool.
While individual Beans vary in functionality, most share the following common defining features:
In JDK 1.2, the JavaBeans API includes an extensible and standard runtime containment and services protocol, and drag and drop support.
Runtime Containment and Services Protocol: When a Bean is introduced to its environment, it knows it is running inside the Java VM and has access to the core Java APIs. This design provides a standard way to nest Beans within other Beans and have the nested Bean access additional runtime services from its environment in a standard way. It also provides a standard way for the environment or containing Bean to extend its capabilities directly to the nested bean.
Drag and Drop Support: Java and non-Java applications can readily share data using an extensible data type system based on the Multipurpose Internet Mail Extension (MIME) standard. JavaBeans drag and drop works with the JFC Accessibility APIs and can be extended to support diverse input devices.
The Applet class and AudioClip interface support playing sounds in applets and creating audio clips.
JDK 1.2 has a new sound engine with better sound quality that provides playback for MIDI files and supports a full range of .wav, .aiff, and .au files. There is also a new Applet class method so applications can create AudioClips without an AppletContext.
Internationalization APIs let you design an application so it can be configured to use languages and scripts from all over the world. Sometimes the term internationalization is abbreviated as i18n, because in the English language there are 18 letters between the first i and the last n. The process of making an application available in other languages and scripts is called internationalization and localization.
Localization means adapting software for a specific region or language by adding locale-specific components and translating text. The term localization is often abbreviated as l10n, because in the English language there are 10 letters between the l and the n.
In JDK 1.2, changes to the Internationalization API include the addition of the Input Method Framework described in the next heading, and a number of surface changes to the Text package that involved renaming and moving methods and changing the order of method parameters to simplify the Internationalization API.
The Input Method Framework (IMF) is new in JDK 1.2. It is a framework that lets all text editing components receive Japanese, Chinese, or Korean text (languages that use thousands of complex characters) from a regular-sized keyboard. The text is typed using character sequences to represent characters or the individual strokes of a character and converted to the intended script. Typically, a sequence of several characters is typed and then converted in one chunk. The process is iterative in that the conversion is tested and retried if the translation does not come out exactly right (there might be more than one possible translation for a given character sequence).
In JDK 1.1, text input using input methods is supported only for the AWT TextField and TextArea components using the native platform input method functionality.
Remote Method Invocation (RMI) lets Java applications use normal method calls (rather than sockets and streams) to communicate across a network. The communicating applications can be running on different computers on opposite sides of the planet. This higher-level and method-based approach to network communications allows access to a remote object as easily as a local object.
JDK 1.2 RMI enhancements include remote object activation, downloadable socket factories, and other minor API enhancements:
Remote object activation introduces support for persistent references to remote objects and automatic object activation by way of these references.
Downloadable socket factories allow a remote object to specify the custom socket factory that RMI will use for remote calls to that object. RMI over a secure transport (such as SSL) can be supported using downloadable socket factories.
Other minor API enhancements allow unexporting a remote object, obtaining the stub for an object implementation, and exporting an object on a specific port.
Serialization is a mechanism for converting objects (including complex data structures such as lists and trees) into a stream of bytes for writing to a file or sending across a network. The stream can later be deserialized and converted back into an object. Serialization is useful for giving objects persistence and transmitting them to a remote location. RMI uses serialization to transmit objects across a network.
In JDK 1.2, serialization is enhanced to include the following API functionality:
The Collections API is new in JDK 1.2. A collection (or container) is a single object that represents a group of objects. The collections API is a unified framework to seamlessly represent and manipulate collections of various types of objects independent of their representation details. Collections enable interoperability between unrelated APIs, encourage software reuse, and make it easier to design, implement, or learn a new API.
The JDK 1.2 Reference Object application programming interface (API) lets you create and manipulate reference objects. A reference object is created from another object of any type, and lets a program maintain a reference to that object after the object has become eligible for garbage collection. Reference objects let you manage garbage collection for greater speed and efficiency in releasing memory, and to add interesting and versatile functionality to your program without delaying garbage collection.
The Reflection API lets a Java program access information about the fields, methods and constructors of loaded classes, and use reflected Field, Method, and Constructor objects to operate within JDK 1.2 security restrictions on the fields, methods, and constructors in other objects. The Reflection API accommodates applications that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class.
Some clients such as the Serialization service, development tools, and debuggers need to bypass the default access controls built into the Java language when they use reflected members or constructors. These controls govern how Method and Constructor reflectives can access fields, invoke members, and create new class instances according to whether the field, method, or class is public, private, or protected.
In JDK 1.2, reflected Field, Method and Constructor objects extend a new base class (AccessibleObject) with a flag field that can be set to bypass the default access controls. Flag values for this field are either True or False, and the default flag value is false. If the flag is True, access checks are bypassed and the requested operation proceeds. If the flag is False, normal access checks are in force.
Setting the flag is under the control of the JDK 1.2 security architecture. In addition to the AccessibleObject instance, which has the necessary state and methods to set the flag to true, a ReflectPermission object is needed. The ReflectPermission object has methods to grant the necessary permission in the policy file to allow the reflective access.
The Java Native Interface (JNI) defines a standard naming and calling convention so the Java VM can locate and invoke native methods. JNI also offers a set of standard interface functions to call from native code to do such things as access, manipulate, release, or create Java objects, or call Java methods. Finally, the JNI supports an Invocation to load, initialize, and invoke the Java VM.
In JDK 1.2, there are a number of new methods to add functionality in the areas of library and version management, local reference management, weak global references, array operations, string operations, reflection support, and the Invocation API.
JDK 1.2 supports extensions, which are packages of Java classes (and any associated native code) that application developers can use to extend the functionality of the core platform. The extension mechanism allows the Java VM to use the extension classes in much the same way as the Java VM uses the system classes. The extension mechanism also provides a way to retrieve extensions from URLs when they are not available as part of the JDK or Java Runtime Environment (JRE).
Extensions are packaged as Java ARchive (JAR) files and installed in the /lib/ext directory of the JDK or JRE. When installed in the /lib/ext directory, extensions can be used by applets and applications without being explicitly included in the class path.
Java ARchive (JAR) file format provides a means for bundling multiple class files and associated resources in a single archive file. JDK 1.2 JAR enhancements include the following:
In JDK 1.2, the Versioning APIS are enhanced to include package-level version control. Java applications and applets can now identify at runtime the version of a specific Java Runtime Environment, Java VM, or class package.
Enhancements to the Versioning APIs for retrieving runtime package version information include the addition of the java.lang.package.class, and new accessor methods in the following classes:
The Java VM provides low-level debugging services, and an API to access the services is the Java Virtual Machine Debugger Interface (JVMDI). The JVMDI APIs include classes and methods for memory management, thread execution, stack frame access, breakpoints, class information, method information, events, and other miscellaneous functions.
1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
© 1994-2005 Sun Microsystems, Inc.