JDK-8165261 : RMI API to export an object with a serialization filter
Type:Enhancement
Component:core-libs
Sub-Component:java.rmi
Affected Version:9
Priority:P3
Status:Resolved
Resolution:Fixed
Submitted:2016-09-01
Updated:2017-05-17
Resolved:2016-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
A UnicastRemoteObject overload of exportObject should allow an ObjectInputFilter to be specified to filter the objects passed as invocation parameters.
Comments
The overloads of exportObject are needed.
Without the constructors, it might mean some restructuring of existing application subclasses of URO to
avoid the unsafe publication and explicitly export the objects.
public static Remote exportObject(Remote obj, int port,
ObjectInputFilter filter) {...}
public static Remote exportObject(Remote obj, int port,
RMIClientSocketFactory csf,
RMIServerSocketFactory ssf,
ObjectInputFilter filter) {...}
03-09-2016
You might consider not bothering with a constructor overload. The problem with UnicastRemoteObject constructors is that the object is exported before the subclass constructor is called. This results in unsafe publication. In some cases a remote call can be serviced before the subclass constructor completes. I've seen this happen in practice, but only with tests where the client in the same JVM and can "win" the race. Still, it's a window where weird things can happen. Something to look out for in this security-sensitive API.