Beginning with JDK 7 Update 21, the default value of the RMI property java.rmi.server.useCodebaseOnly has been set to true. See Enhancements in JDK 7 for more information.
java.rmi.MarshalledObject now genericMarshalledObject
now has a type parameter representing the type of the contained
serialized object.RMIClientSocketFactory
in a given virtual machine, then either that factory object or an
equivalent factory object would remain forever reachable in the
virtual machine, preventing it (and its defining class loader) from
ever being garbage collected; this bug has been fixed. (There is an
equivalent bug for socket factories used to export a remote object:
6332603.)sun.rmi.dgc.client.gcInterval and
sun.rmi.dgc.server.gcInterval, was one minute by
default. The default interval is now one hour, to better
accommodate applications with large heap sizes without special
configuration.rmic, to
pregenerate stub classes for remote objects. Note that
rmic must still be used to pregenerate stub classes
for remote objects that need to support clients running on earlier
versions.
When an application exports a remote object (using the
constructors or static exportObject methods1 of the classes
java.rmi.server.UnicastRemoteObject or
java.rmi.activation.Activatable) and a pregenerated
stub class for the remote object's class cannot be loaded, the
remote object's stub will be a java.lang.reflect.Proxy
instance (whose class is dynamically generated) with a
java.rmi.server.RemoteObjectInvocationHandler as its
invocation handler.
An existing application can be deployed to use dynamically
generated stub classes unconditionally (that is, whether or not
pregenerated stub classes exist) by setting the system property
java.rmi.server.ignoreStubClasses to
"true". If this property is set to
"true", pregenerated stub classes are never used.
Notes:
rmic or the
client will get an ClassNotFoundException
deserializing the remote object's stub. Pre-5.0 clients will not be
able to load an instance of a dynamically generated stub class,
because such a class contains an instance of
RemoteObjectInvocationHandler, which was not available
prior to this release.java.rmi.StubNotFoundException if the
pregenerated stub class for the remote object's class could not be
loaded. With the added support for dynamically generated stub
classes, exporting a remote object that has no pregenerated stub
class will silently succeed instead. A user deploying a server
application to support pre-5.0 clients must still make sure to
pregenerate stub classes for the server's remote object classes,
even though missing stub classes are no longer reported at export
time. Such errors will instead be reported to a pre-5.0 client when
it deserializes a dynamically generated stub class.1 The static method
UnicastRemoteObject.exportObject(Remote) is declared
to return java.rmi.server.RemoteStub and therefore
cannot be used to export a remote object to use a dynamically
generated stub class for its stub. An instance of a dynamically
generated stub class is a java.lang.reflect.Proxy
instance which is not assignable to
RemoteStub.
javax.rmi.ssl.SslRMIClientSocketFactory
and javax.rmi.ssl.SslRMIServerSocketFactory,
which communicate over the Secure Sockets Layer (SSL) or Transport
Layer Security (TLS) protocols using the Java Secure Socket
Extension (JSSE). These socket factory classes provide a simple way
to use JSSE with Java RMI, enabling enforcement of integrity,
confidentiality (through encryption), server authentication, and
(optionally) client authentication for remote method invocations.
For more information on how to use custom socket factories with
Java RMI, see the tutorial "Using Custom Socket Factories with Java
RMI". For more information on JSSE (including how to configure
it), see the JSSE
Reference Guide.rmid or a Java RMI Server from
inetd/xinetd (since Java SE 5.0)System.inheritedChannel method, allows an application
to obtain a channel (java.nio.channels.SocketChannel
or java.nio.channels.ServerSocketChannel, for example)
inherited from a process that launched the virtual machine (VM).
Such an inherited channel can be used to either service a single
incoming connection (in the case of a SocketChannel)
or accept multiple incoming connections (in the case of
ServerSocketChannel). Therefore, Java networking
applications launched by inetd (Solaris Operating
System) or xinetd (Linux) can now obtain the
SocketChannel or ServerSocketChannel
inherited from inetd/xinetd.
With the addition of this feature, the Java RMI activation
daemon rmid has been enhanced to support being
launched from inetd/xinetd so that rmid
can be started up only when it receives an incoming connection. For
details on the enhancements to rmid to support this
feature, see the tools page for rmid (for Solaris, Linux, or Mac OS X
operating systems). For details on how to configure
inetd to launch rmid, see the tutorial
"Configuring inetd to
Launch rmid".
An application using Java RMI can also be designed to be
launched from inetd or xinetd. For an
example on how to implement this technique, see the tutorial
"Designing Services to be
Launched from inetd."
rmic default stub protocol version option now
-v1.2 (since Java SE 5.0)rmic is run without an option to specify the
JRMP stub protocol version to be used by the generated classes, it
now behaves as if the -v1.2 option were specified,
instead of the -vcompat option as in previous
releases.
This change means that by default, rmic does not
generate any skeleton classes and generates stub classes that only
implement the 1.2 stub protocol version. If a remote implementation
class needs to be built to support clients running on JDK 1.1, then
the -vcompat option must now be specified explicitly.
(Also, note that as described above, if a remote implementation
class does not need to support clients running on any release prior
to Java SE 5.0, then rmic does not need to be run at all for
that class.)
See the tools documentation for rmic [Solaris, Linux, or Mac OS X] [Windows] for more information
about these command line options.
rmic no longer compiles arbitrary source files
in the class path (since Java SE 5.0)rmic would sometimes, while
processing its input class files, attempt to compile arbitrary
.java source files that it encountered in the class
path. In Java SE 5.0, rmic does not attempt to compile any
source files other than those for the stub, skeleton, or tie
classes that it generates.
The expectation is that the remote implementation classes passed
to rmic, as well as all classes and interfaces that
they depend on, have already been successfully compiled with
javac before rmic is run. If an existing
build procedure depends on the previous behavior of
rmic for compiling some of its application source
files, then that build procedure will need to be modified to ensure
that all necessary classes are correctly compiled with
javac before running rmic.
This feature is made possible by the new "programmatic access to
stack trace information" feature of java.lang.Throwable in
Java SE 1.4, which included making a Throwable's stack
trace data part of its default serialized form. What the
client-side Java RMI runtime implementation now does to cooperate
with this feature is to append the client-side trace to the
unmarshalled server-side trace, rather than simply overwriting with
the client-side trace as it did in previous releases.
Certain server applications may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled as the result of a remote call (as part of the exception's default serialized form in Java SE 1.4), perhaps for reasons of performance or confidentiality. In such cases, the implementation-specific system property
sun.rmi.server.suppressStackTracescan be set to "true" to cause the server-side Java RMI runtime implementation to clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote method invocations.
RMIClassLoader
(since Java SE 1.4)java.rmi.server.RMIClassLoader now delegate their
behavior to an instance of a new service provider interface,
java.rmi.server.RMIClassLoaderSpi. The service
provider can be configured to augment the Java RMI dynamic class
loading behavior for a given application. By default, the service
provider implements the standard behavior of all of the static
methods in RMIClassLoader. See the class documentation
of RMIClassLoader
and RMIClassLoaderSpi
for more details.java.rmi.server.hostname property can now be
dynamically updated to indicate that future exports should use a
new host name. Therefore, the new host name value will be contained
in the stub for an object that is exported after the property is
updated.sun.rmi.transport.proxy.eagerHttpFallback
has been added to allow additional control over when the Java RMI
default socket factory will fall back to HTTP tunneling. This
property configures the default socket factory so that any
SocketException thrown by an initial (direct) connection attempt
will trigger HTTP tunneling; this more "eager" fallback strategy
can be useful when dealing with firewalls which deny instead of
ignore connection attempts to unauthorized ports.java.rmi.Naming.list
Method No Longer Prepends a Scheme to Names Returned (since Java SE
1.4.1)Naming.list method
prepended the scheme rmi: to each name contained in
the returned array of strings. The Naming.list
implementation now matches the specification, returning an array of
names that are URL-formatted, but without the scheme
component.java.rmi.activation.ActivationGroupDesc
(since Java SE 1.3)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 Java SE 1.3 virtual
machine registers an new activatable object with the
ActivationSystem, rmid must also be
upgraded to run Java SE 1.3, since a pre-1.3 rmid will not be
able to activate the newly registered activatable object.
rmic (since Java SE
1.3)rmic [Solaris, Linux, or Mac OS X] [Windows] 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.
rmid (since Java SE
1.3)rmid [Solaris, Linux, or Mac OS X] [Windows] now requires a
security policy file.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 Java SE 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.