Сериализация (Serialize, в последующем «сохранение») – это процесс сохранения данных объекта во внешнем хранилище.
Эта операция работает в паре с обратной – восстановлением данных, называемой десереализацией (Deserealize, в последующем «восстановление»).

Операции сохранения и восстановления данных применяются очень часто. В классических языках программирования готовых механизмов для сохранения и восстановления данных объектов нет и, при возникновении такой необходимости, приходится создавать их самостоятельно.

В Java такие готовые механизмы существуют и, даже, в количестве более одного. Давайте разберемся, какие механизмы есть и какие возможности они предоставляют для программ на Kotlin.

Само понятие сериализации никак не привязано к формату данных, в который будут сохранены данные, поэтому вне зависимости от того, какой результат будет получен – бинарный файл с собственной структурой, формат XML, JSON или даже текстовый файл – все это будет сериализацией.

Сериализация

В классических языках программирования нет готовых возможностей для сохранения структурированных объектов, но, т.к. структуры данных напрямую лежат в памяти, есть легкий способ сохранения и восстановления данных напрямую. С одной стороны, создавать собственные средства для сохранения нужно только в том случае, когда требуется сохранять сложные объекты со взаимосвязями друг с другом но, с другой, даже если хочется использовать какой-то максимально простой готовый механизм, то реализация сохранения данных в его формат – это довольно трудоемкая операция.

В Java данные элементов одного объекта произвольно разбросаны по памяти JVM, поэтому даже если бы была возможность сохранения структуры объекта целиком, сохранить данные бы не получилось, поэтому единственно возможный путь в Java – это поэлементное сохранение данных элементарных типов из которых состоит объект.
С одной стороны использовать сохранение объектов целиком, одной операцией, в Java невозможно, зато, благодаря наличию развитой RTTI, использование готовых средств для сохранения может быть реализовано очень легко.

Многие классы потоков, такие как Writer или PrintStream предоставляют готовые возможности для сохранения элементарных типов данных, но использовать эти так же неудобно, как и в классических языках программирования из-за очень большого числа описаний, которые необходимо проделывать.
Но, помимо работы с элементарными типами, в Java существует несколько разных типов готовых механизмов для сохранения данных классов и множество библиотек, реализующих работу с одними и теми же форматами, отличающихся друг от друга производительностью, объемом и предоставляемыми возможностями.

Ниже будут рассмотрены типовые способы сохранения данных: встроенные в стандартную библиотеку Java, а так же сохранение в формате XML и JSON.

Serializable

Простейшая возможность, существующая в стандартной библиотеке Java – это сохранение и восстановление данных в полностью автоматическом режиме в бинарной форме. Для реализации этой возможности необходимо всего лишь указать у всех классов, данные которых должны автоматически сохраняться и восстанавливаться, интерфейс Serializable в качестве реализуемого. Это интерфейс «маркер», который не требует реализации ни одного метода. Он используется просто для обозначения того, что данные этого класса должны сохраняться и восстанавливаться.

Пример использования

Использование этого класса элементарно – одной операцией и не требует написания ни одной лишней буквы.

class DataClass(s : String) : Serializable {
  @JvmField var strField = ""
  @JvmField var intField = 0
  @JvmField var dbField = 0.0
  protected @JvmField var strProt = ""
  private var strPriv = ""
  @JvmField val valStr : String
  protected @JvmField val valProt : String

  init {
    valStr = s
    valProt = "prot=" + s

    strField = s + ":baseText"
    intField = s.hashCode()
    dbField = s.hashCode().toDouble() / 1000
    strProt = s+":prot"
    strPriv = s+":priv"
  }

  fun print() {
    outn("str = [%s]\nint = [%d]\ndb = [%f]", strField, intField, dbField)
    outn("prot = [%s]\npriv = [%s]", strProt, strPriv) 
    outn("value = [%s]\nprot value = [%s]", valStr, valProt)
  }
}

fun Action() {
  outn( "Simple object IO test" )

  val a = DataClass("dataA")
  outn("Saved contents:")
  a.print()

  Holder(ObjectOutputStream(File("out.bin").outputStream())).h.writeObject(a)
  val b = Holder(ObjectInputStream(File("out.bin").inputStream())).h.readObject()

  outn("Class: %s", b.javaClass.name)
  if (b is DataClass) {
    outn("Loaded contents:")
    b.print()
  }
}

В результате выполнения этого теста мы получим следующий вывод:

Simple object IO test
Saved contents:
str = [dataA:baseText]
int = [95356375]
db = [95356,375000]
prot = [dataA:prot]
priv = [dataA:priv]
value = [dataA]
prot value = [prot=dataA]
Class: app.test.Externalize.Test$DataClass
Loaded contents:
str = [dataA:baseText]
int = [95356375]
db = [95356,375000]
prot = [dataA:prot]
priv = [dataA:priv]
value = [dataA]
prot value = [prot=dataA]

Как уже видно из результата сохранение и восстановление объекта прошло успешно и, после восстановления, новый объект имеет точно такое же содержимое как сохраняемый.
При выполнении программы был создан файл "out.bin" размером в 244 байта в бинарном формате. Описание формата можно найти во множестве источников, но, на мой взгляд, разбираться в нем не имеет никакого смысла, достаточно, чтобы его успешно понимали операции сохранения и восстановления.

Особенности

Если рассмотреть приведенный выше пример подробнее, то можно увидеть следующие особенности.

• Были сохранены и восстановлены абсолютно все поля, даже те у которых указан тип доступа "private" и "protected".
• Обработаны были и поля, указанные как «val», т.е. неизменяемые по стандартам Kotlin.
• Новый объект был создан, хотя конструктора без параметров у него нет, а существующий не вызывался.

В результате понятно, что состояние объекта сохраняется и восстанавливается минуя все синтаксические ограничения, которые указаны в тексте программы. Иногда такая особенность реализации является плюсом но, иногда, она может являться и принципиальным ограничением на ее использование.

Возможности

Несмотря на кажущуюся простоту этого метода, он предоставляет очень мощный механизм, которым крайне легко и просто пользоваться. У него есть свои недостатки, которые будут описаны ниже, но, часто, его возможностей вполне достаточно для всего, что может понадобиться программисту.

Для более точного управления процессом сохранения и восстановления данных можно использовать дополнительные механизмы.

Контроль версии

Т.к. сохранение данных объекта происходит полностью автоматически, то должен быть механизм, который контролирует совместимость сохраненных данных с текущей структурой объекта. Т.е. если мы добавили или удалили поле в классе, поменяли порядок полей или их тип, то при восстановлении данных они должны попасть на то место, для которого предназначены сохраненные данные.

Такой механизм контроля совместимости существует. При сохранении библиотека автоматически вычисляет код для используемого класса, который описывает его состояние и, при восстановлении, проверяет совместим ли объект с теми данными, которые были сохранены для него ранее. Если к восстанавливаемому классу были добавлены поля или изменен их порядок, то восстановить данные из сохраненной копии можно, но если поля были удалены или у них изменился тип, то восстановить такие данные уже будет невозможно и, при попытке чтения такого объекта, будет выброшена ошибка.

Код описывающий состояние класса может быть вычислен автоматически, при сохранении объекта, но, если класс не планируется изменять в дальнейшем или хочется отключить этот механизм проверки, то можно использовать специальное поле класса.

class DataClass : Serializable {
 companion object {
    const private val serialVersionUID = 1L
  }
}

Это поле должно быть статической константой типа Long, описанной в классе.
В случае Kotlin эта константа обязана быть описана с использованием аннотации @JvmStatic или модификатора const, иначе библиотека загрузки его не увидит.

При восстановлении данных проверяется значение кода из потока с тем, которое вычислено или записано константой у нужного класса в момент сохранения и, если эти значения не совпадают, будет выброшено исключение с ошибкой.
Тип доступа поля serialVersionUID не играет никакой роли, оно может быть как публичным, так и скрытым.
После того, как класс принял окончательную форму и его изменение более не планируется, рекомендуется описать эту константу в классе, чтобы избежать ее расчета при каждой загрузке и сохранении. Значение этой константы может отражать реальное состояние класса, и тогда ее нужно вычислить с помощью методов библиотеки, или содержать любое произвольное значение, если соответствие класса не важно.

Для вычисления значения состояния класса можно воспользоваться утилитой «serialver» из поставки Java, но использовать ее неудобно, поэтому гораздо проще получить это значение программным путем. Для этого нужно в программе, которая использует нужный класс, вызвать метод для вычисления его состояния и полученное значение установить в поле serialVersionUID.

fun Action() {
  println( "ID: %d\n", ObjectStreamClass.lookup(DataClass::class.java).serialVersionUID )
  //…
}

Вывод программы:

ID: 991989581060349712

Управление сохраняемыми данными

Часто сохранять и восстанавливать нужно не все существующие у объекта данные, но только часть из них или восстанавливать их в формате, которые не соответствует их фактическому типу.

Первой возможностью управления является механизм исключений.
Для того, чтобы исключить какое-то поле из списка обрабатываемых его нужно пометить специальным типом "transient". В Java для этого используется специальное ключевое слово, а в Kotlin необходимо использовать специальную аннотацию.

class DataClass : Serializable {
  @JvmField var strField = ""
  @JvmField var intField = 0
  @Transient
  @JvmField var dbField = 0.0
}

При обработке объектов этого класса библиотека сериализации не будет ни сохранять ни восстанавливать значения для поля "dbField". Все остальные поля будут сохранены и восстановлены как обычно.
Этот механизм удобно использовать в случаях, когда объекты поля, значения которых не имеет смысла или нельзя сохранять.
Устанавливать значения полей, которые не будут обрабатываться автоматически, программист должен самостоятельно, после загрузки. Для этого можно воспользоваться методом "readResolve", который описан ниже.

Вторая возможность управления сохранением заключается в том, что можно указать имена и типы полей, которые будут использованы для сохранения и загрузки.
При развитии объекта, иногда, требуется возможность восстанавливать его содержимое, даже если формат объекта уже полностью изменился. Для этого нужно уметь читать поля, которых в классе уже нет, у которых изменилось имя или тип. Это можно усуществить с помощью механизма фильтрации полей, описав статическую константу с именем serialPersistentFields.

open class DataClass(s : String) : Serializable {
  @JvmField var strField = ""
  @JvmField var intField = 0
  @JvmField var dbField = 0.0

  companion object {
    const private val serialVersionUID1 = 1L
    @JvmStatic val serialPersistentFields = arrayOf(
      ObjectStreamField("strField",String::class.java),
      ObjectStreamField("intField",Int::class.java)
    )
  }

  init {
    strField = s + ":baseText"
    intField = s.hashCode()
    dbField = s.hashCode().toDouble() / 1000
  }

  fun print() =
    outn("str = [%s]\nint = [%d]\ndb = [%f]", strField, intField, dbField)
}

fun Action() {
  val a = DataClass("dataA")
  outn("Saved contents:")
  a.print()

  Holder(ObjectOutputStream(File("out.bin").outputStream())).h.writeObject(a)
  val b = Holder(ObjectInputStream(File("out.bin").inputStream())).h.readObject()

  if (b is DataClass) {
    outn("Loaded contents:")
    b.print()
  }
}

Теперь наш пример сохраняет только два поля из трех доступных.

Saved contents:
str = [dataA:baseText]
int = [95356375]
db = [95356,375000]
Loaded contents:
str = [dataA:baseText]
int = [95356375]
db = [0,000000]

Сохранение и восстановление данных вручную

Иногда, описать структуру или изменения в ней так, чтобы автоматизированные средства работали без ошибок не удается. В таком случае нужно сохранять или восстанавливать значения полей класса вручную, но при этом не хотелось бы лишаться всех преимуществ, предоставляемых автоматизированными средствами.

Предположим, что в нашем объекте у одного из полей изменилось имя и при этом нужно обеспечить сохранение
и загрузку данных и с новым и со старым именем. Средства автоматизации справиться с таким изменением неспособны, но можно оперировать полями объекта вручную. У сериализуемого объекта можно описать функции writeObject и readObject, которые будут вызваны для загрузки и сохранения его содержимого.

open class DataClass(s : String) : Serializable {
  @JvmField var strField = ""
  @JvmField var intFieldChanged = 0
  @JvmField var dbField = 0.0

  companion object {
    const private val serialVersionUID1 = 1L
    @JvmStatic val serialPersistentFields = arrayOf(
      ObjectStreamField("strField", String::class.java),
      ObjectStreamField("intField", Int::class.java)
    )
  }

  init {
    strField = s + ":baseText"
    intFieldChanged = s.hashCode()
    dbField = s.hashCode().toDouble() / 1000
  }

  fun print() =
    outn("str = [%s]\nint = [%d]\ndb = [%f]", strField, intFieldChanged, dbField)

  private fun readObject(s : ObjectInputStream) {
    val fields = s.readFields()
    strField = fields.get("strField", "" as Any?) as String
    intFieldChanged = fields.get("intField", 0)
  }

  private fun writeObject(s : ObjectOutputStream) {
    val fields = s.putFields()
    fields.put("strField", strField as Any?)
    fields.put("intField", intFieldChanged)
    s.writeFields()
  }
}

В этом примере поле класса теперь называется intFieldChanged, но в сохраняемых данных его имя по прежнему будет фигурировать как intField, что позволит загружать данные сохраненные со старым именем и сохранять их в таком виде, что старый класс будет способен их загрузить.

В тексте функций writeObject и readObject можно реализовать произвольную логику сохранения и загрузки данных.
Можно пользоваться механизмами, предоставляемыми библиотекой, как это реализовано в примере выше, а можно реализовать сохранение и восстановление объекта полностью вручную. Правда в последнем случае будет сложно обеспечить преемственность сохраняемой структуры, как это реализовано в примере, но, часто, такой необходимость нет. В случае ручного оперирования данными нужно обеспечить, чтобы данные восстанавливались в том же порядке, в котором они были сохранены.

open class DataClass(s : String) : Serializable {
  @JvmField var strField = ""
  @JvmField var intField = 0

  companion object {
    const private val serialVersionUID1 = 1L
  }

  init {
    strField = s + ":baseText"
    intField = s.hashCode()
  }

  fun print() =
    outn("str = [%s]\nint = [%d]", strField, intField)

  private fun readObject(s : ObjectInputStream) {
    strField = s.readUTF()
    intField = s.readInt()
  }

  private fun writeObject(s : ObjectOutputStream) {
    s.writeUTF(strField)
    s.writeInt(intField)
  }
}

Восстановление синглетонов

При восстановлении данных библиотека автоматически восстановит ссылки на объекты, но для работы с объектами, которые существуют в единственном экземпляре этого недостаточно т.к. при загрузке будет создан один, но новый объект, тогда как нужно, чтобы загруженные элементы ссылались на уже существующий в программе.

Это поведение, так же, можно обеспечить.

Для этого достаточно у класса, который должен обеспечивать уникальность, создать метод readResolve. Этот метод будет вызван после загрузки любого объекта этого класса и позволяет заменить его другим.

class LinkedData private constructor(@JvmField val value : Int) : Serializable {
  companion object {
    @JvmField val ZERO = LinkedData(0)
    @JvmField val NONZERO = LinkedData(1)
    @JvmStatic fun make(v : Int) = if (v == 0) ZERO else NONZERO
  }

  private fun readResolve() : Any = if ( value == 0 ) ZERO else NONZERO
}

open class DataClass(v : Int) : Serializable {
  @JvmField val link = LinkedData.make(v)
  @JvmField var intField = v

  companion object {
    const private val serialVersionUID1 = 1L
  }

  fun print() =
    outn("int = [%d]\nlink = [%s]",
         intField,
         if (link == LinkedData.ZERO) "ZERO" else
         if (link == LinkedData.NONZERO) "NONZERO" else
           "OTHER!" )
}

Результат работы программы:

Saved contents:
int = [100]
link = [NONZERO]
Loaded contents:
int = [100]
link = [NONZERO]

Теперь, при загрузке любого объекта класса LinkedData у загруженного объекта будет вызвана функция readResolve и, если понадобится заменить загруженный объект другим, достаточно вернуть его из этого метода.
В нашем примере код вернет один из уже существующих объектов этого класса, обеспечив его уникальность и идентичность.

Сохранение нестандартных классов, прокси

В случае, если необходимо реализовать прозрачную работу с собственными классами, например с коллекциями в собственном формате или обеспечить подмену интерфейса класса (проксирование), то это тоже можно реализовать.
Для этого нужно создать наследника для классов ObjectInputStream и ObjectOutputStream переопределив у них методы annotateClass или annotateProxyClass.

Первый предназначен для обеспечения загрузки и сохранения неизвестных классов, а второй для проксирования интерфейса классов.

Недостатки

Библиотека, реализующая функционал интерфейса Serializable очень могучая, но она имеет ряд серьезных недостатков, которые в некоторых случаях могут являться принципиальным ограничением для ее использования.

ВАЖНО: Serializable работает только с полями!

Самый важный недостаток этого метода заключается в том, что он способен работать только с полями.

Если вы реализуете интерфейс, где значение поля «эмулируется» парой функций для установки и получения значения, если в ваших класса используются делегаты и прочие способы описания свойств, которые не имеют соответствующего поля в классе, то этот механизм окажется абсолютно бесполезен. Он способен сохранить и восстановить только данные, описанные в классе в виде полей, а для всех остальных придется реализовывать их сохранение и загрузку вручную.

class LinkedData private constructor(@JvmField val value : Int) {
  companion object {
    @JvmField val ZERO = LinkedData(0)
    @JvmField val NONZERO = LinkedData(1)
    @JvmStatic fun make(v : Int) = if (v == 0) ZERO else NONZERO
  }
}

open class DataClass : Externalizable {
  @JvmField var link : LinkedData
  @JvmField var intField : Int

  constructor() { link = LinkedData.ZERO; intField = 0 }
  constructor(v : Int) { link = LinkedData.make(v); intField = v }

  fun print() = outn("int = [%d]\nlink = [%s]", intField,
                     if (link == LinkedData.ZERO) "ZERO" else
                       if (link == LinkedData.NONZERO) "NONZERO" else
                         "OTHER!")

  override fun readExternal(s : ObjectInput) {
    link = if ( s.readByte().toInt() == 0 ) LinkedData.ZERO else LinkedData.NONZERO
    intField = s.readInt()
  }

  override fun writeExternal(s : ObjectOutput) {
    s.writeByte(if(link == LinkedData.ZERO) 0 else 1)
    s.writeInt(intField)
  }
}

  0) <noname>   addCaller.t_ForOrGetPut   org.sun.NotNotEmptyGetEach( SetEmptyCombineSplit )
  1) fNotRandom           addCaller.For(void, addCaller.t_HasEmpty Has, addCaller.t_Combine GetCombineHas )
  2) fOrSet           app.PutHasForGet( app.t_Set HasCombineAdd, app.t_ForNotOrAdd Combine )
  3) fHasSplit            org.sun.Set(  Set, sec.sun.t_JoinEmptyHasCombineCombine EmptyCombineOr )
  4) fJoinEach    sec.sun.t_OrForEmptySet   sec.sun.EachPutOrNot( org.sun.t_Combine SetHasSplitJoinEmpty, void )
  5) fEachSet   org.sun.t_RandomSplit   app.OrIsFor( sec.sun.t_Set CombineGetRandom, void )
  6) <noname>   app.t_NotSetForForGet   sun.NotHasForSplitAdd( org.sun.t_IsRandomOrHas Each, void)
  7) fNotSplit    addCaller.t_NotAdd      sec.sun.IsHasNot( app.t_HasForSplitHas ForGet, void )
  8) <noname>           sun.SetForSplitSet( PutCombine, void, void )
  9) fCombineNot  sun.t_SplitRandomGetRandom  sun.AddAdd( void, org.sun.t_NotRandomHasEmpty AddPutNotSplit )
 10) <noname>   addCaller.t_ForIs     sun.EachIs( NotFor, void, void,  PutSplitAddNot )
 11) fSetOr           app.HasJoin( OrOr, void, void, addCaller.t_NotAddHas Each )

USAGE: SerializableTest.jar [-opts]

Where OPTS are:
  -Count=<number>        - set number of items to generate
  -Retry=<number>        - set number of iterations for each test
  -Out=<file>            - set file name to output
  -Nout                  - disable items output
  -gc                    - run gc after every test

>sb -n "-c=100000" "-r=10"
Output file       : test_out
Number of elements: 100000
Number of retries : 10
Tests complete in 0:01:28.050 sec :: Save 0:00:31.903, Load 0:00:30.149, Total 0:01:02.103, Waste 0:00:25.947