wat veroorzaakt deserialisatieproblemen?
Ik wil je graag wat achtergrondinformatie geven voordat ik je vraag beantwoord,
De serialisatie-runtime koppelt aan elke serialiseerbare klasse een versienummer, een serialVersionUID genaamd, dat tijdens deserialisatie wordt gebruikt om te verifiëren dat de afzender en ontvanger van een geserialiseerd object klassen voor dat object hebben geladen die compatibel zijn met betrekking tot serialisatie. Als de ontvanger een klasse voor het object heeft geladen die een andere serialVersionUID heeft dan die van de klasse van de corresponderende afzender, zal deserialisatie resulteren in een InvalidClassException.
Als een serialiseerbare klasse niet expliciet een serialVersionUID declareert, berekent de serialisatie-runtime een standaard serialVersionUID-waarde voor die klasse op basis van verschillende aspecten van de klasse. Het gebruikt de volgende informatie van de klasse om SerialVersionUID te berekenen,
- De klasnaam.
- De class modifiers geschreven als een 32-bits geheel getal.
- De naam van elke interface gesorteerd op naam.
- Voor elk veld van de klasse gesorteerd op veldnaam (behalve persoonlijke statische en persoonlijke tijdelijke velden:
- De naam van het veld.
- De modifiers van het veld geschreven als een 32-bits geheel getal.
- De descriptor van het veld.
-
als er een klasse-initiator bestaat, schrijf dan het volgende op:
De naam van de methode, .
De modifier van de methode, java.lang.reflect.Modifier.STATIC, geschreven als een 32-bits geheel getal.
De descriptor van de methode, ()V.
-
Voor elke niet-private constructor gesorteerd op naam en handtekening van de methode:
De naam van de methode, .
De modifiers van de methode geschreven als een 32-bits geheel getal.
De descriptor van de methode.
-
Voor elke niet-private methode gesorteerd op methodenaam en handtekening:
De naam van de methode.
De modifiers van de methode geschreven als een 32-bits geheel getal.
De descriptor van de methode.
Dus, om je vraag te beantwoorden,
Zou een verwijdering van een openbaar/privaat eigendom een probleem opleveren? Nieuwe eigenschappen toevoegen, misschien? Zou het toevoegen van een nieuwe functie aan de klasse problemen veroorzaken? Hoe zit het met meer constructeurs?
Ja, al deze toevoegingen/verwijderingen zullen standaard het probleem veroorzaken.
Maar een manier om dit te verhelpen is om de SerialVersionUID expliciet te definiëren, dit zal het serialisatiesysteem vertellen dat ik weet dat de klasse in de loop van de tijd zal evolueren (of geëvolueerd) en geen fout zal veroorzaken. Dus het de-serialisatiesysteem leest alleen die velden die in beide zijden aanwezig zijn en wijst de waarde toe. Nieuw toegevoegde velden aan de deserialisatiezijde krijgen de standaardwaarden. Als sommige velden aan de deserialisatiekant worden verwijderd, leest het algoritme gewoon en slaat het over.
Hieronder volgt de manier waarop men de SerialVersionUID kan declareren,
private static final long serialVersionUID = 3487495895819393L;