Помимо "локальности" данных, новые inline/primitive типы позволяют аллоцировать данные "на регистрах процессорах", не делая дополнительных обращений к опереативной памяти и экономить такты процессора. В целом и сейчас такие кейсы могут упрощаться на этапе escape анализа. За то "скидывать" новые типы данные в ОП или нет, отвечает JVM
Но, справедливости ради, Kotlin-корутины не обязывают использовать только их для эффективного IO.
Это понятно. Но проблема как была так и остается - с использованием блокирующего кода внутри корутин - неважно IO или что то другое. И хорошо если IDE умеет распознавать такие случаи и подсказывать. А так это потенциально опасное место чтобы выстрелить себе в ногу. Именно этот минус я и имел ввиду.
По второму пункту вы сами ответили на свой вопрос - какой смысл использовать корутины, если есть возможность использовать JDK21 и выше.
Я бы к минусам корутин еще отнес - чтобы их эффективно использовать все IO вызовы внутри также должны уметь поддерживать корутины(быть не блокирующими), иначе при попытке вызова обычного блокирующего java метода внутри suspend функции это ни к чему хорошему не приведет. И об этом надо помнить постоянно(в отличии от Loom), а попытки решить эту проблему "разукрашивают" код еще сильнее. Похожий тред есть на stackoverflow.
которые, на минуточку в 20-м веке проиграли мировую войну и подверглись атомным бомбардировкам
Такое мог ляпнуть только необразованный человек, который либо не учился в школе или учился плохо. Получается что вторая мировая война сказалась на демографии Япония хуже чем на СССР? Потери Японии 2.5 млн, против 26.5 у СССР если что. Все это легко проверяется в интернете. Более того у Японии нет почти никакого провала по демографии в этот период в отличии от СССР. На начало войны 1941г - 72.7млн на 1945 72.4млн по данным с вики.
которых в начале 20-го века было в ТРИ раза меньше чем русских
к началу 21-го века стало БОЛЬШЕ чем русских
Если говорить про "совок", то надо сравнивать данные первой переписи 1926 г и последней в СССР 1991, а не начало и конец века. Так если что, в первую мировую войну потери России были одними из самых больших (тоже наверное "совок" виноват). И с этим "наследием" уже пришлось жить дальше СССР. Если говорить только проРоссию/РСФСР то на 1926г было 100млн человек, на 1991г - 148млн. И отрицательное сальдо 41г-45г -23млн, вместо 0.3млн у Японии. Итого на 1926г Русских было в 1.6 раз больше, на 91г в 1.2 раза больше. Где тут три раза? я специально брал данные только по РСФСР, а не по СССР в целом. А если убрать провал по демографии России вызванный второй мировой, то получается что разница +- осталась такой же. И по данным из вики что я приводил, видно что например в тех же 80ых, рост численности был выше чем в Японии.
О как! оказывается все дело в законе. Удобная позиция, найти какой-то факт и полагать что дело только в нем и озвучивать факт только на половину. Что его отменили только в лихие 90-ые. А то что его ввели в ноябре 1941 года, то да, эта дата ни о чем не говорит. А население росло потому что оно было уверено в завтрашнем дне. А заводы и вся инфраструктура которая была построена в СССР этому способствовала. И росло население с середины 20-ых годов(можете посмотреть в википедии), не смотря на первые самые тяжелые пятилетки и репресии второй половины 30х.
Здравствуйте. На сколько мне известно, по моим источникам, внутренний разбор по моей ситуации уже был. Что там у вас было решено по итогу если честно мне не очень интересно ни тогда (т.к. на тот момент я уже определился с новым местом работы), ни тем более сейчас, полтора года спустя. Но статьи с похожим содержанием нет нет, да периодически появляются, это о чем то, да говорит. Вообщем если вам интересно, мои ФИО есть в профиле, по ним со 100% вероятностью вы сможете найти данные обо мне внутри компании. И как я уже говорил в Тинькофф трудоустраиваться больше не собираюсь, поэтому полтора года спустя мне не очень интересна вся эта история. Но вы можете попытаться это исправить, для будующих потенциальных сотрудников.
Совершенно верно. Как я понял это мало кого интересовало - мой прошлый опыт в этой компании. Сначало надо было пройти сито обязательных секций, может быть далее при общении на конкретный проект, мой опыт бы и учли, но я до этого не дошел, т.к. после двух первых секций получил оценку мидл, и никакого далее разговора о пизиции senior речи быть не могло)
Кстати если в других компаниях что я указал, в процессе собеса, чувсвуешь что имешь разговор с квалифицированным инженерорм, то тут явно было ощущение что тебя гонят по опроснику и сверяют с эталоном. и есть только одно правльное решение и никак иначе.
upd: как сказали мои знакомые что там работают - мне просто не повезло с интервьюерами
В ali была классическая задача на поиск в ширину - найти кратчайший путь. В huawei проектировали структуру данных, для нахождения строк, по начальной подстроке. на знание trie - деревьев.
Напишу про свой опыт работы в Тинькофф). Я бекэнд java девелопер с 2011 года, проработал 6 лет в Тинькофф с 2015-2020г на позиции senior developer. Далее было немного Яндекса и JetBrains. В 2022г когда пришлось искать новую работу, по известным событиям, я собесился в компании Huawei/Aliexpress/РтЛабс/Тинькофф. Везде были сложные задания - включая алгоритмы на графах. И почти все собеседования, я прошел и более того мне дали именно те условия что я просил, кроме… правильно) Тинькова. Там я вообще не прошел собес, меня оценили на мидла по всем секциям и ответили отказом. Меня если честно это вообще не задело, т.к. собесился туда больше на всякий случай, да и в целом уже заранее знал куда пойду работать дальше.
А теперь немного подробностей, чтобы показать всю нелепость ситуации. На секции с техническим дизайном, проектировали систему по загрузке изображений. Я там немного похоливарил с интервьюером на тему, что лучше для той задачи - kafka или rabbit. Справедливости ради замечу, что задачу можно было решить на любом брокере. Как итог в обратной связи мне написали, что я не разбираюсь ни в том ни в другом. Для справки скажу, что еще в свой первый заход в тинькофф, я реализовывал отложенную отправку сообщений на rabbit и считаю что знаю его не плохо и в свое время прочитал если не всю, то большинство документации по нему на оф.сайте. Далее когда в компании появился кластер kafka, мы мигрировали часть функционала туда, и все новые фичи, где нужна была асинхронная отправка сообщений, реализовывали через kafka. Так что, я мягко говоря имел практический опыт сравнения двух брокеров и участвовал в разборе определенных “граблей” kafka вместе с командой, что отвечает за ее поддержку в компании. И имел хорошую репутацию внутри той компанды, в которй там работал с период 2015-2022г.
Благо у меня остались знакомые там, и рассказав им ситуацию, выяснилось следующее, что человек который меня собеседовал, был вообще аналитик… и в жизни не писал код в промышленном масштабе. что люди туда приходят просто с бумажкой, где сверяют твои ответы с тем что должно быть. И в ответах у него была только - kafka. По другой секции, где меня тоже оценили на мидла, интервьюер был в процессе увольнения, и ему просто было по сути все равно, что ставить в результате, скорее всего он так развлекался.
По итогу для себя я однозначно сделал вывод, что если есть такая компания в которой я больше ни при каких обстоятельствах работать не буду, как бы не сложилась жизнь - это однозначно Тинькофф.
Ковырял исходники idea) мне это также надо было для написания своего плагина из первой статьи. По этой причине я в конце каждой своей публикации про idea-плагины оставляю ссылку ну репоизиторий idea-community. Собственно тут я и решил задокументировать свой опыт, если кому то еще понадобится.
Как я уже говорил в статье, что пока проект в стадии MVP и много кода я заимствовал из основного репозитория idea-community. Поэтому все что можно было переиспользовать я оставлял как есть. Но новый код я пишу на Котлин (лично для себя я не вижу тут большой проблемы, да и в JB никто не заставлял писать на чем то конкретно). Но учитывая что при каждом релизе IDEA, даже мне приходиться местами переписывать код, т.к. ломается обратная совместимость (поэтому у меня уже в репо появились ветки 222/223/231/232), а ваш форк имеет еще более раннюю кодовую бд, то даже код на Java не получилось бы скорее всего легко адаптировать под него и пришлось бы многое переписывать. В основном переписывать надо будет конвертеры в External API - MavenProjectResolver и в взаимодействие с Maven GServerHelper. Можем обсудить детали в лс, если будет время я готов помочь.
Начиная с версии 3.3.1 минимальная версия JDK 7+. И я посчитал что почти 10 лет это срок) поэтому также своему Maven плагину поставил минимальную версию 7. Также начиная с 3.3.1 есть ряд фич на которые есть завязки в коде - например .mvn/jvm.config. Но в целом это не мешает запускать проекты и на более ранних версия Maven, если они работают на JDK 7+. Интереса ради проверил на версии - 3.2.1 все ок. Но вот на 3.1.1 уже вылезли проблемы несовместимости API MavenSession. https://maven.apache.org/docs/history.html
Пока никак, т.е. специально для этого я ничего не делал. Но как показывает практика - все не так уж и плохо) Если сгенерировать Maven/Kotlin проект через стандартный wizard и далее открыть моим плагином, то он с большой долей вероятности заработает на дефолтных IDEA Kotlin Compiler настройках. А Maven вернет корректную проектную модель с Kotlin content root’ами, благодаря параметрам - <sourceDirectory>/<testSourceDirectory> из билд файла - и все будет работать в IDE. Если создать Spring/Kotlin/Maven проект через spring initializr, то там будет еще проблема при билде проекта из IDEA, т.к. она ничего не знает про kotlin-maven-allopen. Но если сбилдить проект мавеном - package, то он сгенерит в target уже корректные “открытые” классы и все далее будет прекрасно работать в IDE. Надо будет кончено допилить эти моменты, займусь в ближайшее время)
Я еще подумал над вашим кейсом - использование дополнительных maven-task при импорте. И нашел одну неприятную особенность, сейчас так задумано что ‘maven agrs’ передаются по все внутренние процессы плагина, будь то импорт проектной модели или запуск таска. И при запуске тасков это выглядит избыточно, особенно при clean. Основной вариант использования(по моему мнению) mvn agrs - это переопределение стандартных настроек Maven во всех процессах плагина (кастомные сеттинги -s /home/settings.xml, локальный репо -Dmaven.repo.local=/home/my_repository и прочее). Поэтому я решил сделать отдельную настройку ‘Import args’ для указания дополнительных аргументов, который будут использоваться только при импорте. Будет вот так (в ближайшее время выложу новую версию в основной Marketplace, уже не alpha):
Additional args - будут добавляться во все maven процессы, включая импорт. Основное назначение переопределять во всех процессах базовые Maven параметры. Для частных случаев можно создать Run Configuration.
Потому что плагины для IDE не пишутся с чистого листа. Для IDEA плагинов есть свой шаблон, встроенный в стандартный wizard. Который использует Gradle и обеспечивает базовый флоу написания плагинов - их запуск, отладку, публикацию в marketplace и прочее. И заниматься изысканиями на тему, а можно ли это переделать на Maven, я не видел смысла, т.к. решал совсем другую проблему. Тем более официальная документация не дает альтернатив. А поиск решений для Maven, находит только не активные проекты вроде - https://plugins.jetbrains.com/plugin/7127-intellij-plugin-development-with-maven/versions и https://maven.apache.org/plugins/maven-idea-plugin/
Спасибо за обратную связь! Интересный use case. Еще одно доказательство того, что нет ничего лучше чем полноценный maven lifecycle для импорта проекта) Если найдете какие то проблемы, то смело пишите в лс. А как раньше вы работали со своим проектом - Eclipse?
GMaven Plus это плагин для Maven. Мой GMaven это плагин для IDEA. И с аналогичным именем в IDEA Marketplace других плагинов нет. К тому же я не уверен что имя плагина должно быть уникальным, в отличии от plugin id.
Помимо "локальности" данных, новые inline/primitive типы позволяют аллоцировать данные "на регистрах процессорах", не делая дополнительных обращений к опереативной памяти и экономить такты процессора. В целом и сейчас такие кейсы могут упрощаться на этапе escape анализа. За то "скидывать" новые типы данные в ОП или нет, отвечает JVM
Это понятно. Но проблема как была так и остается - с использованием блокирующего кода внутри корутин - неважно IO или что то другое. И хорошо если IDE умеет распознавать такие случаи и подсказывать. А так это потенциально опасное место чтобы выстрелить себе в ногу. Именно этот минус я и имел ввиду.
По второму пункту вы сами ответили на свой вопрос - какой смысл использовать корутины, если есть возможность использовать JDK21 и выше.
Я бы к минусам корутин еще отнес - чтобы их эффективно использовать все IO вызовы внутри также должны уметь поддерживать корутины(быть не блокирующими), иначе при попытке вызова обычного блокирующего java метода внутри suspend функции это ни к чему хорошему не приведет. И об этом надо помнить постоянно(в отличии от Loom), а попытки решить эту проблему "разукрашивают" код еще сильнее. Похожий тред есть на stackoverflow.
Такое мог ляпнуть только необразованный человек, который либо не учился в школе или учился плохо. Получается что вторая мировая война сказалась на демографии Япония хуже чем на СССР? Потери Японии 2.5 млн, против 26.5 у СССР если что. Все это легко проверяется в интернете. Более того у Японии нет почти никакого провала по демографии в этот период в отличии от СССР. На начало войны 1941г - 72.7млн на 1945 72.4млн по данным с вики.
Если говорить про "совок", то надо сравнивать данные первой переписи 1926 г и последней в СССР 1991, а не начало и конец века. Так если что, в первую мировую войну потери России были одними из самых больших (тоже наверное "совок" виноват). И с этим "наследием" уже пришлось жить дальше СССР. Если говорить только про Россию/РСФСР то на 1926г было 100млн человек, на 1991г - 148млн. И отрицательное сальдо 41г-45г -23млн, вместо 0.3млн у Японии. Итого на 1926г Русских было в 1.6 раз больше, на 91г в 1.2 раза больше. Где тут три раза? я специально брал данные только по РСФСР, а не по СССР в целом. А если убрать провал по демографии России вызванный второй мировой, то получается что разница +- осталась такой же. И по данным из вики что я приводил, видно что например в тех же 80ых, рост численности был выше чем в Японии.
О как! оказывается все дело в законе. Удобная позиция, найти какой-то факт и полагать что дело только в нем и озвучивать факт только на половину. Что его отменили только в лихие 90-ые. А то что его ввели в ноябре 1941 года, то да, эта дата ни о чем не говорит.
А население росло потому что оно было уверено в завтрашнем дне. А заводы и вся инфраструктура которая была построена в СССР этому способствовала. И росло население с середины 20-ых годов(можете посмотреть в википедии), не смотря на первые самые тяжелые пятилетки и репресии второй половины 30х.
Здравствуйте. На сколько мне известно, по моим источникам, внутренний разбор по моей ситуации уже был. Что там у вас было решено по итогу если честно мне не очень интересно ни тогда (т.к. на тот момент я уже определился с новым местом работы), ни тем более сейчас, полтора года спустя. Но статьи с похожим содержанием нет нет, да периодически появляются, это о чем то, да говорит. Вообщем если вам интересно, мои ФИО есть в профиле, по ним со 100% вероятностью вы сможете найти данные обо мне внутри компании. И как я уже говорил в Тинькофф трудоустраиваться больше не собираюсь, поэтому полтора года спустя мне не очень интересна вся эта история. Но вы можете попытаться это исправить, для будующих потенциальных сотрудников.
Совершенно верно. Как я понял это мало кого интересовало - мой прошлый опыт в этой компании. Сначало надо было пройти сито обязательных секций, может быть далее при общении на конкретный проект, мой опыт бы и учли, но я до этого не дошел, т.к. после двух первых секций получил оценку мидл, и никакого далее разговора о пизиции senior речи быть не могло)
Кстати если в других компаниях что я указал, в процессе собеса, чувсвуешь что имешь разговор с квалифицированным инженерорм, то тут явно было ощущение что тебя гонят по опроснику и сверяют с эталоном. и есть только одно правльное решение и никак иначе.
upd: как сказали мои знакомые что там работают - мне просто не повезло с интервьюерами
В ali была классическая задача на поиск в ширину - найти кратчайший путь. В huawei проектировали структуру данных, для нахождения строк, по начальной подстроке. на знание trie - деревьев.
Напишу про свой опыт работы в Тинькофф). Я бекэнд java девелопер с 2011 года, проработал 6 лет в Тинькофф с 2015-2020г на позиции senior developer. Далее было немного Яндекса и JetBrains. В 2022г когда пришлось искать новую работу, по известным событиям, я собесился в компании Huawei/Aliexpress/РтЛабс/Тинькофф. Везде были сложные задания - включая алгоритмы на графах. И почти все собеседования, я прошел и более того мне дали именно те условия что я просил, кроме… правильно) Тинькова. Там я вообще не прошел собес, меня оценили на мидла по всем секциям и ответили отказом. Меня если честно это вообще не задело, т.к. собесился туда больше на всякий случай, да и в целом уже заранее знал куда пойду работать дальше.
А теперь немного подробностей, чтобы показать всю нелепость ситуации. На секции с техническим дизайном, проектировали систему по загрузке изображений. Я там немного похоливарил с интервьюером на тему, что лучше для той задачи - kafka или rabbit. Справедливости ради замечу, что задачу можно было решить на любом брокере. Как итог в обратной связи мне написали, что я не разбираюсь ни в том ни в другом. Для справки скажу, что еще в свой первый заход в тинькофф, я реализовывал отложенную отправку сообщений на rabbit и считаю что знаю его не плохо и в свое время прочитал если не всю, то большинство документации по нему на оф.сайте. Далее когда в компании появился кластер kafka, мы мигрировали часть функционала туда, и все новые фичи, где нужна была асинхронная отправка сообщений, реализовывали через kafka. Так что, я мягко говоря имел практический опыт сравнения двух брокеров и участвовал в разборе определенных “граблей” kafka вместе с командой, что отвечает за ее поддержку в компании. И имел хорошую репутацию внутри той компанды, в которй там работал с период 2015-2022г.
Благо у меня остались знакомые там, и рассказав им ситуацию, выяснилось следующее, что человек который меня собеседовал, был вообще аналитик… и в жизни не писал код в промышленном масштабе. что люди туда приходят просто с бумажкой, где сверяют твои ответы с тем что должно быть. И в ответах у него была только - kafka. По другой секции, где меня тоже оценили на мидла, интервьюер был в процессе увольнения, и ему просто было по сути все равно, что ставить в результате, скорее всего он так развлекался.
По итогу для себя я однозначно сделал вывод, что если есть такая компания в которой я больше ни при каких обстоятельствах работать не буду, как бы не сложилась жизнь - это однозначно Тинькофф.
продублирую ссылкой. т.к. "промазал" с ответом, а редактировать уже поздно. https://habr.com/ru/articles/759984/comments/#comment_25953974
Ковырял исходники idea) мне это также надо было для написания своего плагина из первой статьи. По этой причине я в конце каждой своей публикации про idea-плагины оставляю ссылку ну репоизиторий idea-community. Собственно тут я и решил задокументировать свой опыт, если кому то еще понадобится.
Если интересно то начиная с версии 232.7 добавлена поддержка Kotlin JVM
Как я уже говорил в статье, что пока проект в стадии MVP и много кода я заимствовал из основного репозитория idea-community. Поэтому все что можно было переиспользовать я оставлял как есть. Но новый код я пишу на Котлин (лично для себя я не вижу тут большой проблемы, да и в JB никто не заставлял писать на чем то конкретно). Но учитывая что при каждом релизе IDEA, даже мне приходиться местами переписывать код, т.к. ломается обратная совместимость (поэтому у меня уже в репо появились ветки 222/223/231/232), а ваш форк имеет еще более раннюю кодовую бд, то даже код на Java не получилось бы скорее всего легко адаптировать под него и пришлось бы многое переписывать. В основном переписывать надо будет конвертеры в External API - MavenProjectResolver и в взаимодействие с Maven GServerHelper. Можем обсудить детали в лс, если будет время я готов помочь.
Начиная с версии 3.3.1 минимальная версия JDK 7+. И я посчитал что почти 10 лет это срок) поэтому также своему Maven плагину поставил минимальную версию 7. Также начиная с 3.3.1 есть ряд фич на которые есть завязки в коде - например .mvn/jvm.config. Но в целом это не мешает запускать проекты и на более ранних версия Maven, если они работают на JDK 7+. Интереса ради проверил на версии - 3.2.1 все ок. Но вот на 3.1.1 уже вылезли проблемы несовместимости API MavenSession.
https://maven.apache.org/docs/history.html
Я не против, open source же) главное чтобы продукт развивался и становился лучше)
Пока никак, т.е. специально для этого я ничего не делал. Но как показывает практика - все не так уж и плохо) Если сгенерировать Maven/Kotlin проект через стандартный wizard и далее открыть моим плагином, то он с большой долей вероятности заработает на дефолтных IDEA Kotlin Compiler настройках. А Maven вернет корректную проектную модель с Kotlin content root’ами, благодаря параметрам - <sourceDirectory>/<testSourceDirectory> из билд файла - и все будет работать в IDE. Если создать Spring/Kotlin/Maven проект через spring initializr, то там будет еще проблема при билде проекта из IDEA, т.к. она ничего не знает про kotlin-maven-allopen. Но если сбилдить проект мавеном - package, то он сгенерит в target уже корректные “открытые” классы и все далее будет прекрасно работать в IDE. Надо будет кончено допилить эти моменты, займусь в ближайшее время)
Я еще подумал над вашим кейсом - использование дополнительных maven-task при импорте. И нашел одну неприятную особенность, сейчас так задумано что ‘maven agrs’ передаются по все внутренние процессы плагина, будь то импорт проектной модели или запуск таска. И при запуске тасков это выглядит избыточно, особенно при clean. Основной вариант использования(по моему мнению) mvn agrs - это переопределение стандартных настроек Maven во всех процессах плагина (кастомные сеттинги -s /home/settings.xml, локальный репо -Dmaven.repo.local=/home/my_repository и прочее). Поэтому я решил сделать отдельную настройку ‘Import args’ для указания дополнительных аргументов, который будут использоваться только при импорте.
Будет вот так (в ближайшее время выложу новую версию в основной Marketplace, уже не alpha):
Additional args - будут добавляться во все maven процессы, включая импорт. Основное назначение переопределять во всех процессах базовые Maven параметры. Для частных случаев можно создать Run Configuration.
Import args - только для импорта.
Потому что плагины для IDE не пишутся с чистого листа. Для IDEA плагинов есть свой шаблон, встроенный в стандартный wizard. Который использует Gradle и обеспечивает базовый флоу написания плагинов - их запуск, отладку, публикацию в marketplace и прочее. И заниматься изысканиями на тему, а можно ли это переделать на Maven, я не видел смысла, т.к. решал совсем другую проблему.
Тем более официальная документация не дает альтернатив. А поиск решений для Maven, находит только не активные проекты вроде - https://plugins.jetbrains.com/plugin/7127-intellij-plugin-development-with-maven/versions и https://maven.apache.org/plugins/maven-idea-plugin/
Спасибо за обратную связь! Интересный use case. Еще одно доказательство того, что нет ничего лучше чем полноценный maven lifecycle для импорта проекта) Если найдете какие то проблемы, то смело пишите в лс. А как раньше вы работали со своим проектом - Eclipse?
GMaven Plus это плагин для Maven.
Мой GMaven это плагин для IDEA. И с аналогичным именем в IDEA Marketplace других плагинов нет. К тому же я не уверен что имя плагина должно быть уникальным, в отличии от plugin id.