Да, как вы уже сказали в вопросе:
RMIClientSocketFactory должен быть сериализуемым, а будет сериализован на клиентской стороне , если используется с exportObject
или конструктором UnicastRemoteObject.
Это означает, что он не должен содержать (непереходные) ссылки на объекты, которые не являются сериализуемыми, только необходимую информацию для создания сокета на лету.
(я недавно опубликовал пример для RMISocketFactory , где мне нужно было позаботиться о том, чтобы сериализоваться.)
Редактировать (после комментария от EJP):
Конечно, это применимо только , если вам нужно использовать фабрику клиентских сокетов вообще . Во многих случаях вы можете просто использовать другие методы exportObject
(или другие конструкторы), которые затем используют фабрику сокетов сервера по умолчанию на стороне сервера и фабрику сокетов клиента по умолчанию на стороне клиента, без сериализации.
И да, нет смысла сериализовать хранилище доверенных сертификатов сервера для клиента - если клиент должен доверять реестру или другим удаленным объектам, для которых сертификаты должны приниматься, у нас есть точка для человека-посредника. средняя атака. Таким образом, SslRMIClientSocketFactory , будучи сериализуемым, не сериализует контекст SSL сервера, а просто использует настройки SSL клиентской виртуальной машины.