public class Contact implements Serializable {
    private String name;
    private String email;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

1. Kiedy powinienem wdrożyć Serializableinterfejs?
2. Dlaczego to robimy?
3. Czy daje jakieś korzyści lub bezpieczeństwo?

1. Od czego to dotyczy „serializacji”? :

   Pozwala zabrać obiekt lub grupę obiektów, umieścić je na dysku lub wysłać przez przewodowy lub bezprzewodowy mechanizm transportowy, a następnie, być może na innym komputerze, odwrócić ten proces: wskrzesić oryginalny obiekt (y). Podstawowymi mechanizmami jest spłaszczenie obiektów w jednowymiarowy strumień bitów i przekształcenie tego strumienia bitów z powrotem w oryginalny obiekt (y).

   Podobnie jak w przypadku Transportera w Star Trek, chodzi o zrobienie czegoś skomplikowanego i przekształcenie go w płaską sekwencję jedynek i zer, a następnie wykonanie tej sekwencji jedynek i zer (prawdopodobnie w innym miejscu, być może w innym czasie) i odtworzenie skomplikowanej oryginału ” coś."

   Dlatego implementuj Serializableinterfejs, gdy potrzebujesz przechowywać kopię obiektu, wyślij je do innego procesu, który działa w tym samym systemie lub w sieci.

2. Ponieważ chcesz przechowywać lub wysyłać obiekt.

3. Ułatwia przechowywanie i wysyłanie przedmiotów. Nie ma to nic wspólnego z bezpieczeństwem.

1. Zaimplementuj Serializableinterfejs, jeśli chcesz mieć możliwość konwersji wystąpienia klasy na serię bajtów lub gdy myślisz, że Serializableobiekt może odwoływać się do wystąpienia Twojej klasy.

2. Serializable klasy są przydatne, gdy chcesz utrwalać ich instancje lub wysyłać je przez sieć.

3. Instancje Serializableklas można łatwo przesyłać. Serializacja ma jednak pewne konsekwencje dla bezpieczeństwa. Przeczytaj efektywną Javę Joshuy Blocha .

Odpowiedź na to pytanie brzmi, być może zaskakująco, nigdy lub bardziej realistycznie tylko wtedy, gdy jesteś zmuszony do współdziałania ze starszym kodem . To jest zalecenie w Effective Java, 3rd Edition autorstwa Joshua Blocha:

Nie ma powodu, aby używać serializacji Java w każdym nowym systemie, który piszesz

Główny architekt Oracle, Mark Reinhold, twierdzi, że usunięcie obecnego mechanizmu serializacji Java jest celem długoterminowym.

Dlaczego serializacja Java jest wadliwa

Java udostępnia jako część języka schemat serializacji, na który można się zdecydować za pomocą Serializableinterfejsu. Ten schemat ma jednak kilka trudnych do usunięcia wad i powinien być traktowany przez projektantów języka Java jako nieudany eksperyment.

• To fundamentalnie udaje, że można mówić o serializowanym postaci obiektu. Ale istnieje nieskończenie wiele schematów serializacji, co daje nieskończenie wiele serializowanych formularzy. Narzucając jeden schemat, bez możliwości zmiany schematu, aplikacje nie mogą korzystać z najbardziej odpowiedniego dla siebie schematu.
• Jest zaimplementowany jako dodatkowy sposób konstruowania obiektów, który omija wszelkie testy warunków wstępnych, które wykonują konstruktory lub metody fabryczne. O ile nie zostanie napisany skomplikowany, podatny na błędy i trudny do przetestowania dodatkowy kod deserializacji, Twój kod prawdopodobnie ma lukę w zabezpieczeniach.
• Testowanie współdziałania różnych wersji formularza serializowanego jest bardzo trudne.
• Obsługa niezmiennych obiektów jest kłopotliwa.

Co zamiast tego zrobić

Zamiast tego użyj schematu serializacji, który możesz jawnie kontrolować. Takie jak bufory protokołów, JSON, XML lub własny niestandardowy schemat.