Korzyści z wygenerowanego identyfikatora serialVersionID zamiast 1L, 2L,

Question

Mam dyskusję z kolegą na temat serialVersionUID klas serializowalnych: Zawsze zaczyna się od serialVersionUID = 1L, a następnie zwiększa ją o jeden, gdy są pewne istotne zmiany w klasie.

Klasy JDK zawsze wydają się używać bardziej skomplikowane, generowane serialVersionUIDs jak w klasie java.lang.String:

private static final long serialVersionUID = -6849794470754667710L; 

Teraz mój kolega pyta o korzyści z tego rodzaju serialVersionUID kontra znacznie prostszych serialVersionUID jak 1L, 2L , 3L ...?

Szukaliśmy również SOF, ale nie jesteśmy zbyt zadowoleni z podanych odpowiedzi, na przykład w Why generate long serialVersionUID instead of a simple 1L?.

Moim zdaniem zaletą korzystania z generowanych identyfikatorów jest to, że nie potrzebuje żadnych informacji o "starszych" wersjach klas. Jednak przy ręcznym zwiększaniu liczby identyfikatorów, musisz znać jak dotąd najwyższą wartość. Może to zabrzmieć banalnie (patrząc na bieżący serialVersionUID i zwiększyć go o 1), ale może być bardziej skomplikowany w większych projektach programistycznych, większych zespołach programistycznych lub w środowiskach rozproszonych.

Answer 1

To interesujące pytanie, od razu do rzeczy: nie wiem.

SUID jest częścią publicznego interfejsu API. Po opublikowaniu interfejsu API, który jest używany poza standardem , sterowanie, takie jak JDK, nie może zmienić tego numeru bez utraty zgodności.

Więc nie widzę żadnej korzyści z używania numeru jak 32432544354343L zamiast 1L.

Ale dla rozwoju wewnątrzobiektowych widzę małą zaletą począwszy od numeru jak 1L:

powiedzmy, że mamy 3 słoiki z aplikacji klient-serwer RMI:

• client.jar
• server.jar
• api.jar

W api.jar re to niektóre klasy biznesowe, takie jak Piosenka, Album, ... używane przez klienta i serwer, z których można serializować .

Teraz zaczynamy od SUID 1L dla niektórych z tych klas , a po wydaniu zmieniamy wewnętrzny format jednego tych klas, więc zwiększamy SUID do 2L.

Teraz zarówno klient, jak i składniki serwera muszą zawierać nowy api.jar. Jeśli popełnimy błąd i zapomnimy zaktualizować klienta lub serwer z nową zależnością api.jar, podczas deserializacji wystąpi wyjątek . Komunikat w wyjątku będzie obejmował niezgodne identyfikatory SUID.

Tak tutaj liczba 1L i 2L są w wiadomości. 2L> 1L, stąd wiemy, że komponent używa starego api.jar. Z liczbami generowanymi przez IDE, takimi jak 123434534553L i 654642646363L, nie mamy wiedzieć, który składnik używa starego api.jar.

Ale z drugiej strony nawet nowe klasy JDK, takie jak LocalDate, używają liczb takich jak 123434534553L zamiast prostszego. W apache commons-lang wydaje się, że istnieje mieszanka, np. , np. FastDateParser.java używa prostego 3L.

https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/time/FastDateParser.java

Dziwne ...

Answer 2

Zaletą korzystania wygenerowany jeden jest to, że jest kompatybilny z poprzednią wersją klasy jeśli uciekł bez serialVersionUID na wolność.

Powiedziawszy to, twój kolega prawie na pewno nie jest w stanie go zwiększyć. Zmienną serialVersionUID należy zmienić tylko w punkcie, w którym akceptujesz, że klasa się nieodwracalnie zmieniła i celowo chcesz wprowadzić niekompatybilność z serializacją. Czasy, w których ma to miejsce w przyrodzie, są rzadkością, ograniczając się do przypadków, w których zmieniasz dziedziczenie klasy lub typy pól członków w sposób niekompatybilny. Jeśli zdecydowałeś się utworzyć klasę Serializable, powinieneś już zaakceptować reżim , w którym to nie nastąpi.