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.

To download the current JDK release, click here.
JDK 9
9 b139Fixed
Related Reports
Blocks :  
Relates :  
Sub Tasks
JDK-8165806 :  
Description
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.
01-09-2016