De Java JNI en plataformas de 64bits

Hace un par de años tuve la necesidad y el gusto de implementar una biblioteca JNI para poder hacer uso de un código escrito en C/C++. La biblioteca quedó bien (don modesto) y logré que funcionara correctamente en sistemas Windows, Linux, y hasta Solaris.

Repito, hasta la fecha todo había funcionando bien, y sin novedad. Sin embargo, hace unos días los usuarios me reportaron que su aplicaciones habían dejado de funcionar, que marcaban error. Después de investigar un poco para ver que pasaba, llegué a esto:


"Exception in thread "main" java.lang.UnsatisfiedLinkError: base.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform"

Sucede que a estos usuarios les compraron unos super-equipos con doble procesador, mucha memoria, mucho disco etc etc.. pero con un jodidisimo sistema operativo, jaajaja, Windows Vista a 64bits. Ups!

El JRE que trae instalado, también es a 64bits, y pues ese es el detalle, Java 64-bits no puedo cargar una biblioteca nativa a 32-bits.

Mi opción inmediata (no tenía mucho tiempo) fue bajarle al Java, instalé un JRE 32-bits, configuré, probé, y listo! Sin embargo, esta solución no me dejó muy satisfecho.

Y bueno, en resumen, bajé un compilador GCC con soporte para 64bits en sistemas Windows, compilé de nuevo mi bilioteca, generé un DLL a 64bits, y ahora el Java/JRE 64-bits puede cargar el DLL sin problemas. Lo que me resta es hacer algunas pruebas para verificar que todo funciona bien como antes, cuando todos mis usuarios eran Windows a 32bits.

La aventura realmente fue encontrar un GCC 64 bits para MS windows, no hay mucho de donde escoger, de hecho tengo la impresión que el único proyecto con esta capacidad es mingw64, ai' les paso el tip.

Sale y vale
Byte

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Opciones

Afortunadamente tuviste la opción de recompilar el DLL a 64 bits; la mayoría de los casos en que se usa JNI es porque no hay un equivalente para ese software en Java, lo cual normalmente implica que no hay código fuente tampoco, por lo que recompilar no es una opción, solamente queda usar JRE de 32 bits.