Совместное использование потоков вывода через интерфейс JNI

Как я могу вызвать Foo :: print из Java чтобы вывод появлялся на выходе?

С концептуальной точки зрения, способ получить Foo :: print (...) для записи в существующий экземпляр Java OutputStream - это написать реализацию C ++ std :: ostream, которая фактически выполняет обратный вызов в Java для вывода.

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

Есть ли способ принудить OutputStream в std :: ostream в Уровень JNI?

AFAIK №

Могу ли я записать вывод в буфер слой JNI, а затем скопируйте его в нет?

Вы имеете в виду что-то примерно такое?

    MyJNIThing m = ...
    int myOstream = m.createMemoryBackedOStream(...); // native method
    ...
    m.someMethodWrapper(... myOStream); // native method
    ...
    byte[] data = m.getCapturedData(myOStream); // native method
    out.write(data);

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

Но я думаю, вам действительно стоит стремиться к устранению этого Код C ++ вместо того, чтобы пытаться делать все более сложные вещи с помощью JNI. IMO, JNI следует использовать только в крайнем случае, а не как кратчайший путь, чтобы избежать перекодирования на Java.

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

Я бы реализовал Ostream C ++, который буферизует записи (до некоторого заданного размера) перед сбросом этих записей в поток вывода java через JNI.

На стороне Java вы можете либо использовать обычный экземпляр OutputStream, либо реализовать постановку в очередь блоков буфера (по сути, byte []), чтобы избежать возможного конфликта блокировок между потоками. Реальный выходной поток используется только задачей в другом потоке, который извлекает блоки из очереди и записывает их в OutpuStream. Я не могу сказать, необходимо это или нет на этом уровне детализации - вы вполне можете обнаружить, что запись напрямую в выходной поток из JNI работает.

Я не разделяю других проблем, связанных с постерами, с JNI и не вижу никаких проблем с использованием JNI для этого. Конечно, ваши сопровождающие должны будут знать свое дело, но это все, и сложностью уровня Java / C ++ можно управлять с помощью документации, примеров и тестовых примеров. В прошлом я реализовал мост Java <> COM с довольно болтливым интерфейсом - никаких проблем с производительностью, потоками или обслуживанием.

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