Javy ciąg dalszy. Wracając do artykułu o serializacji obiektów trzeba opisać kolejny obcy termin, na który wtedy zwróciłem Waszą uwagę. Serializacja obiektów 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. Oto wyjaśnienia czym jest "serialVersionUID" w języku Java, które 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 poprzez implementację 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, to nie stanie się żadna tragedia. Wtedy zostanie wygenerowany automatycznie, tylko że nie będziemy mieli zielonego pojęcia jaki został przypisany :P. Jest jeden sposób na to, ale o tym za moment.
DEFINICJA PARAMETRU "SERIALVERSIONUID" W JĘZYKU JAVA
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. "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", lecz 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. Warto wiedzieć takie szczegóły, bo potem można szybko naprawić problem, a nie powiedzieć "ups!" i czekać na wybawienie ;).