elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
Анонс доклада: Факты и заблуждения о Java-сериализации
elizarov

Serialization ... is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer, or transmitted across a network connection link) and resurrected later in the same or another computer environment.

Wikipedia

Во вторник, 15 октября, на конференции по Java-технологиям Joker, которая пройдет в Санкт-Петербурге, я сделаю доклад про Java-сериализацию.

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

Java-сериализация является неотъемлемой часть платформы Java уже более 10 лет. Она разрабатывалась еще в те времена, когда дальнейшая судьба развития распределённых систем была туманна. Многие технологии «распределённых объектов», разрабатывавшиеся в то время, не дожили до наших дней, и некоторые отголоски этих мёртвых идей можно еще откопать в дизайне Java-сериализации. Несмотря на ряд недостатков, сериализация в Java имеет ряд неоспоримых преимуществ перед многими альтернативными способами реализации. Альтернативные способы сериализации активно рекламируются, в то время как старая добрая Java-сериализация незаслуженно забывается и обрастает совсем уж гротесковыми мифами. Например, как в любой шутке, в первоапрельской шутке JEP-154 есть и доля правды о том, что думают разработчики про Java-сериализацию.

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

Конечно, в докладе будут упомянуты и альтернативы, ведь любой выбор технологий должен быть основан на осознанном сравнении. Сейчас существует очень большое количество алтернатив, и здесь мне нужна ваша помощь. Пишите в коментарии к этой записи о том, какие библиотеки сериализации вы использовали, изучали, или с какими сталкивались в своей практике. Работающие со своим форматом сериализации или с каким-либо другим стандартом, бинарные или текстовые, JSON или XML, кроссплатформерныие или работающие только в Java, оптимизированные для записи в файл или для вызова методов по сети. Я их добавлю к списку известному мне и упомяну обо всех из них без исключений.

UPDATE: А вот и слайды


  • 1
Посольку я использую UIMA, то сериализацию выбирать не приходится. Но, любопытно, конечно, насколько UIMA не оптимальна. Я слышал отзывы, что это как раз слабое место, но кто знает, может больше миф, чем реальность.

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

Hadoop Writables, Protocol Buffers. И свои велосипеды, конечно :)

Как-то странно видеть hadoop writable в категории "формат сериализации" (в отличие от protobuf, который конечно), но после некоторого размышления скорее да.

Мы сейчас используем Gson для сериализации Java-объектов в JSON. Отлично справляется даже с приватными полями, но есть тонкости при работе с вещественными числами.

Десериализацией мы при этом не занимаемся.

Мы для своих разработок используем Thrift, т.к. данная реализация имеет встроенный RPC. Данные гоняются между модулем на Python и ядром на Java. Работает довольно шустро, правда система далеко не highload. Код генерируется ужасный на вид, но работает. Есть проблемы с передачей вещественных чисел в связке Python-Java. Приходится выкручиваться. :)

Роман, очень было бы интересно услышать в докладе о проблемах версионности сериализованных данных. Не раз сталкивался с подобным, но возможно есть какие-то хитрые наработки/best_practice.

И классика: будет ли доступен доклад в виде видео/презентации/статьи? :)

Обязательно будет. Это один из ключевых моментов всей презентации. Конечно, всё будет доступно.

продублирую в корне

JAXB

1. стандарт
2. несколько бодрых имплементаций e.g. METRO, MOXY
3. очень гибкий и удобный - полный контроль над тем что сгенерируется
4. можно идти от классов, можно от схемы (генерация классов)
5. можно в XML, можно в JSON http://blog.bdoughan.com/2011/04/jaxb-and-json-via-jettison.html
6. можно ускорять чтобы не тормозил... e.g. ThreadLocal statefull (де)сериализатора, быстрый StAX парсер (http://woodstox.codehaus.org/Performance) подробнее
http://stackoverflow.com/questions/8626153/make-jaxb-go-faster

Спасибо за ссылки. Ни разу не приходилось убыстрять JAXB, поэтому не сталкивался.

Добрый день!

Конечно Kryo! Ничего быстрее я не видел ;-) Хотя подходит только для Java to Java. Всё очень просто.

https://code.google.com/p/kryo/


Её использует KryoNet - библиотека эффективной коммуникации через TCP или UDP. Тоже всё очень просто. Умеет RMI и просто обмен сообщениями.

https://code.google.com/p/kryonet/

с опозданием добавлю свои 5 копеек... расцвет ява сериализации пришелся на технологию jini, котороя сильно опередила свое время и поэтому не была оценена рынком. сейчас именно ява сериализация для меня вещь бессмысленная, т.к. в реальной жизни приходится взаимодействовать с другими языками/платформами и объявлять wire format. в этом разрезе было бы более интересен топик "high performance serialization in java". а ObjectOutputStream пусть покоится с миром - не нужны графы объектов.

high performance serialization это когда заточено под твои конкретные нужды. Ну вот, например, для передачи миллионов котировок в секунду у нас всё с делано быстро и без ОbjectOutputStream. А для передачи бизнес объектов между узлами кластера OOS это самое то.

Извините, может я чего-то не догнал, но будет ли видео в свободном доступе?

  • 1
?

Log in

No account? Create an account