El problema:
- Deseo ejecutar una aplicación escrita en Java en un Mac M1 (que ejecuta Monterey 12.0.1, por cierto).
- La aplicación contiene al menos un archivo .jar con un binario universal de mac que contiene sólo un fork de i86, sin fork de arm
- esta aplicación funcionaba con el JRE de Oracle (Java 8 Update 311)
- pero una vez que instalé el JDK 17 de Oracle para Arm 64 (desde el .dmg en lugar del tarball), el lanzamiento falló, ya sea que lo lanzara desde la línea de comandos (que definitivamente sería a través del SDK) o desde Finder como antes.
- En particular, falla al quejarse de la falta de soporte nativo del brazo.
- presumiblemente algún binario JRE, que toleraba/emulaba/esperaba intel, fue reemplazado por uno que exigía ARM.
Solución deseada:
- Idealmente, me gustaría ser capaz de construir y depurar aplicaciones java tanto para intel como para macs M1, y ejecutar cualquiera de los dos tipos si los descargo.
- En su defecto, me gustaría poder tener instalado el SDK apropiado para mi hardware, y seguir ejecutando aplicaciones java sólo para Intel desde el JRE.
- Me conformaría con una forma de desinstalar el SDK y volver al estado de sólo JRE que tenía antes de instalarlo.
¿Alguien sabe cómo lograr algo de esto? El sitio de Oracle ni siquiera me dice cómo desinstalar el SDK - sólo cómo instalar Java por completo.
Si alguien sabe cómo el desarrollador de la aplicación, que puede que ni siquiera tenga un mac, puede construir su aplicación para que funcione de forma nativa tanto en los macs intel como en los ARM, es decir, poblar ambas partes del binario universal de mac.
Edición: respondiendo al comentario de abajo, aquí hay un ejemplo de los errores que me hicieron creer que había un componente nativo, aunque se supone que el propio Java es independiente del sistema operativo y del hardware.
gluegen_rt parece ser parte de la aplicación; en particular, la aplicación comprueba si hay una versión actual de la misma al iniciarse y la descarga si no existe. Normalmente aparece con un nombre que sugiere que es un *.jar, no una lib*.dylib.
java.lang.UnsatisfiedLinkError: /private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib: dlopen(/private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib, 0x0001): tried: '/private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/libgluegen_rt.dylib' (no such file)
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:384)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:228)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:170)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
at java.base/java.lang.Runtime.load0(Runtime.java:755)
at java.base/java.lang.System.load(System.java:1953)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:604)
at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:107)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:488)
at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:427)
at com.jogamp.common.os.Platform$1.run(Platform.java:321)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at com.jogamp.common.os.Platform.<clinit>(Platform.java:290)
at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:154)
at haven.JOGLPanel.mkcaps(JOGLPanel.java:73)
at haven.JOGLPanel.<init>(JOGLPanel.java:93)
at haven.MainFrame.<init>(MainFrame.java:172)
at haven.MainFrame.main2(MainFrame.java:445)
at haven.MainFrame.lambda$main$0(MainFrame.java:481)
at java.base/java.lang.Thread.run(Thread.java:833)Aquí están los mensajes de lanzamiento que me hacen creer que gluegen-rt es parte de la aplicación.
$ java -jar ~/Downloads/updater-hafen.jar
OS: 'Mac OS X', arch: 'aarch64'
Checking for updates...
Updates found for 'jogl.jar'
Updates found for 'gluegen-rt.jar'
Updates found for 'hafen-res.jar'
Updates found for 'builtin-res.jar'
Updates found for 'hafen.jar'
Updates found for 'client-res.jar'
Downloading 'jogl.jar'
Downloading 'gluegen-rt.jar'
Downloading 'hafen-res.jar'
Downloading 'builtin-res.jar'
Downloading 'hafen.jar'
Downloading 'client-res.jar'
Starting client...
java -Xmx2048m -Dsun.java2d.uiScale.enabled=false -Djava.library.path="%PATH%":. -jar client/hafen.jar -U https://www.havenandhearth.com/res/ game.havenandhearth.comOtros mensajes que parece que no he guardado sugerían que gluegen-rt.jar contenía porciones de linux-intel, linux-arm, Windows y mac, y que la porción de mac era un binario "universal" de mac que sólo contenía un fork de intel.
