|
Articles Index
2 Platform, Standard Edition 1.4 (J2SE)
By Qusay H. Mahmoud
(April, 2002)
The Java 2 Platform, Standard Edition (J2SE) 1.4 has introduced several new features and enhancements for Object Serialization, Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), and networking in general. The new features and enhancements either address some changes in standard specifications such as CORBA, or improve the performance of existing features. This article gives an overview of the new features and enhancements.
Overview of New Features and Enhancements
New features and enhancements have been introduced for RMI, serialization, and CORBA as discussed in the following sections.
RMI
The RMI enhancements in J2SE 1.4 are:
- Server-side Stack Traces Retained in Remote Exceptions: The RMI runtime implementation will now preserve the server-side stack trace information of an exception that is thrown from a remote call. In other words, when such an exception becomes accessible to client code, its stack trace will now contain all of its original server-side trace data followed by the client-side trace. Certain RMI server applications, however, may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled as a result of a remote call, perhaps for reasons of performance or confidentiality. In such cases, the implementation-specific system property
sun.rmi.server.suppressStackTraces can be set to true to cause the server-side RMI runtime implementation to clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote method invocations.
- Service Provider Interface for
RMIClassLoader: Certain static methods of java.rmi.server.RMICLassLoader can now delegate their behavior to an instance of a new service provider interface java.rmi.server.RMIClassLoaderSpi.
- Dynamic Server Host Name: The property
java.rmi.server.hostname is now dynamically updated to indicate that future exports should use a new host name.
- RMI Implementation Logging: The new implementation of RMI in J2SE 1.4 uses the new Java Logging APIs to provide implementation-specific logging output. Please see RMI Implementation Logging for more information.
- Serializing Primitive Class Objects: In earlier releases, a
ClassNotFoundException would be thrown when passing a Class object to an RMI class. Now, if an object that contains Class objects for primitive types is passed as a remote method parameter or return value, it is stored in an instance of java.rmi.MarshalledObject.
Serialization
There are several enhancements and bug fixes to object serialization in J2SE 1.4. The enhancements are:
- Deserialization of unshared objects: In previous releases, security-conscious programmers had to clone private internal objects after deserializing them to guard against the possibility that outside parties with access to the serialization stream could append spurious back handles to the sensitive objects, which results in extra references to them during deserialization. This solution slows performance and wastes memory. In J2SE 1.4, a more efficient solution is provided by allowing receivers to invalidate unshared objects as they are read in, which makes it impossible for third parties to dereference back-handles to those objects occurring in the stream. This support is provided by the following API additions in the
java.io package:
ObjectInputStream.readUnshared()
ObjectOutputStream.writeUnshared(Object obj)
ObjectStreamField(String name, Class type,
boolean unshared)
|
- Security permission required to override
putFields and readFields: The ObjectOutputStream public one-argument constructor:
public ObjectOutputStream(OutputStream out) throws IOException
now requires the "enableSubclassImplementation" SerializablePermission (in a security manager) when invoked either directly or indirectly by a subclass which overrides ObjectOutputStream.putFields or ObjectOutputStream.writeUnshared
Similarly, the ObjectInputStream public one-argument constructor:
public ObjectInputStream(InputStream in) throws IOException
now requires the "enableSubclassImplementation" SerializablePermission when invoked either directly or indirectly by a subclass which overrides ObjectInputStream.readFields or ObjectInputStream.readUnshared
readObjectNoData method: this method is analogous to the class-defined readObject method, except that if it is defined it is called in cases where the class descriptor for a superclass of the object being deserialized is not present in the serialization stream. Each class-defined readObjectNoData method is required to have the following signature:
private void readObjectNoData() throws ObjectStreamException
The readObjectNoData is never invoked in cases where a class-defined readObject method could be called. However, serializable class implementors can call readObjectNoData from within readObject as a means of consolidating initialization code.
JavaIDL
The J2SE 1.4 release incorporated some changes to JavaIDL (an implementation of the Common Object Request Broker Architecture or CORBA) and RMI-IIOP as a result of changes in the CORBA specification from the Object Manager Group (OMG). The changes are:
- Portable Object Adapter: In CORBA 2.0, the only standard object adapter defined by the Object Management Group (OMG) is the basic object adapter (BOA), which provides basic services to allow a variety of CORBA objects to be created. ORB vendors and developers, however, discovered that the BOA is ambiguous and missing some features. This led vendors to develop their own proprietary extensions, which resulted in poor portability between different ORB implementations. The new standard object adapter in the Portable Object Adapter (POA) provides new features that allow application programmer to construct object implementations that are portable between different ORB products. The POA provides a great deal of flexibility for server implementations.
- Portable Interceptors: Portable Interceptors are hooks into the ORB through which ORB services can intercept the normal flow of execution in the ORB.
- Interoperable Naming Service: The Interoperable Naming Service (INS) provides the following features:
- Capability to resolve using stringified names (such as: a/b.c/d)
- URLs for CORBA object references (corbaloc: and corbaname: formats)
- Standard APIs in
NamingContextExt for converting between CosNames, URLs, and Strings
- ORB arguments for bootstrapping (
ORBInitRef and ORBDefaultInitRef)
- GIOP 1.2: The General Internet InterORB Protocol (GIOP) is the specification for a wire-level protocol for ORB (Object Request Broker) interoperability. IIOP (Internet InterORB Protocol) is a specific mapping of the GIOP that runs directly over TCP/IP connections. GIOP 1.2 is now fully supported.
- Dynamic Anys: This facility enables the construction of an any at runtime, without having static knowledge of its type. This is helpful for writing generic clients such as bridges, browsers, debuggers, and user interface tools.
In addition, there are some new tools related to the JavaIDL as described in Networking Tools.
New Features and Enhancements in Networking
- IPv6: Internet Protocol version 6 support for TCP and UDP application (including multicast) is now included in J2SE 1.4.
- HTTP Digest Authentication: The HTTP digest authentication implementation has been updated to support proxies and origin servers.
- Unconnected/Unbound Socket: This allows more flexible socket creation, binding, and connection. Enables manipulation of socket options before establishing or accepting connections. In addition a timeout can be specified when establishing a connection. A new class,
javax.net.ssl.SSLSocket, which is a subclass of java.net.Socket has been added to provide security for data sent through sockets through encryption.
- Connected UDP Socket: The UDP protocol is a connectionless protocol, however, the
DatagramSocket.connect method now establishes the address association at native level. Where supported, this allows an application to have visibility of ICMP port unreachable messages as an indication that the remote application is unavailable.
- Uniform Resource Identifier (URI): The
java.net.URI is new a class that allows URI construction and parsing without the presence of a protocol handler, which is not possible with the URL class.
- JNDI DNS Service Provider in InetAddress: This enhancement in class
java.net.InetAddress enables applications to configure a pure Java name service provider by using a DNS name service provider through JNDI.
- URLEncoder and URLDecoder: These have been added to enable applications to use other character encoding/decoding schemes.
- TCP Out-of-Band Data: New methods in class
java.net.Socket have been added to provide limited support for TCP urgent data for support certain legacy applications. Urgent data may be sent on any TCP socket. However, only partial support for receiving urgent data is provided.
- SOCKS: Full V5 and V4 TCP support with autonegotiation with the proxy of which version to use.
- NetworkInterface: The
java.net.NetworkInterface class allows enumeration of interfaces and addresses and can be used in applications deployed on machines with multiple network interfaces.
Networking Tools
Some new tools have been introduced in J2SE 1.4, and some existing tools have been enhanced. In the following subsections, I discuss the existing tools that have been enhanced as well as the new tools.
Enhanced Tools
idlj
The idlj tool now generates server-side bindings as in the Portable Servant Inheritance Model. New command-line options have been introduced to enable you to continue to generate backwards-compatible server-side bindings.
rmic
The rmic compiler has a new option to enable Portable Object Adapter (POA) for RMI. The POA enables portability among vendor ORBs. In order to enable POA support, use the argument -iiop and -poa as follows:
rmic -iiop -poa
New Tools
orbd
The orbd tool has been introduced in J2SE 1.4. With earlier J2SE, the Transient Naming Service, tnameserv was used. The orbd tool can be used instead of the tnameserv as it includes both, a transient naming service and persistent naming service. It is used to enable clients to transparently locate and invoke persistent objects on CORBA servers.
servertool
The servertool is a new tool that has been introduced in J2SE 1.4. It provides an ease-of-use interface for application programmers to register, unregister, startup, and shutdown servers.
The servertool has the following syntax:
servertool -ORBInitialPort nameserverport options [ commands ]
If you start the servertool without any commands, it will display a servertool> prompt. Commands then can be entered at the prompt. On the other hand, if you enter a command when starting servertool, the servertool runs the command and then exists. The commands are for registering, unregistering, and finding information about servers. For more information on the commands, please see servertool.
The -ORBInitialPort nameserverport option is required. The value for nameserverport specifies the port (use a port greater than or equal to 1024)on which orbd is running and listening for incoming requests.
Conclusion
This article presented an overview of the new features, enhancements, and tools that have been introduced with J2SE 1.4. The enhancements of existing features and tools improve the performance of applications, and the introduction of new features and tools address changes in standard specification (as in the case of CORBA).
For more information
Download J2SE 1.4
J2SE 1.4 Documentation
RMI Implementation Logging
About the Author
Qusay H. Mahmoud provides Java consulting and training services. He has published dozens of articles on Java, and is the author of Distributed Programming with Java (Manning Publications, 1999) and Learning Wireless Java (O'Reilly, 2002).
Have a question about Java programming? Use
Java Online
Support.
|
|