Доступные библиотеки сопрограмм на Java

Question

Я хотел бы сделать кое-что в Java, которое было бы более понятным, если бы оно было написано с использованием параллельных подпрограмм, но для которых полноценные потоки являются серьезным излишним. Ответ, конечно же, заключается в использовании сопрограмм , но в стандартных библиотеках Java поддержки сопрограмм, по-видимому, нет, и быстрый гугл об этом тут или там вызывает заманчивые подсказки, но ничего существенный.

Вот что я нашел до сих пор:

• JSIM имеет класс сопрограммы, но выглядит довольно тяжеловесно и сопоставляется, по-видимому, с темы в точках. Смысл этого состоит в том, чтобы уменьшить сложность полной многопоточности, а не добавлять к Это. Кроме того, я не уверен, что класс можно извлечь из библиотеки и использовать независимо.
• Xalan имеет класс набора сопрограмм, который делает вещи, подобные сопрограммам, но опять же сомнительно, если это может быть содержательно извлечен из всей библиотеки. Похоже, что это реализовано как строго контролируемая форма пула потоков, а не фактические сопрограммы.
• Есть проект Google Code , который выглядит как то, что я ищу, но, если что-то выглядит больше тяжелее, чем использование потоков. Я в основном нервничаю из-за того, что требуется программное обеспечение для динамически изменять байт-код JVM во время выполнения, чтобы выполнять свою работу. Это выглядит как излишнее и как то, что вызовет больше проблем, чем решит сопрограмма. Дальше похоже, что нет реализовать всю концепцию сопрограмм. На мой взгляд, это дает yield функцию, которая просто возвращает к призывателю. Правильные сопрограммы позволяют yield s передавать управление любой известной сопрограмме напрямую. По сути, эта библиотека, тяжеловесная и страшная как таковая, дает вам поддержку только итераторов, а не полностью общие сопрограммы.
• Многообещающее имя Coroutine для Java терпит неудачу, потому что это зависит от платформы (очевидно, с использованием JNI) решение.

И это все, что я нашел.

Я знаю о встроенной поддержке JVM сопрограмм в машине Да Винчи, а также знаю о трюке с продолжением JNI для этого. Однако это не очень хорошие решения для меня, так как я не обязательно буду контролировать, на какой виртуальной машине или платформе будет работать мой код. (Действительно, любая система манипулирования байт-кодом страдает от подобных проблем - было бы лучше, если бы эта чистая Java была бы возможной. Манипулирование байт-кодом во время выполнения ограничило бы меня от использования этого на Android, например.)

Так у кого-нибудь есть указатели? Это вообще возможно? Если нет, будет ли это возможно в Java 7?

---

Отредактировано, чтобы добавить:

Просто чтобы убедиться, что путаница заключена, это связанный вопрос к моему другому , но не тот же. Эта модель ищет существующую реализацию в попытке избежать ненужного повторного изобретения колеса. Другой вопрос касается того, как можно было бы реализовать сопрограммы в Java, если бы этот вопрос оказался неопровержимым. Цель состоит в том, чтобы держать разные вопросы в разных темах.

---

Далее отредактировано, чтобы добавить:

Выбран ответ . Некоторые комментарии, однако, в порядке. Указанная библиотека не является библиотекой сопрограмм, поэтому технически она не отвечает на мой вопрос. При этом, однако, у него есть два ребра над проектом Google Code, с которым связано выше:

1. Оба решения используют манипулирование байт-кодом, но выбранная библиотека позволяет статическое манипулирование байт-кодом, что делает его пригодным для использования в Android и других несовместимых стеках JVM.
2. Проект Google Code не выполняет всех сопрограмм. Хотя библиотека ответов даже не выполняет сопрограммы вообще, она делает что-то более важное: она обеспечивает хороший фундаментальный инструмент для прокрутки моих собственных полнофункциональных сопрограмм.

Answer 1

Javaflow - это продолжение реализации, вероятно, оно позволит вам это сделать. Он использует манипулирование байт-кодом, хотя.

Во всяком случае, такое чувство, что вы пытаетесь сделать ООП с простым C. Это выполнимо, но это не значит, что вы должны это сделать.

Answer 2

Фреймворк Kilim реализует сопрограммы с помощью перезаписи байтового кода. Я сам использовал его для реализации легких процессов в Erjang , и он очень стабилен и удивительно быстр для продолжающегося переписывания байт-кода.

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

Answer 3

Что вы думаете об этой библиотеке продолжений, написанной Матиасом Манном? Я скопировал плюсы и минусы с веб-сайта создателя, чтобы облегчить обсуждение. Важно посмотреть на тесты в исходном коде, чтобы увидеть не только один пример на веб-сайте.

http://www.matthiasmann.de/content/view/24/26/

Давайте начнем с того, что вы получаете:

• Пишите простой последовательный код - вам больше не нужно создавать конечные автоматы вручную
• Потоки не создаются или не нужны - нет проблем с многопоточной синхронизацией
• Нет создания мусора из выполнения кода
• Очень небольшие накладные расходы
• Изменяются только приостановленные вызовы методов - все вызовы в вашей стандартной библиотеке (например, java.util. * И т. Д.) Не затрагиваются вообще.
• Полная поддержка сериализации
• Вы можете сохранить состояние выполнения сопрограмм как часть вашего игрового состояния в вашей сохраненной игре без какого-либо дополнительного кода. Это, конечно, требует, чтобы ваши классы и типы данных, которые вы используете в своих сопрограммах, были сериализуемыми. Полная поддержка обработки исключений и, наконец, блоки
• Предварительная обработка в автономном режиме не замедляет время загрузки приложения Конечно, инструменты исполнения также возможны.
• Очень маленькая библиотека времени выполнения - менее 10 КБ (несжатый JAR) Лицензия BSD

Со всеми этими замечательными функциями - вы можете спросить о недостатках. Ну, есть, конечно, несколько недостатков:

• Конструкторы и статические инициализаторы не могут быть приостановлены
• Приостановимые методы не могут быть синхронизированы или имеют синхронизированные блоки
• Вам нужно скачать библиотеку ASM3 для запуска задачи инструментария
• Вы не можете вызвать приостановленный метод с отражением

Проблему синхронизации можно обойти, поместив код, который требует использования синхронизации, в свой собственный метод.

Answer 4

Ваши требования:

• легкий - без учета потоков,
• не зависит от нативного кода и
• не использовать модификацию байт-кода.

У меня неприятное ощущение, что эти требования исключили все разумные стратегии для реализации сопрограмм в Java.

Answer 5

Если вы используете Java, на конец 2017 года доступно 2 варианта:

• Сопрограмма
• Tasclate-Javaflow

Оба они основаны на commons-javaflow - они переписывают ваш код на уровне байт-кода, чтобы все заработало.

Я поддерживаю Сопрограммы - Преимущества в том, что он быстрый, поддерживает все основные системы сборки и поддерживает сериализацию / управление версиями ваших сопрограмм. Недостатком является то, что API имеет несколько отклонений от commons-javaflow.

Всилаев поддерживает Tasclate-Javaflow - я не использовал его, поэтому не могу об этом говорить, но он поддерживается и, глядя на примеры, его API-интерфейс ближе к общему javaflow.

Существуют также языковые функции в Kotlin и Scala (и, возможно, других языках на основе JVM), которые позволяют вам использовать сопрограммы. Но, прежде чем переключать языки, вы должны знать, что Kotlin, Scala или любой другой язык JVM du jour сегодня не является и никогда не будет Java. Что бы он ни делал в фоновом режиме, чтобы все заработало, он может не сработать, когда наступит следующий выпуск JVM.

Люди, которые поддерживают JDK в Oracle, имеют опыт использования этих сторонних языков JVM в качестве исследования рынка. Если высокоуровневая функция будет добавлена ​​в сторонний язык JVM и она достаточно популярна, они включат ее в Java. Это то, что сейчас происходит с сопрограммами. Существует проект OpenJDK под названием Project Loom , который направлен на добавление сопрограмм в язык Java.

Для Project Loom еще рано. Если вы критически просматриваете предложение, это беспорядок. Я уверен, что со временем это стабилизируется, но то, что мы в конечном итоге получим, может полностью отличаться от того, что многие из нас ожидают.

Напомним, что вы можете либо использовать один из инструментариев байт-кода, либо переключать языки. Project Loom все еще находится на ранних стадиях, и есть вероятность, что он никогда не будет добавлен в Java.

Answer 6

платформа Play теперь предоставляет продолжения с Javaflow. Поскольку в других областях игра предоставляет такие удобства, вы можете начать с нее.

http://www.playframework.org/documentation/1.2RC2/releasenotes-1.2#Continuations

Answer 7

Для Java доступна новая библиотека сопрограмм. Он реализован на чистой Java, поэтому нет необходимости в JNI или агентах Java, работающих отдельно. Это открытый исходный код и может быть загружен с GitHub:

https://github.com/esoco/coroutines

Введение в рамки можно найти на Medium:

https://medium.com/@esocogmbh/65661a379c85

Answer 8

Quasar реализует Go-подобные сопрограммы и каналы среди других функций с использованием продолжений.

Более подробная информация, тесты и ссылки на Quasar в моем другом ответе .

Answer 9

Я проверил связанный вопрос, который вы связали, и на всю жизнь я не могу понять, что же такого плохого в темах. В потоках Java никогда не являются нативными потоками, это просто изолированные исполнительные блоки, которые в зависимости от контекста могут работать как их собственные нативные потоки, если это выгодно, то есть разумное разделение больших исполняющих блоков на собственные потоки при сохранении маленьких в нескольких более разумно из-за накладных расходов.

Тем не менее, Java / JDK изначально не имеет сопрограмм, доступных для программистов высокого уровня - пока. JDK7 ( всякий раз, когда это выходит ) будет иметь то, что известно как jsr166y , который является структурой Fork / Join Дуга Ли. Для получения технической информации проверьте этот PDF от mr. Сама Леа. На практике Fork / Join добавляет еще один ( полезный! ) уровень детализации поверх модели внутренней потоковой обработки Java, которая должна помочь вам достичь того, чего вы хотите.