The Solaris 8 4/01 release includes the Java 2 SDK Standard Edition v. 1.3.0, also known as J2SETM 1.3.0. Below are new feature descriptions. Also included are descriptions of J2SE and JDK releases in previous Update releases. The information in this section supplements that found in The Java 2 SDK for Solaris Developer's Guide. The following describes new features in each Update release.
For the most current man pages, use the man command. The Solaris 8 Update release man pages include new feature information that is not in the Solaris 8 Reference Manual Collection.
J2SE 1.3.0 is an upgrade release for Java 2 SDK. The software includes the following new features and enhancements.
Performance improvements
Java HotSpotTM technology and performance-tuned runtime libraries make J2SE 1.3.0 faster in many functional areas than previous versions of the Java 2 SDK.
Easier web deployment
New features such as applet caching and automatic installation of optional packages by J2SE 1.3.0's Java Plug-in component enhance the speed and flexibility with which programs can be deployed on the web.
Enterprise interoperability
The addition of RMI/IIOP and the Java Naming and Directory InterfaceTM in J2SE 1.3.0 enhance the interoperability of the Java 2 Platform.
Security advances
New support for RSA electronic signing, dynamic trust management, X.509 certificates, and verification of Netscape-signed files mean more ways for developers to protect their electronic data.
Java Sound
J2SE 1.3.0 includes a powerful new sound API. Previous releases of the platform limited audio support to basic playback of audio clips. With this release, the Java 2 Platform for the first time defines a set of standard classes and interfaces for low-level audio support.
Enhanced APIs and improved ease of development
In response to requests from the development community, J2SE 1.3.0 adds new features to various areas of the Java 2 Platform. These features expand the functionality of the platform to enable development of more powerful applications. In addition, many of the new features make the development process itself faster and more efficient.
Each of these features is described more fully below. For detailed information about the new features in J2SE 1.3.0, see the Java 2 Platform documentation at http://java.sun.com/j2se/1.3/docs. The Java 2 Platform documentation includes the API specification for J2SE 1.3.0.
Many enhancements have been made to improve the performance of the Java 2 SDK in version 1.3.0 These changes include the addition of the Java HotSpotTM Client Virtual Machine (VM) and the Java HotSpot Server VM, both of which implement high-performance Java HotSpot technology. The Java HotSpot Client VM is tuned to maximize performance on client systems, improving performance in areas of startup time and memory footprint. The Java HotSpot Server VM is tuned to maximize performance of program execution speed and is aimed at server applications that are less concerned with startup and memory footprint.
J2SE 1.3.0 also includes newly tuned class libraries for improved runtime performance.
J2SE 1.3.0's new applet-caching feature ensures that often-used applets are always available for rapid loading and fast startup by keeping copies of the applets in a local cache. When an applet has been downloaded more than once, it can be stored in the local applet cache. This storage eliminates the need for a browser to download an applet over the network every subsequent time that the applet is needed. The local, cached copy can be used instead.
This feature is valuable for large, high-use applets. Many enterprise applets, for example, are in the megabyte-size range, and applets that large can take tens of minutes to load over a network. The new applet-caching feature eliminates the download time, enabling businesses to use a larger array of more powerful applets than ever before.
J2SE 1.3.0 also supports automatic deployment of optional packages. Optional packages are sets of features and APIs that, while not part of the Java 2 Platform, Standard Edition, are available separately for developers to use for specialized programming needs. Examples are Java Media Framework technology and the JavaHelpTM optional packages.
Before J2SE 1.3.0, an applet that used one or more optional packages had to trust that up-to-date versions of the optional packages were installed on every client that might want to run the applet. Without the proper optional package installed on the client, the applet could exhibit unintended behavior or not run at all.
With J2SE 1.3.0, applets can specify version and vendor information for any optional packages that they require. Developers can have their applets specify a URL at which the latest version of a required optional package can be downloaded if any of the following conditions are met.
The optional package is not already installed locally.
The optional package is installed but has an out-of-date version number.
The optional package is installed but is not from a specified vendor.
J2SE 1.3.0 supports any native and Java language installer programs that an optional package might have, automatically launching the installer program when a new version of an optional package is retrieved from the network.
J2SE 1.3.0 includes two significant enhancements to support for CORBA technologies: a production CORBA IDL compiler written in the Java language and the RMI over IIOP (RMI-IIOP) API. CORBA Interface Definition Language (IDL) is a language that defines only the interfaces for distributed systems. By using a neutral language to define interfaces, CORBA can support multiple languages. For the first time, the Java 2 SDK, Standard Edition includes an IDL compiler to compile language-neutral CORBA IDL into standard Java language bindings. These language bindings work with the Java IDL Object Request Broker (ORB) to support traditional CORBA programming in the Java programming language.
Since version 1.1 of the Java platform, the Remote Method Interface (RMI) has allowed programmers to write interfaces for distributed computing directly in the Java language. Because RMI used its own wire protocol, programmers had to give up the ability to communicate with objects written in other languages when they used RMI. RMI-IIOP uses the Java IDL ORB to enable the standard CORBA wire protocol, Internet InterORB Protocol (IIOP), to be used with RMI. Since IIOP is used for all communication, objects written in other languages such as C++ can communicate with RMI over IIOP distributed objects. Further, RMI has been accepted as the CORBA standard for mapping interfaces in the Java programming language to CORBA IDL. To facilitate programming in other languages, CORBA standard IDL can be generated from RMI-enabled classes. Existing RMI programs can be converted to use the IIOP protocol, typically with very limited changes.
RMI-IIOP combines the programming ease of RMI with JavaIDL's CORBA-compliant interaction with software written in other languages. By adhering to a few restrictions, RMI programmers can now use CORBA's IIOP communications to protocol to communicate with clients of any type, whether written entirely in the Java programming language or made up of components written in other CORBA-compliant languages.
J2SE 1.3.0's new Java Naming and Directory InterfaceTM (JNDI) API enables developers to add naming and directory functionality to applications written in the Java programming language. JNDI is designed to be independent of any specific naming or directory service implementation to enable seamless connectivity to heterogeneous enterprise naming and directory services. Thus a variety of services — new, emerging, and already deployed ones—can be accessed in a common way. Developers can use J2SE 1.3.0 to build powerful and portable directory-enabled applications by using this industry-standard interface.
The JNDI architecture consists of an API and a Service Provider Interface (SPI). Java applications use this API to access a variety of naming and directory services. The SPI enables a variety of naming and directory services to be plugged in transparently, allowing the Java application to access their services. JNDI in the J2SE 1.3.0 release comes with service providers for accessing the following services:
Lightweight Directory Access Protocol (LDAP) — An Internet standard for accessing directory services
Common Object Services (COS) Name Server — The name server for storing CORBA object references
The RMI registry service provider — The name server for storing RMI remote objects
With the security enhancements available in J2SE 1.3.0, developers have more tools at their disposal for protecting their technology investments. New support for RSA signatures and J2SE 1.3.0's enhanced dynamic trust management facilities also greatly increase the ease of web-based deployment.
J2SE 1.3.0 includes a cryptographic service provider to support the widely used RSA signatures for electronically signing software that is delivered over the Web. Standard RSA certificates are supported, including those from VeriSign and Thawte.
Prior to J2SE 1.3.0, Java platform users who wanted to use RSA certificates needed to write their own RSA service providers or purchase an RSA service provider from a third party. Now an RSA provider is included as a standard part of J2SE 1.3.0.
New dynamic trust management facilities in J2SE 1.3.0 provide pop-up dialogs to let users validate applet signers, eliminating the need to deploy security key files to each client that runs the signed applet.
Previously, if a user wanted to give an applet from a trusted source extra security permissions to allow the applet to perform normally forbidden operations, the user needed to preconfigure his or her local cache of trusted signer certificates to recognize the certificate of the applet's trusted source. This would need to be done for every client machine on which the applet might potentially be run.
J2SE 1.3.0 provides a better solution by providing facilities to extract the applet's signers from the applet's codesource and pass them to the browser. The browser then verifies the certificate chain all the way up to its root certificate, and checks if that root certificate is contained in the browser's database of trusted root certificates. If so, the browser displays the chain of the authenticated signer and give the user the option to remove all security restrictions on the applet.
J2SE 1.3.0 provides enhanced support for X.509 public-key certificates. J2SE 1.3.0 now supports all X.520 attributes that are either mandated or recommended by the most recent proposed standard protocol (RFC 2459). In addition, J2SE 1.3.0 can handle multiple Attribute/Value Assertions within a Relative Distinguished Name.
The Java Sound API enables Java programs to capture, process, and play audio and Musical Instrument Digital Interface (MIDI) data. These new capabilities enable developers to create new types of applications, including:
Communication frameworks, including conferencing and telephony applications.
End-user content delivery systems. These systems range from simple desktop media players to streamed music delivery systems or broadcast audio applications for live events.
Interactive applications, such as games and web sites, that generate sound dynamically in response to user interaction.
Tools and toolkits for creating and editing original audio or musical content.
The Java Sound API is supported by an efficient sound engine that guarantees high-quality audio mixing and MIDI synthesis capabilities for the platform. More specifically, the implementation that is included with J2SE 1.3.0 supports the following features:
Audio file formats: AIFF, AU and WAV
Music file formats: MIDI type 0 and type 1 and Rich Music Format
Audio codecs: u-law and a-law
Audio data formats: 8- and 16-bit audio samples, in mono and stereo, with sample rates from 8 kHz to 48 kHz
MIDI wavetable synthesis and sequencing in software, and access to hardware MIDI devices
An all-software mixer that can mix and render up to 64 total channels of digital audio and synthesized MIDI music.
Additionally, the API defines a set of service provider interfaces that developers can use to extend the capabilities of the current implementation. Users can install modules that provide support for additional file formats, codecs, and devices. The API includes methods for querying and accessing the resources currently available on the system.
J2SE 1.3.0 has a new Robot API that is designed to make automated Abstract Window Toolkit (AWT) and Swing testing possible. The Robot API enables code that is written in the Java programming language to generate low-level native mouse and keyboard input events. Because the events are generated at the operating system level, they are indistinguishable from real user input to the rest of the AWT.
Though designed primarily to improve testability, the Robot API also provides other benefits:
Accessibility-enabled applications can give more feedback. For example, if the user acts on a screen object by using voice commands, the mouse pointer can be moved to indicate the object being manipulated.
The Robot API enables creation of computer-based training (CBT) and other demo-type applications.
J2SE 1.3.0 also has an improved API for printing. The new printing API gives developers an easy mechanism to print the AWT components by using native platform facilities. By using the new API, developers can control properties of a print job such as destination, number of copies, page ranges, page size, orientation, print quality, and more.
J2SE 1.3.0 introduces support for rendering on multiple monitors the GUI Frames and Windows that belong to the same application. The Java 2DTM API supports three multi-screen configurations:
Two or more independent screens
Two or more screens where one screen is the primary screen and the other screens display copies of what appears on the primary screen
Two or more screens that form a virtual desktop
With J2SE 1.3.0's new dynamic font-loading API, a developer can create and load TrueType fonts during runtime. Developers can use the Java 2D API to give their dynamically loaded fonts the desired features such as size, style, transforms, and others.
The Java 2D API in J2SE 1.3.0 now supports the Portable Graphics Network (PGN) format, a flexible, extensive, non-proprietary file format that represents lossless and portable storage of raster images. PGN supports gray scale, indexed-color, and truecolor images, with an optional alpha channel.
JPDA technology is a multi-tiered debugging architecture that enables tool developers to easily create debugger applications that run portably across platforms, virtual-machine implementations, and J2SE versions.
JPDA consists of three layers:
JVMDI - Java Virtual Machine Debug Interface
Defines the debugging services a VM must provide for debugging.
JDWP - Java Debug Wire Protocol
Defines the format of information and requests transferred between the process being debugged and the debugger front end, which implements the Java Debug Interface.
JDI - Java Debug Interface
Defines a high-level Java programming language interface that tool developers can easily use to write remote debugger applications.
The internationalization enhancements in the J2SE 1.3.0 release give developers even more flexibility in localizing their applications for international users. Two new features are described here.
Input methods are software components that interpret user operations such as typing keys or speaking to generate text input for applications, and they play an important role in enabling entry of text in international locales. Unlike English text which can be entered by directly typing it in from the keyboard, entering text in languages such as Japanese or Chinese requires a more sophisticated input method framework, and J2SE 1.3.0 provides a powerful set of the tools that developers need to handle the job.
Modern text-editing components permit the display of entered text inside the context of the document in which the text will finally appear. This is called the on-the-spot input, and it has always been supported by the Java 2 Platform.
J2SE 1.3.0 adds support for a second style of input, called below-the-spot, that is popular is such countries such as China. In below-the-spot text editing, composed text is shown in a separate composition window that is automatically positioned close to the insertion point where text will be inserted.
It might be that a developer would want to change and customize the windows that appear as part of his or her input method framework. J2SE 1.3.0 gives developers full flexibility to do so by providing a new API for an input method engine Service Provider Interface (SPI). The SPI enables developers to construct their own custom input method engines to meet the needs their software.
A further example of new international locale support is that J2SE 1.3.0 can render application frames and dialog boxes to have toolbars and menu bars with a right-to-left orientation for locales such as Arabic and Hebrew.
J2SE 1.3.0 contains select new functionality that Sun has added to the platform and Java 2 SDK tools suite in consultation with business partners and in response to input from developers. A sampling of the enhancements include:
New javac Compiler
The javac compiler has been re-implemented from scratch in J2SE 1.3 making it faster for many applications than the compilers in previous versions of the Java 2 SDK.
Dynamic Proxy Classes
J2SE 1.3 contains a new API for dynamic proxy classes. A dynamic proxy class is a class that implements a list of interfaces specified at runtime such that a method invocation through one of the interfaces on an instance of the class is encoded and dispatched to another object through a uniform interface. Thus, you can use a dynamic proxy class can be used to create a type-safe proxy object for a list of interfaces without requiring pre-generation of the proxy class, such as with compile-time tools. Dynamic proxy classes are useful to developers who need to provide the type-safe reflective dispatch of invocations to objects that present interface APIs.
For example, you can use a dynamic proxy class to create an object that implements multiple arbitrary event listener interfaces to process a variety of events of different types in a uniform fashion, such as by logging all such events to a file.
Expanded API for Collections
The J2SE 1.3 version of the popular Collections API has been made even easier for you to use. The 1.3 Collections API includes new convenience methods and copy constructors for Lists and Maps.
Expanded Java Foundation Classes/Swing Functionality
A large part of the J2SE 1.3.0 engineering effort has been directed into tuning and enhancing the Swing components of the Java Foundation Classes API. In addition to performance tuning of the Swing libraries, new JFC/Swing functionality has been added to the Swing libraries in several areas. One example is the new support for variable-height rows in lightweight table components.
Improved Math and Utility Libraries
J2SE 1.3.0 includes two math-related classes that have the same API: Math and StrictMath. StrictMath is defined to return bit-for-bit reproducible results for numeric operations in all implementations for developers who need that guarantee. Implementations of class Math, on the other hand, can vary within specified constraints to enable flexibility for better performance. Developers who want best performance but don't require bit-for-bit reproducible results on different platforms will want to use Math rather than StrictMath for their numeric code.
The J2SE API for arbitrary precision math, classes BigInteger and BigDecimal, enables arithmetic operations that never overflow or lose precision, features necessary for many types of computations such as financial calculations. Class BigInteger has been reimplemented in pure Java programming-language code. Previously, the implementation of the BigInteger class was based on an underlying C library. The new implementation performs many standard operations faster than the old implementation. The new API also includes new convenience features that make it easier for you to use.
A new Timer API has been added to the Java 2 Platform to support animations, human interaction timeouts, on-screen clocks and calendars, work-scheduling routines, reminder facilities, and more.
An API for virtual machine shutdown hooks has been added to class java.lang.Runtime that provides a simple, portable interface to the underlying operating system's process-shutdown notification so that an application written in the Java programming language can initiate shutdown actions such as closing down network connections, saving session state, and deleting temporary files.
New delete-on-close mode for opening Zip and Jar files has been added so that long-running server applications can delete no-longer-needed JarFile objects and data to keep disk space free.
The following describes new features in J2SE releases.
Table 18–1 Previous Java 2 Standard Edition (J2SE) Releases
Java Release |
Update Release |
---|---|
J2SE 1.2.2_07a contains fixes for bugs identified in previous releases in the J2SE 1.2.2 series. An important bug fix in J2SE 1.2.2_07a is a fix for a performance regression that was introduced in J2SE 1.2.2_05. For more information about bug fixes in J2SE 1.2.2_07a, see this URL: http://java.sun.com/j2se/1.2/ReleaseNotes.html. |
4/01 |
The J2SE 1.2.2_06 is improved with bug fixes since the last release. |
1/01 |
The J2SE v. 1.2.2_05a is a bug-fix release of v. 1.2.2_05 (without the "a") of the same product and includes the following new features and enhancements.
|
10/00 |
The following are JDK releases that have been included in Update releases.
Table 18–2 JDK Releases
JDK Releases |
Update Release |
---|---|
JDK 1.1.8_12 is improved with bug fixes since the last release. |
1/01 |
The JDK 1.1.8_10 is improved with bug fixes. |
10/00 |
In the Solaris 8 10/00 release, with the addition of mod_jserv module and related files, the Apache web server software now supports Java servlets. The following configuration files are now stored in /etc/apache:
zone.properties
jserv.properties
jserv.conf
The mod_jserv module, like the rest of Apache software, is open source code that is maintained by a group external to Sun. This group seeks to maintain compatibility with previous releases of Apache and mod_jserv.