Заставить Java runtime игнорировать serialVersionUIDs?

Question

Мне приходится работать с большим количеством скомпилированных Java-классов, в которых явно не указан serialVersionUID.Поскольку их UID были произвольно сгенерированы компилятором, многие классы, которые необходимо сериализовать и десериализовать, в конечном итоге вызывают исключения, даже если фактические определения классов совпадают.(Конечно, все это ожидаемое поведение.)

Для меня непрактично возвращаться назад и исправлять весь этот сторонний код.

Поэтому мой вопрос заключается в следующем:Есть ли какой-нибудь способ создать среду выполнения Java игнорировать различия в serialVersionUIDs и десериализация не выполняется только при наличии фактических различий в структуре?

Answer 1

Если у вас есть доступ к базе кода, вы можете использовать задачу SerialVer для Ant , чтобы вставить и измените serialVersionUID в исходном коде сериализуемого класса и устраните проблему раз и навсегда.

Если вы не можете или если это не вариант (например, если вы уже сериализовали некоторые объекты, которые необходимо десериализовать), одним из решений будет расширение ObjectInputStream . Дополните его поведение, чтобы сравнить serialVersionUID дескриптора потока с serialVersionUID класса в локальной JVM, который представляет этот дескриптор, и использовать дескриптор локального класса в случае несоответствия , Затем просто используйте этот пользовательский класс для десериализации. Примерно так (кредиты это сообщение ):

import java.io.IOException;
import java.io.InputStream;
import java.io.InvalidClassException;
import java.io.ObjectInputStream;
import java.io.ObjectStreamClass;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


public class DecompressibleInputStream extends ObjectInputStream {

    private static Logger logger = LoggerFactory.getLogger(DecompressibleInputStream.class);

    public DecompressibleInputStream(InputStream in) throws IOException {
        super(in);
    }

    protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException {
        ObjectStreamClass resultClassDescriptor = super.readClassDescriptor(); // initially streams descriptor
        Class localClass; // the class in the local JVM that this descriptor represents.
        try {
            localClass = Class.forName(resultClassDescriptor.getName()); 
        } catch (ClassNotFoundException e) {
            logger.error("No local class for " + resultClassDescriptor.getName(), e);
            return resultClassDescriptor;
        }
        ObjectStreamClass localClassDescriptor = ObjectStreamClass.lookup(localClass);
        if (localClassDescriptor != null) { // only if class implements serializable
            final long localSUID = localClassDescriptor.getSerialVersionUID();
            final long streamSUID = resultClassDescriptor.getSerialVersionUID();
            if (streamSUID != localSUID) { // check for serialVersionUID mismatch.
                final StringBuffer s = new StringBuffer("Overriding serialized class version mismatch: ");
                s.append("local serialVersionUID = ").append(localSUID);
                s.append(" stream serialVersionUID = ").append(streamSUID);
                Exception e = new InvalidClassException(s.toString());
                logger.error("Potentially Fatal Deserialization Operation.", e);
                resultClassDescriptor = localClassDescriptor; // Use local class descriptor for deserialization
            }
        }
        return resultClassDescriptor;
    }
}

Answer 2

Насколько это практически невозможно исправить? Если у вас есть исходный код, и вы можете перестроить его, не можете ли вы просто запустить скрипт над всей базой кода, чтобы вставить

private long serialVersionUID = 1L;

везде?

Answer 3

Использовать CGLIB для вставки их в двоичные классы?

Answer 4

Ошибки сериализации во время выполнения четко указывают, каким будет ожидаемый идентификатор. Просто измените ваши классы, чтобы объявить их в качестве идентификатора, и все будет хорошо. Это требует от вас внесения изменений, но я не верю, что этого можно избежать

Answer 5

Возможно, вы могли бы использовать Aspectj для "введения" поля в каждый сериализуемый класс по мере его загрузки.Я бы сначала ввел интерфейс маркера в каждый класс, используя пакет, а затем ввел поле, используя хэш файла класса для serialVersionUID

public aspect SerializationIntroducerAspect {

   // introduce marker into each class in the org.simple package
   declare parents: (org.simple.*) implements SerialIdIntroduced;

   public interface SerialIdIntroduced{}

   // add the field to each class marked with the interface above.
   private long SerialIdIntroduced.serialVersionUID = createIdFromHash(); 

   private long SerialIdIntroduced.createIdFromHash()
   {
       if(serialVersionUID == 0)
       {
           serialVersionUID = getClass().hashCode();
       }
       return serialVersionUID;
   }
}

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

HTH

сте