Попроси Джейка Вортановича написать)

ну он вроде не единственный программист на деревне)

Перевод статьи Mike Hearn'а о том почему они использовали Kotlin в Corda и какой опыт они получили. Оригинальная статья дотирована январем 2017. https://habr.com/post/422549/

статя дОтирована?

В этом что-то есть

Спасибо, уже поправил

Занятно что автор указал ссылкой на оригинал kotlin.link) https://kotlin.link/articles/Corda-Kotlin.html

https://www.corda.net/2017/01/10/kotlin/ А ссылочка с kotlin.link, кстати, ведёт вникуда.

Да, видимо поэтому. И оригинал в гугле не могу найти. Все-таки не зря архивировал статьи)

Похоже, сейчас у них блог на медиуме, и статья по Котлину туда не переехала. ?

What is lambda?

Всем привет, ребят расскажите новичку зачем в котлин избавились от cheked exception?

Всем привет, ребят расскажите новичку зачем в котлин избавились от cheked exception?

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

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

Ну просто странная история получается, например мы отправляем какой то вызов в библиотеку которая кидает например io, то есть получается мне нужно лезть в сорсы чтобы понять это? Я понимаю что мехонизм сам по себе сложный, я про то когда там через 5 классов исключение сквозное и тд, но тем не менее все знают что оно там есть и что его придется обрабатывать хочешь или нет :))

Ну просто странная история получается, например мы отправляем какой то вызов в библиотеку которая кидает например io, то есть получается мне нужно лезть в сорсы чтобы понять это? Я понимаю что мехонизм сам по себе сложный, я про то когда там через 5 классов исключение сквозное и тд, но тем не менее все знают что оно там есть и что его придется обрабатывать хочешь или нет :))

Ну хотя бы есть аннотация @Throws есть. В некоторых языках и этого нет (как и документации к коду) при этом в наличии безумное метапрограммирование и кучи вариантов вызова функций.

Ну просто странная история получается, например мы отправляем какой то вызов в библиотеку которая кидает например io, то есть получается мне нужно лезть в сорсы чтобы понять это? Я понимаю что мехонизм сам по себе сложный, я про то когда там через 5 классов исключение сквозное и тд, но тем не менее все знают что оно там есть и что его придется обрабатывать хочешь или нет :))

Аннотируйте свой код @Throws - делайте мир лучше! )

Ну хотя бы есть аннотация @Throws есть. В некоторых языках и этого нет (как и документации к коду) при этом в наличии безумное метапрограммирование и кучи вариантов вызова функций.

Интересная аннотация которая мне кажется ничего не даёт :) я сейчас пишу библиотеку, там внутри сишный код который завершается с кодом ошибки, ну я и с jni швыряю его наверх к тому кто звал, соответственно упаковывая aar аннотации удаляются :) ну как пользователь должен узнать о том что ему будет исключения сыпать на каждый шаг в сторону?) Согласен можно было сделать объект и его швырять.. но просто сам факт того что у меня ни rx нет ничего, чисто базовый io, как я должен пользователя уведомить что он пишет в закрытую память ?) Странно короче , пойду почитаю эффективную Яву , ходят слухи блох писал про это..

Интересная аннотация которая мне кажется ничего не даёт :) я сейчас пишу библиотеку, там внутри сишный код который завершается с кодом ошибки, ну я и с jni швыряю его наверх к тому кто звал, соответственно упаковывая aar аннотации удаляются :) ну как пользователь должен узнать о том что ему будет исключения сыпать на каждый шаг в сторону?) Согласен можно было сделать объект и его швырять.. но просто сам факт того что у меня ни rx нет ничего, чисто базовый io, как я должен пользователя уведомить что он пишет в закрытую память ?) Странно короче , пойду почитаю эффективную Яву , ходят слухи блох писал про это..

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

когда нул, когда и какое исключения

Ну просто странная история получается, например мы отправляем какой то вызов в библиотеку которая кидает например io, то есть получается мне нужно лезть в сорсы чтобы понять это? Я понимаю что мехонизм сам по себе сложный, я про то когда там через 5 классов исключение сквозное и тд, но тем не менее все знают что оно там есть и что его придется обрабатывать хочешь или нет :))

Метод не должен диктовать, как вызывающая сторона будет обрабатывать ошибки; объявление throws раскрывает детали имплементации; обработка проверяемых исключений, которые никогда не произойдут, замусоривает код. Проблем с проверяемыми исключениями больше, чем пользы, типы исключений должны быть в документации, а не в сигнатуре. В Джаве они были ошибкой, не зря современные языки от них отказались. Пункт 7 в статье https://medium.com/@lukleDev/how-effective-java-may-have-influenced-the-design-of-kotlin-part-2-89844d62ddf3 и соответствующая глава в Effective Java.

Метод не должен диктовать, как вызывающая сторона будет обрабатывать ошибки; объявление throws раскрывает детали имплементации; обработка проверяемых исключений, которые никогда не произойдут, замусоривает код. Проблем с проверяемыми исключениями больше, чем пользы, типы исключений должны быть в документации, а не в сигнатуре. В Джаве они были ошибкой, не зря современные языки от них отказались. Пункт 7 в статье https://medium.com/@lukleDev/how-effective-java-may-have-influenced-the-design-of-kotlin-part-2-89844d62ddf3 и соответствующая глава в Effective Java.

+

Ну просто странная история получается, например мы отправляем какой то вызов в библиотеку которая кидает например io, то есть получается мне нужно лезть в сорсы чтобы понять это? Я понимаю что мехонизм сам по себе сложный, я про то когда там через 5 классов исключение сквозное и тд, но тем не менее все знают что оно там есть и что его придется обрабатывать хочешь или нет :))

Ты можешь завернуть ее в suspend функцию (если она IO, то наверняка асинхронная) и тогда ее вообще нельзя будет вызвать из обычного кода.

Ты можешь завернуть ее в suspend функцию (если она IO, то наверняка асинхронная) и тогда ее вообще нельзя будет вызвать из обычного кода.

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

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

Иван тебе уже расписал, сами джависты признают что это не самая лучшая фича

некоторые юзкейсы того не стоят

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

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

Иван тебе уже расписал, сами джависты признают что это не самая лучшая фича

Я не говорю что она лучшая :) я просто хочу понять :) сорян видимо я туповат :)

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

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

Я не говорю что она лучшая :) я просто хочу понять :) сорян видимо я туповат :)

Почитаей, как оно сделано в Swift, там что-то на подобии CH, только современное.

некоторые юзкейсы того не стоят

Я согласен как и в большинстве случаев связанных с какими то граничащими условиями это хорошо не везде и далеко не всегда я говорю о тех там 5% где это действительно смотрится хорошо а не о методах которые при делении на ноль кидают исключения :)

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

так в чем проблема непроверяемый исключений?

как можно правильно замапить data class с Any data class ExampleDataClass(val number: Int) если я сделаю так val example = msg.data to obj.dataClass dataClass это ExampleDataClass::class.java то получу на выхлопе ({z=2.0} а ожидаю Int

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

{ hello -> "world" } (catch Whatever) {"sup" } finally { "sup" }

Почитаей, как оно сделано в Swift, там что-то на подобии CH, только современное.

А можете в 2х словах?) Я может не правильно выразился, мне просто кажется что существуют все таки кейсы в которых это необходимо ..

как можно правильно замапить data class с Any data class ExampleDataClass(val number: Int) если я сделаю так val example = msg.data to obj.dataClass dataClass это ExampleDataClass::class.java то получу на выхлопе ({z=2.0} а ожидаю Int

obj::class

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

{ hello -> "world" } (catch Whatever) {"sup" } finally { "sup" }

ужасно, особено для { it * 2 }

Метод не должен диктовать, как вызывающая сторона будет обрабатывать ошибки; объявление throws раскрывает детали имплементации; обработка проверяемых исключений, которые никогда не произойдут, замусоривает код. Проблем с проверяемыми исключениями больше, чем пользы, типы исключений должны быть в документации, а не в сигнатуре. В Джаве они были ошибкой, не зря современные языки от них отказались. Пункт 7 в статье https://medium.com/@lukleDev/how-effective-java-may-have-influenced-the-design-of-kotlin-part-2-89844d62ddf3 и соответствующая глава в Effective Java.

Автор вопроса как раз интересуется деталями реализации - чтобы не кукарекать на проде

тиапм таких лямб

ужасно, особено для { it * 2 }

ну дык и функция чистая

Автор вопроса как раз интересуется деталями реализации - чтобы не кукарекать на проде

дока

ну дык и функция чистая

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

Ну тут уже религия пошла. Кто то скажет по умному - раскрытие деталей реализации, а кто-то скажет - это часть контракта

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

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

Но есть же задачи в которых они смотрятся вполне вменяемо ?

Ну тут уже религия пошла. Кто то скажет по умному - раскрытие деталей реализации, а кто-то скажет - это часть контракта

это можно выразит по другому, например возращать Врапер(значение, ексепшин), или Empty объект

Но есть же задачи в которых они смотрятся вполне вменяемо ?

примеры

(не спорю есть, но сколько их)

это можно выразит по другому, например возращать Врапер(значение, ексепшин), или Empty объект

и do-notation посахарить!

примеры

Создать файл и записать его :)

obj::class

тоже самое, kotlin-reflect поставил

Создать файл и записать его :)

ну и, я могу сказать успешно, не успешно, выдавать статус и т.д.

это можно выразит по другому, например возращать Врапер(значение, ексепшин), или Empty объект

SuccessOrFailure ?

SuccessOrFailure ?

я к примеру, чекед ничем не лучше, вот JS на самом деле если убрать динамическую типизацию станет топовым, а нет что-то TypeScript не зашел, ибо программисты говнокодят, а яп плохой

А каким образом контракт на метод нарушает инкапсуляцию?

А каким образом контракт на метод нарушает инкапсуляцию?

контракт что-то поясняет, а не говорит что тебе и как нужно проверить

а вообще оффтоп пошел

Создать файл и записать его :)

зависит от кейса. Если пилишь библиотеку, то действительно больно, хочется обезопасит и сделать касиво

зависит от кейса. Если пилишь библиотеку, то действительно больно, хочется обезопасит и сделать касиво

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

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

котлин это ошибки компиляции, а не в рантайме

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

возникла идея, не знаю поможет ли в данном примере, еще смотря что метод возращает, но базируется он на Empty. Возращаем некий буфер для чтения файла, и он буде пустой если не прочитан, и будет что-то типа статуса (пока непонятно как это красивей сделать, saled class), если тебя беспокоет что файл не прочитался ты проверишь, если нет то ты пропустишь проверку и не свалишся в рантайме, в этом и идея. Вот как ее правильней развить, остается открытым вопросом

возникла идея, не знаю поможет ли в данном примере, еще смотря что метод возращает, но базируется он на Empty. Возращаем некий буфер для чтения файла, и он буде пустой если не прочитан, и будет что-то типа статуса (пока непонятно как это красивей сделать, saled class), если тебя беспокоет что файл не прочитался ты проверишь, если нет то ты пропустишь проверку и не свалишся в рантайме, в этом и идея. Вот как ее правильней развить, остается открытым вопросом

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

Короче я понял исключение проделки дьявола :))

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

получать исклюения от си-ой либы ? в джаве ? >работа с библиотекой далее не имеет смысла в этом суть Empty, объект есть, а результата не будет, или кинуть Nothing, то сделает код недостижимым, и прервет выолнения

ERROR: S client not available

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

Вообще говоря в свете отсутствия checked exceptions Kotlin-разработчики должны быть чуть лучше Java-разработчиков подготовлены к внезапным исключениям. Так что @throws в документации к методу и ещё одной оговорки в текстовой документации на всякий случай должно быть достаточно. Ну либо, как правильно подсказывает Богдан, вместо бросания исключений обработать прерывание в сишном коде и учесть его в результате метода — для JNI sealed класс ничем не отличается от обычного, просто вернуть инстанс либо объекта с результатом, либо объекта с ошибкой.

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

зачастую с либы как раз возращаю статус код, покрайне мере древние, и они не связаны с с++

Ну если я правильно понял и исключение кидается каким-нибудь env->ThrowException(...).

зачастую с либы как раз возращаю статус код, покрайне мере древние, и они не связаны с с++

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

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

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

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

Да все верно, у меня so кидает статусы, два варианта либо где то в jni их мапить (рефлексией создавать классы) и откидывать клиенту или кидать исключение , с одной стороны исключения чем хороши, в моем случаи есть последовательность методов, например первичная инициализация состоит из 5 методов, которые следуют строго определенным образом (я знаю я даун можно объединить в 1 или делать объекты которые требуются функциям нижнего уровня в верхнем) тем не менее мне кажется лучше написать 1 try блок чем 5 проверок тип isSuccess() , с другой стороны клиенты котлин понятия не имеют (ТК врятли они будут да и читать документацию никому не нравиться) что эти методы могут порождать ошибки, тут такая интересная картинка появляется , если делать исключения, то это плохо, делать объекты тоже тк задержки + накладные расходы + гулячие данные + невнятный внешний интерфейс вот и я не знаю тип как лучше по этому и спросил чем мотивируется отказ от исключений, в принципе идеи ясны..

Да все верно, у меня so кидает статусы, два варианта либо где то в jni их мапить (рефлексией создавать классы) и откидывать клиенту или кидать исключение , с одной стороны исключения чем хороши, в моем случаи есть последовательность методов, например первичная инициализация состоит из 5 методов, которые следуют строго определенным образом (я знаю я даун можно объединить в 1 или делать объекты которые требуются функциям нижнего уровня в верхнем) тем не менее мне кажется лучше написать 1 try блок чем 5 проверок тип isSuccess() , с другой стороны клиенты котлин понятия не имеют (ТК врятли они будут да и читать документацию никому не нравиться) что эти методы могут порождать ошибки, тут такая интересная картинка появляется , если делать исключения, то это плохо, делать объекты тоже тк задержки + накладные расходы + гулячие данные + невнятный внешний интерфейс вот и я не знаю тип как лучше по этому и спросил чем мотивируется отказ от исключений, в принципе идеи ясны..

Ну конкретно правильность порядка вызова пяти функций -- это плохая задача для checked exceptions, ибо такое дев обработает приблизительно никак в 99% случаев :) Может, эти нативные методы стоит спрятать за котлин-методами, которые поймают исключение и вернут в свою очередь sealed class? Нативную часть тогда менять не придётся, а потребитель получит удобный программный интерфейс.

Ну конкретно правильность порядка вызова пяти функций -- это плохая задача для checked exceptions, ибо такое дев обработает приблизительно никак в 99% случаев :) Может, эти нативные методы стоит спрятать за котлин-методами, которые поймают исключение и вернут в свою очередь sealed class? Нативную часть тогда менять не придётся, а потребитель получит удобный программный интерфейс.

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

Да все верно, у меня so кидает статусы, два варианта либо где то в jni их мапить (рефлексией создавать классы) и откидывать клиенту или кидать исключение , с одной стороны исключения чем хороши, в моем случаи есть последовательность методов, например первичная инициализация состоит из 5 методов, которые следуют строго определенным образом (я знаю я даун можно объединить в 1 или делать объекты которые требуются функциям нижнего уровня в верхнем) тем не менее мне кажется лучше написать 1 try блок чем 5 проверок тип isSuccess() , с другой стороны клиенты котлин понятия не имеют (ТК врятли они будут да и читать документацию никому не нравиться) что эти методы могут порождать ошибки, тут такая интересная картинка появляется , если делать исключения, то это плохо, делать объекты тоже тк задержки + накладные расходы + гулячие данные + невнятный внешний интерфейс вот и я не знаю тип как лучше по этому и спросил чем мотивируется отказ от исключений, в принципе идеи ясны..

исключения тоже не бесплатны

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

А, я думал, речь именно об ошибках в случае неправильного порядка вызова методов.

А, я думал, речь именно об ошибках в случае неправильного порядка вызова методов.

Извини, я наверное плохо свои мысли вырожаю,там есть initResurces (тут может упасть куча всего не примонтировалась файловая система например или пользовательский ввод) потом идёт handshake ( рукопожатие не имеет смысла без корневой дериктории ТК сохранять результат не получиться ну и ошибка неверных данных например перепутали алгоритм или тип того) остальные в принципе друг от друга не зависят но должны пройти после handshake'a все исключения у меня это 1 класс который имеет код ну и красивое сообщение с разбором деталей. Вот я и думал все в 1 try обьеденить...

Извини, я наверное плохо свои мысли вырожаю,там есть initResurces (тут может упасть куча всего не примонтировалась файловая система например или пользовательский ввод) потом идёт handshake ( рукопожатие не имеет смысла без корневой дериктории ТК сохранять результат не получиться ну и ошибка неверных данных например перепутали алгоритм или тип того) остальные в принципе друг от друга не зависят но должны пройти после handshake'a все исключения у меня это 1 класс который имеет код ну и красивое сообщение с разбором деталей. Вот я и думал все в 1 try обьеденить...

Да, это я неправильно изначально понял. Ну один try никуда не девается, просто потребитель апишки теперь не обязан его писать.

Если для него исключение упадёт внезапно -- значит он ССЗБ и не прочитал документацию :)

Да, это я неправильно изначально понял. Ну один try никуда не девается, просто потребитель апишки теперь не обязан его писать.

Хххх звучит справедливо, просто мне котлин в новинку (4 месяца где то что-то пробую) заметил что на каждое сложное решение есть какая та магия, подумал малоли тут что то тоже есть :)) спасибо огромное за помощь !!

Хххх звучит справедливо, просто мне котлин в новинку (4 месяца где то что-то пробую) заметил что на каждое сложное решение есть какая та магия, подумал малоли тут что то тоже есть :)) спасибо огромное за помощь !!

Магии нету. Она могла бы быть в умном тулинге, который бы читал джавадоки / смотрел бы на @Throws и следил бы за исключениями, которые проваливались бы вникуда, но, видимо, это либо непростая задача, либо просто невостребовано, раз до сих пор не реализовали :) Да не за что, не помогли же ничем)

Обсуждали возможность сделать проверку @Throws линтером. Ничего невозможного, просто у людей руки не долшли. Я думаю, что рань или поздон оно будет.

я обновил json-бенчмарки https://github.com/wizzardo/json-benchmarks

добавил на графики аллокацию памяти, но klaxon все портит и ее не везде видно

добавил на графики аллокацию памяти, но klaxon все портит и ее не везде видно

Мда, клаксон зверюга какая-то, спасибо большое ?

Зверюга?

Может я его готовлю неправильно?

Я фиг знает, может ну его с графиков, написать в ридми чтт боец выбыл

Может я его готовлю неправильно?

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

добавил на графики аллокацию памяти, но klaxon все портит и ее не везде видно

такое ощущение что klaxon это ужасная дичь

худшая производительность везде, больше всех треша и так далее

А звёзд то сколько у него

862 ?

Не всем производительность нужна, кому-то генерация объектиков. Кстати, я не увидел вот такой момент: мне к примеру нужно быстро парсить дерево, но при этом не нужно считывать все значения, а только маленькое количество отдельных элементов. Я чего-то не вижу такого случая.

Я просто специально для этого переполз с glassfish на json-simple и скорость увеличилась в несколько раз. А у вас оно наоборот.

Я просто специально для этого переполз с glassfish на json-simple и скорость увеличилась в несколько раз. А у вас оно наоборот.

Какого размера джейсоны, чтобы Так заморачиваться?

Маленького, но их много, надо прочитать быстро несколько сот и из каждого нужно одно-два поля