Не. Используйте что-то вроде Протокол буфера .
Мыло многословно и медленно. И RMI приводит к плохому дизайну программ, когда сообщения, которые вместо отправки занимали бы наносекунды, становятся сообщениями, которые занимают микросекунды (если две программы находятся в одном окне или, возможно, в одной локальной сети) или даже миллисекунды для отправки. И это обязательно также стимулирует проекты, в которых клиент и сервер зависят друг от друга в довольно взаимосвязанной форме, как это делают вызывающая и вызываемая сторона при обычном вызове метода. Это поощряет размер горизонта состояния, чтобы охватить сквозную задержку клиента, общающегося с сервером, что может значительно замедлить его и привести к ошибкам.
Используйте методы, в которых передача сообщений является явной и которые побуждают вас сосредоточиться на данных, передаваемых через операцию, которая должна выполняться удаленной стороной. Опять же, это указывает на решение, подобное буферам протокола.
Я давно написал статью о том, почему RPC (и, соответственно, RMI) была плохой идеей . В нем я выделяю CORBA, но большинство моих аргументов применимы практически к любой форме RPC.
Кроме того, существование и популярность таких языков, как Erlang, показывают, что явная передача сообщений хороша даже для связи между различными потоками на одном и том же ЦП, где задержка и сетевые задержки не являются проблемой. Это потому, что это значительно уменьшает связь между потоками. Потоки больше не должны соглашаться всегда получать мьютекс, прежде чем делать определенные вещи или что-то в этом роде. Горизонт состояния отдельного потока больше не включает в себя состояние других потоков в системе. Это также уменьшает синхронное поведение, при котором несколько потоков хотят управлять одним и тем же мьютексом или частью общего состояния.