Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adding Mac ARM support #591

Closed
8 tasks done
tresf opened this issue Feb 24, 2020 · 12 comments
Closed
8 tasks done

Adding Mac ARM support #591

tresf opened this issue Feb 24, 2020 · 12 comments
Assignees
@tresf
Labels
enhancement

Comments

@tresf
Copy link
Contributor

tresf commented Feb 24, 2020 •
edited
Loading

TODO:

... Somewhat related: Homebrew/homebrew-core#65670

What works through emulation:

  • AdoptOpenJDK11 installtaion
  • QZ Tray 2.1.1 installation
  • PDFWriter installation
  • Printing PDFs
  • Listing serial ports
  • Listing HID ports

What doesn't work through emulation:

Original Post

Click to expand

The rumors of Apple switching to ARM are getting stronger...

https://9to5mac.com/2020/02/24/apple-to-release-first-arm-mac-without-intel-processor-in-next-18-months-predicts-kuo/

Ming-Chi Kuo is out with a new analyst note today and the most interesting part of his forecast is that Apple will release its first Mac with an ARM processor in the first half of 2021.

This is a fairly short amount of time to create a build with ARM support especially considering there's currently no ARM Java SDK out for Java making a runtime a non-starter.

Apple may find a way to emulate the x86 instruction set to buy us some time, but it would have to be x86-64 since Catalina dropped support for 32-bit applications.

To support this, well need either:

  1. A way of creating either a universal installer
    -- or --
  2. ARM platform detection on our downloads page

White-Label builds will be directly impacted as we currently leverage an x86-64 Mac to build for all platforms.
@tresf tresf added the timebomb Something's going to break on a specific day label Feb 24, 2020
@tresf tresf self-assigned this Feb 24, 2020
@tresf
Copy link
Contributor Author

tresf commented Jun 23, 2020 •
edited
Loading

The rumors have come true and Apple has confirmed the following:

  • Rosetta 2: x86_64 emulation layer for non-native apps
  • Universal 2: Dual x86_64 + ARM binary format

The good news is the current x86_64 version of Java will run as-is through hardware emulation according to claims by Apple. This is actually better than the situation with Windows (#605) where emulation is limited to 32-bit apps only.

In order to test the new Mac, a company needs to be enrolled into the early developer program. If accepted, the company receives a loaner Mac Mini equipped with MacOS "Big Sur", an Apple A12Z CPU, 16 GB RAM, 512 GB SSD. Edit:, it's against the license agreement with Apple to disclose any information about this kit if/once received so this thread may go dark for a bit. :)

FWIW, Apple's coining the hardware as "Apple Silicon", not ARM.

@tresf tresf added enhancement and removed timebomb Something's going to break on a specific day labels Jun 23, 2020
@tresf
Copy link
Contributor Author

tresf commented Jul 1, 2020 •
edited
Loading

FYI, pinged HID4Java: gary-rowe/hid4java#93

Also, I've reached out to Adopt and they're working on getting their hands on a Mac for building and testing on.

@tresf
Copy link
Contributor Author

tresf commented Jul 20, 2020

Quick update: I've released version 0.6.0 to Maven Central which has several improvements to JNA and hidapi.Quick update: I've released version 0.6.0 to Maven Central which has several improvements to JNA and hidapi.

In the examples code I've added an architecture detection logging message which should assist with selection of suitable ARM support. As I understand it, JNA supports linux-arm (32-bit hard float), linux-armel (32-bit EABI) and linux-aarch64 is directed at ARM v8 but I don't have any hardware that could trigger this detection.

Would it be possible for your team to run the 0.6.0 code on the ARM hardware and tell me what the platform output is? For example on OS X (10.15.5) the output is:

Platform architecture: x86-64
Resource prefix: darwin
In the examples code I've added an architecture detection logging message which should assist with selection of suitable ARM support. As I understand it, JNA supports linux-arm (32-bit hard float), linux-armel (32-bit EABI) and linux-aarch64 is directed at ARM v8 but I don't have any hardware that could trigger this detection.

Would it be possible for your team to run the 0.6.0 code on the ARM hardware and tell me what the platform output is? For example on OS X (10.15.5) the output is:

Platform architecture: x86-64
Resource prefix: darwin

@gary-rowe it seems some GitHub comments got rolled back (possibly due to service outages?). One major issue with ARM on Mac in general is that AFAIK there's no binaries yet, so Java will execute using the Intel x86_64 instruction set under Coretto 2 emulation. I'd be happy to run some code, but I fear that the values should match that of your 10.15.5 results unless they're running natively, no?

@gary-rowe
Copy link

it seems some GitHub comments got rolled back (possibly due to service outages?).

Nope that was me posting to the wrong project and covering my tracks. See gary-rowe/hid4java#93.

One major issue with ARM on Mac in general is that AFAIK there's no binaries yet, so Java will execute using the Intel x86_64 instruction set under Coretto 2 emulation. I'd be happy to run some code, but I fear that the values should match that of your 10.15.5 results unless they're running natively, no?

It does seem as if that would be the case based on emulation. I was thinking you had some pre-release hardware running the binaries you could use for experimentation. Let me know when you're in position to move forward with this and I'll do what I can to help.

@tresf
Copy link
Contributor Author

tresf commented Jul 20, 2020

I was thinking you had some pre-release hardware running the binaries you could use for experimentation.

I do, and I'd be happy to run tests, but at time of writing this openjdk isn't working yet. I've reached out to a few channels to see if perhaps we can at least get a zero-build for starters.

@gary-rowe
Copy link

I do, and I'd be happy to run tests, but at time of writing this openjdk isn't working yet. I've reached out to a few channels to see if perhaps we can at least get a zero-build for starters.

OK. Just give me the nod when you're ready.

@tresf
Copy link
Contributor Author

tresf commented Jul 21, 2020

I do, and I'd be happy to run tests, but at time of writing this openjdk isn't working yet. I've reached out to a few channels to see if perhaps we can at least get a zero-build for starters.

Sorry, I realized now that this is a bit specific since I've separated Windows and ARM bug reports. I do have a JDK on Windows ARM, so I can get values from that soon. I'll post them on the more broad bug report here: gary-rowe/hid4java#93

@tresf
Copy link
Contributor Author

tresf commented Jul 24, 2020

FYI: JNA PR to help support this change: java-native-access/jna#1238

@tresf
Copy link
Contributor Author

tresf commented Feb 5, 2021 •
edited
Loading

OK. Just give me the nod when you're ready.

@gary-rowe, JNA is available in snapshot form and openjdk has been ported to ARM64 and is readily available for testing, so we're ready to begin testing as soon as there's a build of HID4Java available.

@tresf tresf mentioned this issue Feb 24, 2021
Closed
@tresf tresf mentioned this issue Apr 3, 2021
Merged
@tresf
Copy link
Contributor Author

tresf commented Apr 3, 2021 •
edited
Loading

Initial support has landed on master (via #783)

What works natively:

  • ✅ JNA
  • ✅ JavaFX (but ONLY using { rasterize: true }, Monocle disabled)

What doesn't work:

  • 🚫 JavaFX vector prints (will fail after the 1st attempt, reported upstream SUPQZ-7)
  • 🚫 JavaFX Monocle (headless) prints (not available upstream yet)
  • 🚫 JSSC (we maintain this; waiting on us)
  • 🚫 HID4Java (requires upstream JNA bump, or we could just build this ourselves)

@tresf tresf mentioned this issue Apr 6, 2021
Closed
@tresf
Copy link
Contributor Author

tresf commented Aug 7, 2021 •
edited
Loading

Support has landed on master branch. Downloads will be up soon (days, not weeks).

Note, QZ Tray doesn't know the difference between a Rosetta 2 version of Java or a native version, so it's not yet intelligent enough to automatically run natively in environments with both Java versions installed. This will be fixed in QZ Tray 2.2.0 expected in a month or so.

Until QZ Tray 2.1.4 is published, we have a dedicated ARM64 installer available here:
https://github.com/tresf/tray/releases/tag/v2.1.4-RC

If you have any issues with this release, please open a new bug report.

@tresf tresf closed this as completed Aug 7, 2021
@tresf
Copy link
Contributor Author

tresf commented Aug 23, 2021

M1 downloads are available https://qz.io/download

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tresf tresf

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gary-rowe @tresf