Как стать автором
Обновить

Комментарии 26

А почему Вы выбрали для работы именно gson? Почему не jackson? На основании чего Вы выбрали конкретно эту библиотеку?
Всегда удивляли такие вопросы…

А почему надо было выбрать jackson? На основании чего Вы выбрали конкретно эту библиотеку?
НЛО прилетело и опубликовало эту надпись здесь
Нет, меня удивляет такая вот дилетантская постановка вопроса.
Библиотек море и каждый использует то, что ему удобно/нравится.
Если можете сказать что-то за jackson, так и говорите:
«Почему не jackson? Он быстрее/выше/сильнее.
У него есть поддержка того-то и того-то, а gson ничего подобного нет».
Jackson гораздо популярнее gson. Посему автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа. Почитать этот анализ было бы гораздо интереснее, нежели никчемные ответы на вопросы, которые не Вам задавали, и не менее скучные возгласы на тему того, что и как часто Вас удивляет.
Так вполне себе обоснованное удивление же. Никто же не приходит в комментарии к видео «Меняем масло в Ладе-Весте своими руками» со словами: «А почему Веста? По информации с сайта kolesa.ru, Солярис самое популярное авто в России, так на каком основании вы тут делаете видео о Весте?»

Да и не понятно, насколько глубоко должны уходить эти вопросы. Например: «Почему Gson, а не Jackson? Почему json, а не protobuf? Зачем вам вообще сериализовать-десериализовать данные?» Какой из этих вопросов уже не подходит под «автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа»? Статья рассматривает один-единственный вопрос: «Как работать с Gson», а те, кому нужно сравнение с альтернативами, могут и другие источники поискать.
Потому что это стандартно встающий вопрос перед разработчиком. Вот есть n библиотек для работы с json. Какую же выбрать?! Какая лучше? Какой удобнее пользоваться? Какая быстрее? Производительность маршалинга и демаршалинга в большинстве очень важна.
Если производительность важна, надо выбирать библиотеку с API SAX-типа.
Это спасет, если вы собираетесь парсить гигабайтные json'ы. А если вы парсите много мелких json файлов, то не вижу никакого преимущества библиотек с API SAX-типа.
Еще можно парсить мегабайтные json'ы на android. В этом случае конечно же лучше выбрать Jackson
Немного странно видеть такой вопрос к обучающему материалу. Если вы хотели получить в ответ сравнительный анализ этих библиотек — извините, с jackson мне не приходилось плотно работать. Gson устраивал меня по всем параметрам, плюс — имел, на мой взгляд, более удобный API.
Но на тему сравнения подобных инструментов есть довольно много информации, правда, в основном на английском. Если вам действительно интересен такой обзор на русском языке — возможно, он заслуживает отдельной статьи.
Была у меня потребность генерировать почти-json (json, расширенный тем, что значения некоторых полей были бы кусочком кода на js).
К сожалению, попытка использовать gson для этого не увенчалась успехом: всех его богатых возможностей кастомизации оказалось недостаточно.
Все уперлось в конечном итоге в ограниченные возможности JsonWriter: String там, как положено в json, всегда в кавычках и с соответствующим escaping'ом.
И как вышли из положения?
выход — писать ручками, к сожалению,
так как задача у меня была более узкая (генерация json подобного input'а для конкретной библиотеки), то это оказалось вполне незатратно
За статью спасибо, но перенос { } на новую строку в java ужасно бесит:(
НЛО прилетело и опубликовало эту надпись здесь
У меня в IDE всё нормально. И по дефолту и в Eclipce и intellij idea скобки не переносятся ибо так в java заведено
Это у автора в IDE что то не так с форматированием кода.
А зачем было выводить имя гнома в ключ? Чтобы люди без вашего адаптера задолбались парсить это?
Нет, я понимая когда пишут свои адаптеры для типов, типа ObjectID org.bson.types.ObjectId для монги. Но вот так адаптеры под классы.
Не забывайте, статья — обучающий материал. Я сделал это именно с целью показать возможный способ использования в качестве ключа самих данных.
И кстати, да, на практике был случай, когда это действительно было удобно — при передачи данных в систему на Scala + Mongo.
И чем это было удобно? Обычный сериализатор если ему передать такие данные будет думать что это название объекта и будет пытаться найти класс с таким именем — Orin или Kodi и т.д.

Прогоните свой json с именами в виде ключей хотябы тут json2csharp.com/ и убедитесь.
Так же если отправить его в Rails он сериализует каждого гнома в отдельный хеш с именем гнома, хотя должен был бы в масив с хешами чтобы удобней по ним можно было проходить.
Простите за нытье, но меня начинает раздражать потобный стиль заголовков
«Gson или «Туда и Обратно»» или (точно не помню) «Не стреляйте себе в ногу. О разработке».

Что это? О чем это? Нужно ли мне это? Вот я вижу, что-то про json. Ну вроде я рабаю с json. Зашел. А не, это про другое. Вышел.
И таких постов все больле и больше.
Простите и меня за озвучивание очевидного, но, помимо заголовка, у статьи есть анонс, выводящийся до хабраката. В нем, по-моему, довольно четко и лаконично описано, что такое Gson, зачем он нужен, и о чем эта статья. Плюс пометка «tutorial».
Статья большая и интересная, большое спасибо автору за труд.
А некоторые комментаторы реально похожи на «бабок в очереди».
Для того, чтобы не проставлять Expose каждому полю, есть вот такое решение: stackoverflow.com/a/17733569

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

Где в этой строке "Type weaponsListType = new TypeToken<List>(){}.getType();" у вас "наследуем параметризованный класс TypeToken" ? Где тут наследование ?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий