"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):
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:
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.
Serialization Enhancements (notable for RMI)
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.
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.
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 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.
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.