Godzina dwunasta, zatem piszę po raz drugi. Wracając do tamtego artykułu trzeba opisać kolejny obcy termin, na który wtedy zwróciłem Waszą uwagę. Serializacja obiektów w Javie wiąże się z dużą odpowiedzialnością. To nie jest temat, który powinien być w rękach kompletnej amatorszczyzny. Po czym rozpoznać doświadczonego od początkującego w tym temacie? Jeden wstawi ważną stałą "serialVersionUID" do klasy, a drugi nie. Wyjaśnienia czym jest "serialVersionUID" w języku Java zostawiam w środku.
| Tweet |
"SERIALVERSIONUID"?! PIERWSZE SŁYSZĘ!
To niedobrze. Jest to nic innego jak stała typu "long" przechowująca liczbowy identyfikator. Gdy oznaczamy jakąś klasę, która może być serializowana (implementacja interfejsu "Serializable"), w trakcie "mielenia" obiektów wirtualna maszyna "doczepia" jeszcze specjalne liczbowe ID będące w stanie jednoznacznie ustalić klasę do której ten obiekt ma należeć. Jeżeli samodzielnie nie ustalimy identyfikatora, mamy DUŻE kłopoty w przypadku modyfikacji klasy po dokonaniu zapisu danych!
Tuż przed podjęciem próby deserializacji danych, Java porównuje ze sobą identyfikatory zarówno obecnej struktury klasy, jak i zapisanej wartości w pliku. Gdy dokonamy modyfikacji struktury klasy dodając choć jedną nową daną składową czy metodę, klasa otrzymuje ZUPEŁNIE INNY "serialVersionUID". Gdy pominiemy ten parametr przed pierwszą serializacją danych, zostanie wygenerowany automatycznie, tylko że nie będziemy mieli zielonego pojęcia jaki został przypisany. Jest jeden sposób na to, ale o tym za moment.
DEFINICJA PARAMETRU "SERIALVERSIONUID" W JĘZYKU JAVA
Napisałem o tym już wcześniej nawet jakich modyfikatorów używać, ale oczywiście przypomnę o tym po raz kolejny. Prawidłowa definicja stałej powinna wyglądać w taki sposób:
private static final long serialVersionUID = [dowolna liczba zakończona dużą literą L];I już wyjaśniam po kolei co, jak, dlaczego. Modyfikator dostępu "private", aby nie można było zmienić tego na zewnątrz. "static", żeby to była dana przechowywana w klasie, a nie w każdym osobnym obiekcie duplikować niepotrzebnie to samo. "final", gdyż musi to być stała wartość, a więc musi być cały czas taka sama i niezmienna od początku do samego końca trwania procesu. "long", ponieważ generowane identyfikatory przyjmują liczby całkowite z zakresu wykraczającego poza zakres typu "int".
PROGRAM "SERIALVER" RECEPTĄ NA ZBADANIE IDENTYFIKATORA
Na sam koniec kilka zdań o specjalnym programie narzędziowym zdolnym do badania identyfikatorów. Java posiada małe narzędzie o nazwie "serialver", które pozwala uratować sytuację, gdy serializowany obiekt otrzymał już losowo wygenerowany "serialVersionUID" w języku Java, a my już dokonaliśmy modyfikacji w klasie i nie wiemy jaki to jest numer. Po otwarciu wiersza poleceń, wpisujemy polecenie "cd" i wyszukujemy lokalizacji w której znajduje się katalog ze skompilowanymi plikami klasowymi (nie pliki źródłowe ".java"!) ignorując ciąg folderów reprezentujących nazwy pakietów, to ważne! Po czym podajemy kolejne polecenie:
serialver [nazwa pakietu].[nazwa klasy]
Wówczas uruchamiany program przeszukuje daną klasę i na jej podstawie wypisuje aktualny numer ID.
 |
Tak wygląda uruchomienie programu "serialver" ukazujące "serialVersionUID" klasy "Point" w języku Java z przykładu w jednym z poprzednich artykułów.
Powyższy wycinek ukazuje co prawda uruchamianie z lokalizacji projektu programu "IntelliJ IDEA", ale przy ręcznym kompilowaniu przy użyciu "javac" też nie będzie problemów. Po prostu musicie ustawić katalog roboczy taki sam gdzie znajdują się skompilowane pliki klasowe z rozszerzeniem ".class".
To by było tyle z tego tematu. Dzięki za przeczytanie, warto wiedzieć takie szczegóły bo po nich można zobaczyć kto naprawdę się uczy programowania, a kto tylko patrzy na kasę.