Add support for running inside ARM64 JRE

[dg76]

Hi,

thank you for this great library! :-)

Unfortunately it does not load on the new macOS 13:

SEVERE: java.lang.UnsatisfiedLinkError: Can't load library: /Users/dom/Library/Caches/JNA/temp/jna11470923764084623985.tmp
Oct 28, 2022 1:33:15 PM  
SEVERE:     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)
Oct 28, 2022 1:33:15 PM  

and

SEVERE: java.lang.NoClassDefFoundError: Could not initialize class ca.weblite.objc.RuntimeUtils
Oct 28, 2022 1:33:15 PM  
SEVERE:     at javaobjectivecbridge@1.2/ca.weblite.objc.Client.sendPointer(Client.java:340)
Oct 28, 2022 1:33:15 PM  
SEVERE:     at javaobjectivecbridge@1.2/ca.weblite.objc.NSObject.init(NSObject.java:193)
Oct 28, 2022 1:33:15 PM  
SEVERE:     at javaobjectivecbridge@1.2/ca.weblite.objc.NSObject.<init>(NSObject.java:122)
Oct 28, 2022 1:33:15 PM  

Do you have an idea what might cause this and how to fix it?

Thank you very much!

[dg76]

I think it has something to do with running it in arm64 mode on an M1 mac. I will examine it further, maybe it is just a problem on my side. I will close this issue. Sorry, it seems that I cannot delete it.

[shannah]

Can you comment on why you closed the issue?

[dg76]

I was trying to find out why my Java program does not work on macOS 13. Because I am still using macOS 12 on my M1 Mac I installed macOS 13 in UTM ( https://mac.getutm.app/ ). There I had to recreate my development environment and I accidentally used an arm64 JDK instead of an x86 JDK. Somehow this caused the errors mentioned above.

I don't know why it doesn't work in arm64 mode yet. But it works fine in x86 mode. And I have found the real reason for the crash now. Previously running the command ekEvent.sendBoolean("allDay") on an EKEvent object worked fine. Now it has to be ekEvent.sendBoolean("isAllDay").

So this library seems to work fine on macOS 13 in x86 mode. I could not get it working in arm64 mode yet but I didn't try that on macOS 12 either so far. If I find that there is a problem in arm64 mode I will create a new issue here. I see that M1/arm64 support was added so it probably should work. Maybe I did something wrong on macOS 13. I will first try to get it running in arm64 moe in macOS 12 and then I will check if it works on macOS 13, too. Thank you for your quick response! :-)

[shannah]

I've changed the name of the issue and reopened, as we need to add support for running in an ARM64 JRE.

[dg76]

Hi,

ok, I have tried to use it with the zulu17.32.13-ca-fx-jdk17.0.2-macosx_aarch64 JDK on macOS 12 now. I thought arm64/M1 support was already finished due to the completed issue https://github.com/shannah/Java-Objective-C-Bridge/issues/41 . However I get the UnsatisfiedLinkError mentioned above and when I check what the file contains, it contains only i386 and x86_64 code:

$ file ~/Library/Caches/JNA/temp/jna7507673842831383718.tmp
/Users/dom/Library/Caches/JNA/temp/jna7507673842831383718.tmp: Mach-O universal binary with 2 architectures: [i386:Mach-O dynamically linked shared library i386Mach-O dynamically linked shared library i386] [x86_64:Mach-O 64-bit dynamically linked shared library x86_64Mach-O 64-bit dynamically linked shared library x86_64]
/Users/dom/Library/Caches/JNA/temp/jna7507673842831383718.tmp (for architecture i386):  Mach-O dynamically linked shared library i386
/Users/dom/Library/Caches/JNA/temp/jna7507673842831383718.tmp (for architecture x86_64):        Mach-O 64-bit dynamically linked shared library x86_64

Sorry, it seems that I don't understand what the issue https://github.com/shannah/Java-Objective-C-Bridge/issues/41 was about. I thought it was about adding support for arm64 on M1? I have used version 1.2 of the Java-Objective-C-Bridge. Is there anything that I have to do to activate the generation of arm64 code in the library? Or is that just not supported yet and thus you have reopened this issue here? 🤔

[shannah]

Oh. Yeah. I did already add support for M1, and multiple projects are reported to be working with it. What version are you using? And where are you downloading it from. I'd like to inspect the dylib.

[shannah]

I just downloaded the lib from maven central - version 1.2, and checked the native lib, and it appears to be compiled for aarch64.

ip-10-0-1-81:java-objc-bridge-1.2 shannah$ file libjcocoa.dylib
libjcocoa.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64
- Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64
- Mach-O 64-bit dynamically linked shared library arm64]
libjcocoa.dylib (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64
libjcocoa.dylib (for architecture arm64):   Mach-O 64-bit dynamically linked shared library arm64

[shannah]

Regarding your output from file ~/Library/Caches/JNA/temp/jna7507673842831383718.tmp

JNA should load the correct version of the shared lib for the architecture. If you are running in an x64 vm, the shared lib will be the x64 lib. On the arm64 vm, it should use the arm64 lib.

Is it possible that the lib that you are checking was created while running in the x64 vm?

[dg76]

I have found the reason now. I had loaded version 5.6.0 instead of 5.10.0 of net.java.dev.jna:jna and used an old version of oshi-core ( https://github.com/oshi/oshi ) which also referenced an old version of jna. I have updated oshi-core to 6.3.0 and net.java.dev.jna:jna to 5.12.1 and now it works! 🎉😊 Thank you very much for your quick responses!

[shannah]

Great! Thanks for sharing your experience. I'm sure it will help one or two future travellers who face similar obstacles