Me gustaría algún tipo de IPC (tubos, tal vez incluso tomas de corriente). De esta forma, su código se reduce a copiar hacia y desde matrices de bytes en C++, y usando InputStreams y OutputStreams en Java.
Recientemente trabajé en un proyecto donde teníamos una biblioteca distribuida por un tercero, que se escribió en C++. Pero cada sistema que tenemos que podría usar esta biblioteca fue escrita en Java.
Fuimos por la ruta de envolver la biblioteca como un archivo ejecutable nativo, que lee la entrada de stdin, traduciéndola a llamadas de función a la biblioteca . En consecuencia, los resultados de la biblioteca se convirtieron y el se imprimió en stdout.
Esto también significaba que el contenedor era fácil de probar, ya que todo lo que tenía que hacer era invocarlo en la línea de comando. Descubrió un lote de errores y problemas debido a esto. Lo recomiendo ampliamente
El siguiente problema era '¿Cómo invoco el envoltorio de C++' y '¿Cómo lo incluyo en el paquete con la aplicación Java'? De hecho, evitamos las respuestas a estas preguntas , al exponer el ejecutable a través de inetd. Entonces nuestras aplicaciones java invocaron el código C abriendo un socket. Porque había codificado la envoltura para comunicarse a través de la entrada estándar y salida estándar, que no tenía que modificar que en absoluto para exponerlo a través de TCP (Lea sobre inetd si estás desconcertado). La programación más ingeniosa que he hecho ... :-)
Disculpa, me puse en tangente. Trataba de ilustrar la flexibilidad que puede obtener si decide separar el código C++ en un proceso separado . El punto es que ha hecho el trabajo de coordinar sus estructuras de datos por adelantado. Entonces, inicialmente, puede mantener su otro proceso local y comunicarse a través de un conducto. El problema es que si alguna vez decide que necesita enviar las solicitudes a un servidor TCP remoto, , no le costaría mucho esfuerzo cambiar el programa java. Ya ha realizado la mayor parte del trabajo. Puede valer la pena considerarlo. Si es realmente adecuado para usted, no lo sé.
no he estará con JNI, pero sí tenemos aplicaciones que lo utilizan en el trabajo, y todos ellos sufren problemas de gestión de memoria:
1) Si la C/C++ código comete un error con la aritmética de punteros , tu aplicación Java también está jodida. Probablemente muera con un SIGSEGV. Por lo tanto, su código C/C++ es mejor, sólido, probado y merece la pena. Con el proyecto en el que estaba trabajando, la mayoría de las aplicaciones Java eran procesos de servidor, que se supone que funcionan 24/7. No confiamos en este biblioteca que mucho, útil como puede ser.
2) Pasar estructuras de datos entre Java y C++ puede ser problemático. Especialmente si pasa objetos Java a las funciones C.Por lo general, tiene que realizar algún tipo de conversión, lo que plantea problemas tales como '¿Debería copiar esta estructura de datos? ¿Cuándo debería destruirlo? Es especialmente malo si inadvertidamente llamas 'gratis' en algún objeto que fue asignado en el programa Java.
3) He visto un código JNI. Simplemente se ve feo ... [barf]
Perdón por la larga publicación.
¿esto realmente es compatible con C++, o solo admite funciones, y no C++ - clases/class-methods, etc.? – smerlin
Entonces, lo que estoy viendo en JNI es que los wrappers se escriben antes de que se introduzca el código C++ (o cualquier otro idioma). Ya tengo todo el código C++, entonces ¿qué es lo que no estoy acertando sobre JNI? – sparkFinder
Creo que tienes que escribir algo en C++ para llamar a tu código, y el resto en Java para llamar a tu contenedor. Por lo tanto, tendrá su código original, el contenedor de C++ accediendo al código original, el JNI de Java y el acceso de Java al envoltorio de Java. – Victor