RMI Release Notes

Contents of the JavaTM 2 SDK, Standard Edition, v 1.3

"accept" java.net.SocketPermission requirement for receiving remote calls

Due to a bug in previous J2SE implementations, it was possible to export a remote object in a given access control context and then receive a remote call to that object over a given socket connection even if the access control context did not have "accept" java.netSocketPermission for the remote java.net.InetAddress and port of the socket connection.

This bug has been fixed; therefore, in some cases, code that exports remote objects might need to be granted more permissions that it did with previous implementations in order to function correctly.

As an example of how to grant such permissions using the default security policy file syntax, permission to accept socket connections from a host named terrier.east.sun.com can be expressed by the following permission entry (in the grant entry for the appropriate code source):

permission java.net.SocketPermission "terrier.east.sun.com", "accept";

As desrcibed in the documentation for java.netSocketPermission, the host specification may begin with a wildcard "*"; therefore, permission to accept socket connections for any host can be expressed by the following permission entry in a given grant entry:

permission java.net.SocketPermission "*", "accept";

Unexported remote objects not getting garbage collected

In previous implementations, under certain conditions, the RMI runtime would strongly refer to a remote object even after it has been explicitly unexported. This bug has been fixed so that the RMI runtime will never refer to a remote object that has been explicitly unexported.

ObjectOutputStream replacement table performance

In previous implementations, an ObjectOutputStream instance remembered replaced objects (that is, those objects which have been returned by a call to ObjectOutputStream.replaceObject or by a class-defined writeReplace method) in such a way that a linear search was used to determine whether or not an object had a replacement. Therefore, if the number of objects replaced in a given stream was large, the overhead of the search became prohibitively expensive for each new object serialized. This bug has been fixed so that the implementation now uses a more efficient algorithm for remembering for object replacements. This fix to the object serialization implementation also benefits the scalability of object replacement during RMI argument and return value marshalling.

Strings longer than 64K can now be serialized (since 1.3)

Prior to 1.3, an attempt to serialize a string longer than 64K would result in a java.io.UTFDataFormatException being thrown. In 1.3, the serialization protocol has been enhanced to allow strings longer than 64K to be serialized. RMI will also allow these longer strings to be passed in RMI calls between 1.3-compatible Java virtual machines* (JVMs). Note that if a 1.2 (or earlier) JVM attempts to read a long string written from a 1.3-compatible JVM, the 1.2 (or earlier) JVM will receive a java.io.StreamCorruptedException.

Serialization performance enhancements (since 1.3)

UTF read and write performance has improved significantly in 1.3. Additionally, writing the fields of an object during default serialization and reading the fields of an object during default deserialization is up to 20% faster. Other general implementation improvements have also increased performance up to an additional 20%. These serialization improvements have increased the overall performance of RMI calls that pass objects as parameters or return values.

Improved exception reporting (since 1.3)

If a class can not be found during the class resolution process of deserialization, the original java.lang.ClassNotFoundException is thrown instead of a generic one so that more information about the failure is available. Another improvement to deserialization exception reporting includes maintaining the name of the original class that could not be found instead of reporting a higher-level class that was being deserialized. For example, if (in an RMI call) the stub class can be found but the remote interface class cannot, the serialization mechanism will now report correctly that the interface class was the class that could not be found instead of erroneously reporting that the stub class could not be found.

java.rmi.activation.ActivationGroupDesc (since 1.3)

The getClassName method, which returns the group's class name, can now return null, indicating the system's default group implementation. Previously, the getClassName method would return the name of the internal implementation class if the default group implementation was chosen when the descriptor was constructed.

Due to this change, if an application running in a 1.3 JVM registers an new activatable object with the ActivationSystem, rmid must also be upgraded to run 1.3, since a pre-1.3 rmid will not be able to activate the newly registered activatable object.

Constructors of activatable objects (since 1.3)

An activatable object's "activation" constructor, which takes an ActivationID and a MarshalledObjectas arguments and which is called by the ActivationInstantiator each time the object is activated, can now be private or protected. Previously, the implementation only allowed public activation constructors.

Serializing remote objects (since 1.2.2)

Prior to 1.2.2, an attempt to pass an unexported remote object in a RMI call would result in a java.rmi.StubNotFoundException. This exception was a result of the RMI runtime's failure to locate a stub object during an attempt to replace a remote object implementation with its corresponding stub. In 1.2.2 and later releases, an unexported remote object passed in an RMI call will no longer result in an exception, but rather the remote object will be serialized instead of its stub. If the remote object implementation is not serializable, an attempt to pass an unexported object in an RMI call will result in a java.rmi.RemoteException with the nested exception java.io.NotSerializableException.

java.rmi.server.RMIClassLoader (since 1.3)

java.rmi.server.RMIClassLoader has a new method, getClassLoader. This method returns the class loader that RMI uses to load classes from a specified codebase URL path. This API can be used in an implementation that requires complete RMI marshalling/unmarshalling behavior. See java.rmi.server.RMIClassLoader for details.

The RMI Stub Compiler, rmic

• By default, rmic now assumes that the destination directory for generated stubs is the package-named subdirectory of the current working directory. If the "-d" option is not specified, the result is the same as though it were specified with the current working directory "." as an argument. The "-d" may still be used to override the default destination directory.
• Two new options, "-idl" and "-iiop" have been added to generate IDL and stubs for IIOP, respectively.

The RMI Activation Daemon, rmid

By default, rmid now requires a security policy file.

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.

Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved.  Please send comments to: rmi-comments@java.sun.com