Comments 27
А почему Вы выбрали для работы именно gson? Почему не jackson? На основании чего Вы выбрали конкретно эту библиотеку?
Всегда удивляли такие вопросы…
А почему надо было выбрать jackson? На основании чего Вы выбрали конкретно эту библиотеку?
А почему надо было выбрать jackson? На основании чего Вы выбрали конкретно эту библиотеку?
UFO just landed and posted this here
Нет, меня удивляет такая вот дилетантская постановка вопроса.
Библиотек море и каждый использует то, что ему удобно/нравится.
Если можете сказать что-то за jackson, так и говорите:
«Почему не jackson? Он быстрее/выше/сильнее.
У него есть поддержка того-то и того-то, а gson ничего подобного нет».
Библиотек море и каждый использует то, что ему удобно/нравится.
Если можете сказать что-то за jackson, так и говорите:
«Почему не jackson? Он быстрее/выше/сильнее.
У него есть поддержка того-то и того-то, а gson ничего подобного нет».
Jackson гораздо популярнее gson. Посему автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа. Почитать этот анализ было бы гораздо интереснее, нежели никчемные ответы на вопросы, которые не Вам задавали, и не менее скучные возгласы на тему того, что и как часто Вас удивляет.
Так вполне себе обоснованное удивление же. Никто же не приходит в комментарии к видео «Меняем масло в Ладе-Весте своими руками» со словами: «А почему Веста? По информации с сайта kolesa.ru, Солярис самое популярное авто в России, так на каком основании вы тут делаете видео о Весте?»
Да и не понятно, насколько глубоко должны уходить эти вопросы. Например: «Почему Gson, а не Jackson? Почему json, а не protobuf? Зачем вам вообще сериализовать-десериализовать данные?» Какой из этих вопросов уже не подходит под «автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа»? Статья рассматривает один-единственный вопрос: «Как работать с Gson», а те, кому нужно сравнение с альтернативами, могут и другие источники поискать.
Да и не понятно, насколько глубоко должны уходить эти вопросы. Например: «Почему Gson, а не Jackson? Почему json, а не protobuf? Зачем вам вообще сериализовать-десериализовать данные?» Какой из этих вопросов уже не подходит под «автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа»? Статья рассматривает один-единственный вопрос: «Как работать с Gson», а те, кому нужно сравнение с альтернативами, могут и другие источники поискать.
Потому что это стандартно встающий вопрос перед разработчиком. Вот есть n библиотек для работы с json. Какую же выбрать?! Какая лучше? Какой удобнее пользоваться? Какая быстрее? Производительность маршалинга и демаршалинга в большинстве очень важна.
Немного странно видеть такой вопрос к обучающему материалу. Если вы хотели получить в ответ сравнительный анализ этих библиотек — извините, с jackson мне не приходилось плотно работать. Gson устраивал меня по всем параметрам, плюс — имел, на мой взгляд, более удобный API.
Но на тему сравнения подобных инструментов есть довольно много информации, правда, в основном на английском. Если вам действительно интересен такой обзор на русском языке — возможно, он заслуживает отдельной статьи.
Но на тему сравнения подобных инструментов есть довольно много информации, правда, в основном на английском. Если вам действительно интересен такой обзор на русском языке — возможно, он заслуживает отдельной статьи.
Была у меня потребность генерировать почти-json (json, расширенный тем, что значения некоторых полей были бы кусочком кода на js).
К сожалению, попытка использовать gson для этого не увенчалась успехом: всех его богатых возможностей кастомизации оказалось недостаточно.
Все уперлось в конечном итоге в ограниченные возможности JsonWriter: String там, как положено в json, всегда в кавычках и с соответствующим escaping'ом.
К сожалению, попытка использовать gson для этого не увенчалась успехом: всех его богатых возможностей кастомизации оказалось недостаточно.
Все уперлось в конечном итоге в ограниченные возможности JsonWriter: String там, как положено в json, всегда в кавычках и с соответствующим escaping'ом.
За статью спасибо, но перенос
{ } на новую строку в java ужасно бесит:(А зачем было выводить имя гнома в ключ? Чтобы люди без вашего адаптера задолбались парсить это?
Нет, я понимая когда пишут свои адаптеры для типов, типа
Нет, я понимая когда пишут свои адаптеры для типов, типа
ObjectID org.bson.types.ObjectId для монги. Но вот так адаптеры под классы.Не забывайте, статья — обучающий материал. Я сделал это именно с целью показать возможный способ использования в качестве ключа самих данных.
И кстати, да, на практике был случай, когда это действительно было удобно — при передачи данных в систему на Scala + Mongo.
И кстати, да, на практике был случай, когда это действительно было удобно — при передачи данных в систему на Scala + Mongo.
И чем это было удобно? Обычный сериализатор если ему передать такие данные будет думать что это название объекта и будет пытаться найти класс с таким именем —
Прогоните свой json с именами в виде ключей хотябы тут json2csharp.com/ и убедитесь.
Так же если отправить его в Rails он сериализует каждого гнома в отдельный хеш с именем гнома, хотя должен был бы в масив с хешами чтобы удобней по ним можно было проходить.
Orin или Kodi и т.д.Прогоните свой json с именами в виде ключей хотябы тут json2csharp.com/ и убедитесь.
Так же если отправить его в Rails он сериализует каждого гнома в отдельный хеш с именем гнома, хотя должен был бы в масив с хешами чтобы удобней по ним можно было проходить.
Простите за нытье, но меня начинает раздражать потобный стиль заголовков
«Gson или «Туда и Обратно»» или (точно не помню) «Не стреляйте себе в ногу. О разработке».
Что это? О чем это? Нужно ли мне это? Вот я вижу, что-то про json. Ну вроде я рабаю с json. Зашел. А не, это про другое. Вышел.
И таких постов все больле и больше.
«Gson или «Туда и Обратно»» или (точно не помню) «Не стреляйте себе в ногу. О разработке».
Что это? О чем это? Нужно ли мне это? Вот я вижу, что-то про json. Ну вроде я рабаю с json. Зашел. А не, это про другое. Вышел.
И таких постов все больле и больше.
Статья большая и интересная, большое спасибо автору за труд.
А некоторые комментаторы реально похожи на «бабок в очереди».
А некоторые комментаторы реально похожи на «бабок в очереди».
Для того, чтобы не проставлять Expose каждому полю, есть вот такое решение: stackoverflow.com/a/17733569
Статья годная, и правильно, что без дроблений на части, спасибо.
Статья годная, и правильно, что без дроблений на части, спасибо.
Где в этой строке "Type weaponsListType = new TypeToken<List>(){}.getType();" у вас "наследуем параметризованный класс TypeToken" ? Где тут наследование ?
Вот так зайдешь случайно на Хабр 10 лет спустя - а тут комментарий.. С одной стороны - приятно, с другой - я с джавой лет 8 из этих 10 не работал уже, ничего не помню.. Пришлось гуглить. :D
Итак, если процитировать строку более полно:
наследуем параметризованный класс
TypeTokenанонимным классом
Ключевая фраза тут - анонимным классом.
Вот эти скобочки {} означают, что мы создаём инстанс анонимного класса-наследника от TypeToken (если не ошибаюсь) - но при этом ничего не меняем просто, не переопределяем и не добавляем никаких полей.
Вот, к примеру, статья про анонимные классы: https://javarush.com/groups/posts/2193-anonimnihe-klassih
По-моему так. Увидимся в 2034! :D
Sign up to leave a comment.
Gson или «Туда и Обратно»