Комментарии 18
Старый и добрый вопрос — а нахрена козе баян? Что можно улучшить в Java дёргая какой-то страшный натив? Вот получить геморой при переносе приложения банально на соседний сервер — это пожалуйста. Сразу вызываем магов с глубоким знанием си, серверной оси, её администрирования и т.д. и т.п. Они долго мучают несчастный сервер. Далее гордо заявляют — можно пробовать! Потом опять ничего не работает, но в итоге, осознавая великую важность глубокого понимания нативных процессов, мы все дружно аплодируем победителям.
Правда сегодня Java как-то обходится без аплодисментов сторонним разработчикам. Даже непонятно, как можно так легко жить? Вот поэтому нам срочно нужны нативные вызовы, ручное управление памятью, указатели, и да, конечно, вставки на ассемблере, а как без них в наше время?
Правда сегодня Java как-то обходится без аплодисментов сторонним разработчикам. Даже непонятно, как можно так легко жить? Вот поэтому нам срочно нужны нативные вызовы, ручное управление памятью, указатели, и да, конечно, вставки на ассемблере, а как без них в наше время?
Например, вам нужен нативный генератор случайных чисел. Для вызова API с мудрого железа. Вариант?
Странный пасаж. С++ корутины не зависят от платформы и их перенос не сложнее мигрирования Java кода. А написание асинхронного кода в виде синхронной программмы, да ещё и в функционально стиле — это и красиво и удобно. Где тут указатели и ручное управление памятью — не понятно. Не бойтесь кросс-языковых вызовов, если это приносит действительно новый функционал.
Если посмотреть как устроены потоки в Java, то под капотом они ложатся в системные потоки.
Используя нативные корутины, можно реализовать легковесные потоки для Java.
Используя нативные корутины, можно реализовать легковесные потоки для Java.
>> Используя нативные корутины, можно реализовать легковесные потоки для Java.
А если посмотреть, как работают «легковесные потоки», то окажется, что их можно легко реализовать на Java без вызовов нативного кода. То есть всё украдено до нас, подобные игрушки давно реализованы в виде библиотек и им не нужен натив и C++, поэтому по прежнему совершенно непонятно, зачем в Java эта модная штучка из С++.
И да, полагаться на «легковесность» потоков не всегда правильно. Если нет понимания, как оно работает внутри, то хоть легковесные, хоть какие угодно потоки, могут больно ударить по голове интересными эффектами.
Сам по себе подход «облегчения» программирования при выполнении псевдо-параллельных задач должен выбираться грамотным архитектором, который понимает все «за и против». А просто вносить в массы сумятицу и тренировать использовать непонятный большинству инструмент — это приведёт лишь к очередному витку порождения недалёких, но очень уверенных в своих скиллах программистов. На уровне языка же внедрять подобные штучки нужно ещё осторожнее. При этом стоит помнить, что изначально при разработке Java тоже предполагалось использовать «лёгкие» потоки, но потом, серьёзно подумав, от этого отказались и включили в язык стандартные потоки ОС, что полностью закрыло все потребности, включая потребность в упрощении, которое достигается банальным написанием соответствующей библиотеки. А вот не было бы привычных потоков — Java вообще вряд ли взлетела бы.
А если посмотреть, как работают «легковесные потоки», то окажется, что их можно легко реализовать на Java без вызовов нативного кода. То есть всё украдено до нас, подобные игрушки давно реализованы в виде библиотек и им не нужен натив и C++, поэтому по прежнему совершенно непонятно, зачем в Java эта модная штучка из С++.
И да, полагаться на «легковесность» потоков не всегда правильно. Если нет понимания, как оно работает внутри, то хоть легковесные, хоть какие угодно потоки, могут больно ударить по голове интересными эффектами.
Сам по себе подход «облегчения» программирования при выполнении псевдо-параллельных задач должен выбираться грамотным архитектором, который понимает все «за и против». А просто вносить в массы сумятицу и тренировать использовать непонятный большинству инструмент — это приведёт лишь к очередному витку порождения недалёких, но очень уверенных в своих скиллах программистов. На уровне языка же внедрять подобные штучки нужно ещё осторожнее. При этом стоит помнить, что изначально при разработке Java тоже предполагалось использовать «лёгкие» потоки, но потом, серьёзно подумав, от этого отказались и включили в язык стандартные потоки ОС, что полностью закрыло все потребности, включая потребность в упрощении, которое достигается банальным написанием соответствующей библиотеки. А вот не было бы привычных потоков — Java вообще вряд ли взлетела бы.
При этом стоит помнить, что изначально при разработке Java тоже предполагалось использовать «лёгкие» потоки, но потом, серьёзно подумав, от этого отказались и включили в язык стандартные потоки ОС
Справедливости ради стоит отметить, что «легкие» потоки появились в джаве в те древние времена, когда в windows с потоками было еще не очень. Когда стало очень, выпилили свои потоки не долго думая.
Вообще говоря, сейчас как раз идёт работа над тем, чтобы добавить легковесные потоки на уровне языка: Project Loom.
Да проект Loom, много обещающий и это будет хорошо если в будущем в Java внедрят файберы. Но сейчас можно как альтернативу использовать нативные корутины или что другое.
там все таки не green threads, а еще более легковесное.
собственно поэтому и стали называть fibers, чтоб не путать, роль аля context из rx-реализаций.
собственно поэтому и стали называть fibers, чтоб не путать, роль аля context из rx-реализаций.
мотивация ведь простая — быстродействие
Крайне спорный тезис. То есть в рекламе — да, могут и про скорость и про отсутствие всех на свете проблем написать, но на самом деле, снова повторюсь, ничего такого, чего нельзя сделать средствами обычной Java в этих «лёгких» потоках нет.
Единственный профит — это принятие стандарта на библиотеку (которых уже в количестве), скрывающую от неопытных разработчиков сложность управления потоками. Но стандарт, естественно, крайне плох там, где нужна гибкость. Поэтому и библиотеки останутся, и новые кастомные решения будут. Но при этом из си тянуть какой-то функционал — совершенно никак не оправдано.
Единственный профит — это принятие стандарта на библиотеку (которых уже в количестве), скрывающую от неопытных разработчиков сложность управления потоками. Но стандарт, естественно, крайне плох там, где нужна гибкость. Поэтому и библиотеки останутся, и новые кастомные решения будут. Но при этом из си тянуть какой-то функционал — совершенно никак не оправдано.
JVM написана на С++. Если не ошибаюсь в текущем коде используется С++98. Но есть предложения использовать С++14 во внутреннем коде JVM JEP 347. А о нативных корутинах, которые используются в статье используется С++2а(С++20). Поэтому может быть в далеком будущем, когда код JVM переведут на С++20(С++98 => C++14 => C++20) в JVM реализуют легкие потоки на нативных корутинах.
вы случаем не путаете stackful и stackless корутины?
Если вы уж через JNI зовете плюсовые корутины, то в чем проблема звать котлиновские корутины? Нужен асинхронный код — пишем suspend функции в котлине, а из Джавы звать только обертки над ними.
Расскажите популярно, что такое корутины?
И в том виде как упомянуты корутины в статье, в чем их принципиальное превосходство над rx-библиотеками?
И в том виде как упомянуты корутины в статье, в чем их принципиальное превосходство над rx-библиотеками?
Можно почитать вот сдесь: c++ coroutine
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование нативных корутин в Java