Я бы использовал подход с несколькими загрузчиками классов.

(Переименование пакетов также сработает. Это выглядит некрасиво, но это одноразовый прием, поэтому красота и правильность могут отойти на второй план. Промежуточная сериализация кажется рискованной — была причина, по которой вы используете Kryo, и эта причина будет отменена. с использованием другой промежуточной формы).

Общий дизайн будет таким:

child classloaders:      Old Kryo     New Kryo   <-- both with simple wrappers
                                \       /
                                 \     /
                                  \   /
                                   \ /
                                    |
default classloader:    domain model; controller for the re-serialization

1. Загрузите классы объектов домена в загрузчик классов по умолчанию.

2. Загрузите банку с модифицированной версией Kryo и кодом оболочки. Оболочка имеет статический метод main с одним аргументом: имя файла для десериализации. Вызовите основной метод через отражение из загрузчика классов по умолчанию:

       Class deserializer = deserializerClassLoader.loadClass("com.example.deserializer.Main");
       Method mainIn = deserializer.getMethod("main", String.class);
       Object graph = mainIn.invoke(null, "/path/to/input/file");
   

   1. This method:
      1. Deserializes the file as one object graph
      2. Помещает объект в общее пространство. ThreadLocal — это простой способ или его возврат к скрипту-оболочке.

3. Когда вызов вернется, загрузите второй Jar с новой структурой сериализации с помощью простой оболочки. У оболочки есть статический «основной» метод и аргумент для передачи имени файла для сериализации. Вызов основного метода через отражение из загрузчика классов по умолчанию:

       Class serializer = deserializerClassLoader.loadClass("com.example.serializer.Main");
       Method mainOut = deserializer.getMethod("main", Object.class, String.class);
       mainOut.invoke(null, graph, "/path/to/output/file");
   

   1. This method
      1. Retrieves the object from the ThreadLocal
      2. Сериализирует объект и записывает его в файл

Соображения

Во фрагментах кода создается один загрузчик классов для каждой сериализации и десериализации объекта. Вы, вероятно, захотите загрузить загрузчики классов только один раз, открыть основные методы и перебрать файлы, например:

for (String file: files) {
    Object graph = mainIn.invoke(null, file + ".in");
    mainOut.invoke(null, graph, file + ".out");
}

Имеют ли объекты предметной области какую-либо ссылку на какой-либо класс Kryo? Если это так, у вас есть трудности:

1. Если ссылка является просто ссылкой на класс, например, для вызова метода, то при первом использовании класса будет загружена одна из двух версий Kryo в загрузчик классов по умолчанию. Это вероятно вызовет проблемы, поскольку часть сериализации или десериализации может быть выполнена неправильной версией Kryo.
2. Если ссылка используется для создания экземпляров любых объектов Kryo и сохранения ссылки в модели предметной области (члены класса или экземпляра), то Kryo фактически сериализует часть себя в модели. Это может стать препятствием для такого подхода.

В любом случае, ваш первый подход должен состоять в том, чтобы изучить эти ссылки и удалить их. Один из способов убедиться, что вы это сделали, — убедиться, что загрузчик классов по умолчанию не имеет доступа к какой-либо версии Kryo. Если объекты домена каким-либо образом ссылаются на Kryo, ссылка завершится ошибкой (с ClassNotFoundError, если на класс ссылаются напрямую, или ClassNotFoundException, если используется отражение).

Для 2 вы можете создать два файла jar, которые содержат сериализатор и все зависимости для новой и старой версий вашего сериализатора, как показано здесь. Затем создайте задание по сокращению карты, которое загружает каждую версию вашего кода в отдельный загрузчик классов, и добавьте некоторый связующий код в середине, который десериализуется со старым кодом, а затем сериализуется с новым кодом.

Вы должны быть осторожны, чтобы ваш объект домена загружался в тот же загрузчик классов, что и ваш связующий код, а код для сериализации/десериализации зависит от того же загрузчика классов, что и ваш связующий код, чтобы они оба видели один и тот же класс объекта домена.

Самый простой способ, который я придумал, не задумываясь, — это использование дополнительного Java-приложения, выполняющего преобразование за вас. Таким образом, вы отправляете двоичные данные во вторичное Java-приложение (простые локальные сокеты прекрасно справятся с этой задачей), поэтому вам не нужно возиться с загрузчиками классов или пакетами.

Единственное, о чем нужно думать, это промежуточное представление. Возможно, вы захотите использовать другой механизм сериализации или, если время не имеет значения, вы можете использовать внутреннюю сериализацию Java.

Использование второго Java-приложения избавляет вас от необходимости иметь дело с временным хранилищем и делать все в памяти.

И когда у вас есть эти сокеты + второй код приложения, вы обнаружите массу ситуаций, когда это пригодится.

Также можно построить локальный кластер с помощью jGroups и в конце концов избавить себя от хлопот с сокетами. jGroups — это самый простой API для связи, который я знаю. Просто сформируйте логический канал и проверьте, кто присоединяется. И лучше всего это даже работает в одной и той же JVM, что упрощает тестирование, и, если это делается удаленно, можно связать разные физические серверы вместе точно так же, как это работает для локальных приложений.

Еще одна переменная альтернатива — использование ZeroMQ с его протоколом ipc (межпроцессное взаимодействие).