Связь между Java и Haskell
Я погуглил и получил несколько ответов, что связь между Java и Haskell может осуществляться с помощью GCJNI(теперь сайт не работает) и LambdaVM. Чтобы использовать LambdaVM/GCJNI, нужно ли мне загружать какие-либо инструменты для сборки? Где я могу узнать о них больше, так как я не нахожу много ресурсов в Интернете?
Я хочу разработать приложение, которое обменивается данными между Java и Haskell(где я получу входные данные от Java, передам его на Haskell, обработаю там и верну результат обратно в Java). Это то, что я хочу сделать. Пожалуйста, помогите мне...
4 ответа
Вызов Haskell из C выглядит довольно просто, и, следовательно, также может быть легко вызван из Java с помощью JavaCPP. Например, чтобы позвонить fibonacci_hs() функция из примера кода Safe.hs:
{-# LANGUAGE ForeignFunctionInterface #-}
module Safe where
import Foreign.C.Types
fibonacci :: Int -> Int
fibonacci n = fibs !! n
where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
fibonacci_hs :: CInt -> CInt
fibonacci_hs = fromIntegral . fibonacci . fromIntegral
foreign export ccall fibonacci_hs :: CInt -> CInt
мы можем сделать это таким образом из Java:
import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;
@Platform(include={"<HsFFI.h>","Safe_stub.h"})
public class Safe {
static { Loader.load(); }
public static native void hs_init(int[] argc, @Cast("char***") @ByPtrPtr PointerPointer argv);
public static native int fibonacci_hs(int i);
public static void main(String[] args) {
hs_init(null, null);
int i = fibonacci_hs(42);
System.out.println("Fibonacci: " + i);
}
}
Под Linux процедура компиляции выглядит следующим образом:
$ ghc -fPIC -dynamic -c -O Safe.hs
$ javac -cp javacpp.jar Safe.java
$ java -jar javacpp.jar -Dplatform.compiler=ghc -Dplatform.compiler.output="-optc-O3 -Wall Safe.o -dynamic -fPIC -shared -lstdc++ -lHSrts-ghc7.6.3 -o " -Dplatform.linkpath.prefix2="-optl -Wl,-rpath," Safe
И программа работает нормально с обычным java команда:
$ java -cp javacpp.jar:. Safe
Fibonacci: 267914296
Изменить: я позволил себе сделать некоторые микробенчмаркинг вызова накладных расходов. Со следующим заголовочным файлом C
Safe.h:inline int fibonacci_c(int n) {
return n < 2 ? n : fibonacci_c(n - 1) + fibonacci_c(n - 2);
}
следующий класс Java:
import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;
@Platform(include={"<HsFFI.h>","Safe_stub.h", "Safe.h"})
public class Safe {
static { Loader.load(); }
public static native void hs_init(int[] argc, @Cast("char***") @ByPtrPtr PointerPointer argv);
public static native int fibonacci_hs(int i);
public static native int fibonacci_c(int n);
public static int fibonacci(int n) {
return n < 2 ? n : fibonacci(n - 1) + fibonacci(n - 2);
}
public static void main(String[] args) {
hs_init(null, null);
for (int i = 0; i < 1000000; i++) {
fibonacci_hs(0);
fibonacci_c(0);
fibonacci(0);
}
long t1 = System.nanoTime();
for (int i = 0; i < 1000000; i++) {
fibonacci_hs(0);
}
long t2 = System.nanoTime();
for (int i = 0; i < 1000000; i++) {
fibonacci_c(0);
}
long t3 = System.nanoTime();
for (int i = 0; i < 1000000; i++) {
fibonacci(0);
}
long t4 = System.nanoTime();
System.out.println("fibonacci_hs(0): " + (t2 - t1)/1000000 + " ns");
System.out.println("fibonacci_c(0): " + (t3 - t2)/1000000 + " ns");
System.out.println("fibonacci(0): " + (t4 - t3)/1000000 + " ns");
}
}
выводит это с процессором Intel Core i7-3632QM @ 2,20 ГГц, Fedora 20 x86_64, GCC 4.8.3, GHC 7.6.3 и OpenJDK 8:
fibonacci_hs(0): 200 ns
fibonacci_c(0): 9 ns
fibonacci(0): 2 ns
Справедливости ради стоит отметить, что заходить в JVM тоже довольно дорого...
Обновление: с недавними изменениями в JavaCPP пользователи теперь могут получить доступ к функции обратного вызова (указатели) по имени из C/C++, что позволяет легко вызывать JVM из Haskell. Например, на основе информации, найденной на вики-странице относительно FFI Haskell, со следующим кодом, размещенным в
Main.hs:{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C -- get the C types
import Foreign.Ptr (Ptr,nullPtr)
-- impure function
foreign import ccall "JavaCPP_init" c_javacpp_init :: CInt -> Ptr (Ptr CString) -> IO ()
javacpp_init :: IO ()
javacpp_init = c_javacpp_init 0 nullPtr
-- pure function
foreign import ccall "fibonacci" c_fibonacci :: CInt -> CInt
fibonacci :: Int -> Int
fibonacci i = fromIntegral (c_fibonacci (fromIntegral i))
main = do
javacpp_init
print $ fibonacci 42
и fibonacci функция, определенная в Java следующим образом:
import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;
@Platform
public class Main {
public static class Fibonacci extends FunctionPointer {
public @Name("fibonacci") int call(int n) {
return n < 2 ? n : call(n - 1) + call(n - 2);
}
}
}
мы можем собрать под Linux x86_64 что-то вроде:
$ javac -cp javacpp.jar Main.java
$ java -jar javacpp.jar Main -header
$ ghc --make Main.hs linux-x86_64/libjniMain.so
и программа выполняется правильно, выдавая такой вывод:
$ ./Main
267914296
Если вы выберете подход на сервере Haskell, вы можете использовать библиотеку MessagePack serialization / rpc. У него есть привязки как для Java, так и для Haskell, и привязки на Haskell, похоже, хорошо поддерживаются. Ищите msgpack и msgpack-rpc в Hackage.
Вот забавный пример взаимодействия Java/Haskell с использованием MessagePack: Java-сервер, клиент Haskell (ссылки идут на GitHub). Общение в противоположном направлении от того, что вы хотите, хотя.
Это зависит от того, как вы хотите, чтобы они общались. Иметь код Java и Haskell, работающий изначально в одном и том же процессе и обменивающийся данными в памяти через их соответствующие FFI, - огромная проблема, не в последнюю очередь потому, что у вас есть два GC, борющихся за данные, и два компилятора, каждый из которых имеет свои собственные идеи представления различные типы данных. Скомпилировать Haskell под JVM также сложно, потому что у JVM (в настоящее время) нет концепции замыканий.
Конечно, это можно сделать, но переход от демонстратора к промышленному инструменту требует огромных усилий. Насколько я понимаю, инструменты, о которых вы говорите, никогда не выходили за рамки демонстрации.
Более простое, хотя и менее изящное решение - написать программу на Haskell в виде серверного процесса, который отправляет данные через сокеты из Java. Если производительность и объем не слишком высоки, то кодирование в JSON, вероятно, будет простым, поскольку обе стороны имеют библиотеки для его поддержки.
TL;DR: использовать шаблон передачи сообщений (т. Е. Клиент-сервер RPC или одноранговые узлы).
Зачем? Это безопаснее, масштабируемо, гибко и отлаживаемо. Вызов в FFI будет хрупким и сложным для тестирования.
Основы / спецификации RPC
gRPC Публичная ветка Google Protobufs RPC через HTTP/2
msgpack-rpc Не включает транспорт.
zerorpc ZeroMQ + msgpack. Имеет только реализации Python и Node. Кажется, заброшенный тоже.
XML-RPC зрелый. Широкая совместимость, но это также XML.
JSON-RPC Легче отлаживать. Не бинарный протокол, хотя BSON может взломать некоторые библиотеки.
Сериализация
Буферы протокола (protobufs) Существует много, гораздо больше инструментов для этого, чем другие. Он поддерживает версионные / необязательные элементы данных, которые не требуют перекомпиляции (или разрушения) мира для взаимодействия.
msgpack Симпатичный, простой и эффективный, но не поддерживающий совместимые изменения схемы. Это просто тупой двоичный кодек. Вероятно, слишком простой и низкоуровневый для практического использования.
Транспорты
ZeroMQ Вероятно, самый быстрый, не Infiniband/FC/10 GbE, не потокобезопасный транспорт сообщений.
Nanomsg Новая, поточно- ориентированная, переосмысленная философия UNIX ZeroMQ от одного из ее основателей.
HTTP/2 (используется gRPC) Преимущество здесь в том, что это стандарт, который работает внутри и между центрами обработки данных, а также имеет TLS (нативный код gRPC использует BoringSSL, "более безопасный" разворот OpenSSL от Google).
MQTT Когда вам нужно реализовать push-уведомления для миллиарда устройств и использовать удобочитаемый протокол.