相关疑难解决方法(0)

我可能会冒这个问题冒险.

在我看来,为新类显式指定serialVersionUID是不好的.考虑两种情况,即在布局应该更改时不更改它,并在不应该更改时更改它.

不应该改变它何时应该被改变发生几乎只有在它是明确的时候.在这种情况下,它会导致一些非常微妙,难以发现的错误.特别是在开发过程中,当类布局经常变化时.但是如果它没有明确指定,它将会改变并且反序列化将大声破坏,最有可能通过清除存储库来解决.

不应该发生的情况几乎只有在隐含时才会发生.这是一种罕见的情况,其中类布局已更改但我们仍希望从旧的序列化blob反序列化.这可能会在QA期间被捕获(从5.2升级到5.2.1之后的奇怪错误,请参阅附加的堆栈跟踪),并且可以通过设置显式值来轻松修复.

评论？

假设我有我的 custom RuntimeException，MyEntityJPA在哪里@Entity：

@Getter
public class MyEntityAlreadyExistingException extends RuntimeException {

    private final MyEntity myEntity;

    public MyEntityAlreadyExistingException(MyEntity myEntity) {
        super(MessageFormat.format("MyEntity with name \"{0}\" already exists", myEntity.getName()));
        this.myEntity = myEntity;
    }
}

声纳提示我进行myEntity瞬态或可序列化。

我应该如何处理这种情况？

我不使用任何 RMI，也不使用任何远程处理。它是一个相对简单的 Spring Boot Web 应用程序，带有 JPA。

如果我可以myEntity序列化，我以后可以利用哪些优势？