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.

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

Support for Apple Silicon (macOS on ARM) #7175

Closed
JosephRedfern opened this issue Dec 9, 2020 · 30 comments
Closed

Support for Apple Silicon (macOS on ARM) #7175

JosephRedfern opened this issue Dec 9, 2020 · 30 comments
Assignees
Milestone

Comments

@JosephRedfern
Copy link

JosephRedfern commented Dec 9, 2020

Apologies if this has already been discussed -- I have searched on both GitHub issues and Discourse but may have missed it.

Are there plans to provide macOS builds targeting Apple Silicon/M1/ARM64? What (if any) are the barriers to such builds being released, and is there anything that can be done to help with this?

JabRef appears functional under Rosetta 2, but native release would be optimal for both performance and efficiency. Is this a matter of bundling a JRE that doesn't rely on Rosetta 2?

Thanks,
Joe

@Siedlerchr
Copy link
Member

Thanks for the question, it has not yet been discussed. I agree that this would be a nice thing to have.

JabRef depends both on the JDK version and javafx (openfjx)
The JDK environment seems to be already available for mac arm already. At least some experimental builds.
https://openjdk.java.net/jeps/391
The other thing is OpenJFX
https://bugs.openjdk.java.net/browse/JDK-8257222
To summarize, not yet possible, but they are working on it, unfortunately not yet a release/version planned.
Best is to keep an eye on the Javafx issue.

When all those issues are fixed, you should be able to compile JabRef yourself and run it natively.

@Siedlerchr Siedlerchr added status: depends-on-external A bug or issue that depends on an update of an external library dev: build-system labels Dec 9, 2020
@Siedlerchr
Copy link
Member

There recently has been some work to build the javafx media libs and webkit libs for Apple Silicon, so it might be read with the next openjfx release.

@astroboylrx
Copy link

Any update on this issue? Thanks in advance

@Siedlerchr
Copy link
Member

Siedlerchr commented Mar 17, 2022

Yes it should be working now, but I am unsure if it needs to be built in a special way. You probably need to build JabRef from code on M1. I am not sure if the jpackage on Github CI build can get the right version

@astroboylrx
Copy link

Yes it should be working now, but I am unsure if it needs to be built in a special way. You probably need to build JabRef from code on M1. I am not sure if the jpackage on Github CI build can get the right version

Thanks. Is there documentation to follow regarding how to build it on macOS?

@Siedlerchr
Copy link
Member

To build the current version on Mac, you can just need JDK 17 https://adoptium.net/releases.html probably the aarch64 and Gradle.
then just do ./gradlew run to build and start the app for the first time.
You can also run ./gradlew jpackage . This will create the app under build/distribution
It will just show version 100 as default.

@astroboylrx
Copy link

@Siedlerchr Thank you sooo much!
I was able to build it successfully with the JDK 17 in your link (and with a few minor warnings warning: [module] module name component log4j2/ojdbc10/lang3/antlr4 should avoid terminal digits). It looks like jabref will download Gradle automatically after ./gradlew jpackage.

The about info shows

JabRef 100.0.0
Mac OS X 12.3 aarch64 
Java 17.0.2 
JavaFX 18+12

I guess I'll stick with version 100 before the official releases include arm builds 😄

@astroboylrx
Copy link

@Siedlerchr By the way, I'm happy to contribute my build to Development Builds if that's useful or helpful.

@noirchen
Copy link

@astroboylrx it would be great if you can share your builds.

@astroboylrx
Copy link

@astroboylrx it would be great if you can share your builds.

Sure, I created a repo and shared my builds in the Releases.

@Siedlerchr
Copy link
Member

@astroboylrx Cool! Thanks. The only thing is that during our Github actions build we inject some token secrets for some fetchers.

@astroboylrx
Copy link

@astroboylrx Cool! Thanks. The only thing is that during our Github actions build we inject some token secrets for some fetchers.

I see. Thanks for the info! The main fetcher I'm using to add a new entry is "SAO/NASA ADS", "DOI", and "ArXiv", which all seem to be okay so far. I guess for those who need to use some specific fetchers, they may need to stick to the official builds to search for papers.


Emmm, I know the new API of SAO/NASA ADS requires a token and I've used that...
Oh, I see. Thanks for keeping some tokens in the repo.

@Siedlerchr
Copy link
Member

Siedlerchr commented Mar 27, 2022

We have some for testing in the repo and some secrets are injected into the build info.
And the other thing is just signing + notarizing for osx

SpringerNatureAPIKey: ${{ secrets.SpringerNatureAPIKey }}
AstrophysicsDataSystemAPIKey: ${{ secrets.AstrophysicsDataSystemAPIKey }}
IEEEAPIKey: ${{ secrets.IEEEAPIKey }}

@liu-qilong
Copy link

@astroboylrx it would be great if you can share your builds.

Sure, I created a repo and shared my builds in the Releases.

Thanks indeed! I tried it a little bit and it seems really smoother!

@jangid19
Copy link

jangid19 commented Aug 25, 2022

@astroboylrx it would be great if you can share your builds.

Sure, I created a repo and shared my builds in the Releases.

Thanks a lot. Feels great to be rocking JabRef 100.0.0. 😆
Screen Shot 2022-08-25 at 1 18 19 AM

@brodmo
Copy link

brodmo commented Oct 4, 2022

Any updates on this? The .app I managed to build with ./gradlew jpackage doesn't work when using Java for ARM and I don't know why

@Siedlerchr
Copy link
Member

@mbrdl Hi, unfortunately Github still does not offer ARM VMs for building on CI and I neither have an ARM machine. But mabye soon.
Did you install the correct JDK 18 for arm? Otherwise ask @jangid19

@Siedlerchr
Copy link
Member

Good news at all, as I now have an M1 machine I was able to build the release packages for arm64 as well.
@JosephRedfern @jangid19 @mbrdl @astroboylrx

@Siedlerchr Siedlerchr moved this from Low priority to Normal priority in Features & Enhancements Dec 18, 2022
@krantisaran
Copy link

Any developments on how to get JabRef running on an M1? I managed to get it working on my desktop by installing it via brew, but no luck on my laptop.

@Siedlerchr
Copy link
Member

Siedlerchr commented Apr 1, 2023

@krantisaran The latest release is avaiable for m1 as well. works out of the box. We just had problems with the apple notraizatioh stuff, so ou have to execute xattr -d com.apple.quarantine /Applications/JabRef.app once

@krantisaran
Copy link

@Siedlerchr Thanks so much! We had a prior exchange on twitter but when I tried what you advised then I got an error message. Just installed jabref via brew and ran the command you mentioned and now it's working!! Thanks so much -- I've been stuck for months.

@astroboylrx
Copy link

To build the current version on Mac, you can just need JDK 17 https://adoptium.net/releases.html probably the aarch64 and Gradle. then just do ./gradlew run to build and start the app for the first time. You can also run ./gradlew jpackage . This will create the app under build/distribution It will just show version 100 as default.

Has anything changed for the compile procedure?
I have a Java Development Kit 19 and make JAVA_HOME pointing to this JDK. However, the build failed with:


> Configure project :
Project : => 'org.jabref' Java module

> Task :compileJava
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/Investigator.java:58: error: duplicate class: org.jabref.logic.importer.fileformat.medline.Investigator
public class Investigator {
       ^
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/MeshHeading.java:46: error: duplicate class: org.jabref.logic.importer.fileformat.medline.MeshHeading
public class MeshHeading {
       ^
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/ArticleId.java:41: error: duplicate class: org.jabref.logic.importer.fileformat.medline.ArticleId
public class ArticleId {
       ^
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/PersonalNameSubject.java:48: error: duplicate class: org.jabref.logic.importer.fileformat.medline.PersonalNameSubject
public class PersonalNameSubject {
       ^
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/ObjectFactory.java:416: error: constructor MeshHeading in record MeshHeading cannot be applied to given types;
        return new MeshHeading();
               ^
  required: String,List<String>
  found:    no arguments
  reason: actual and formal argument lists differ in length
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/ObjectFactory.java:448: error: constructor PersonalNameSubject in record PersonalNameSubject cannot be applied to given types;
        return new PersonalNameSubject();
               ^
  required: String,String
  found:    no arguments
  reason: actual and formal argument lists differ in length
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/ObjectFactory.java:496: error: constructor Investigator in record Investigator cannot be applied to given types;
        return new Investigator();
               ^
  required: String,String,List<String>
  found:    no arguments
  reason: actual and formal argument lists differ in length
/Users/rixin/opt/builds/jabref/src-gen/main/java/org/jabref/logic/importer/fileformat/medline/ObjectFactory.java:544: error: constructor ArticleId in record ArticleId cannot be applied to given types;
        return new ArticleId();
               ^
  required: String,String
  found:    no arguments
  reason: actual and formal argument lists differ in length
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
8 errors

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/8.0.2/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 3s
10 actionable tasks: 2 executed, 8 up-to-date

@Siedlerchr
Copy link
Member

Jdk 19 is sufficient. Just use a gradlew clean before. Then it should work

@calixtus calixtus added this to the v5.10 milestone Apr 24, 2023
@koppor koppor removed the status: depends-on-external A bug or issue that depends on an update of an external library label Jul 31, 2023
@koppor
Copy link
Member

koppor commented Jul 31, 2023

Notarization works again. Please wait for a release.

@koppor koppor self-assigned this Jul 31, 2023
@koppor
Copy link
Member

koppor commented Jul 31, 2023

Fixed by #10095

@eustomaqua
Copy link

#7175 (comment)

Sorry to ask, but I installed JDK17 according to this illustration, trying to fix the issue of "JabRef runs and responds slowly on M1/M2". However, I cannot run "./gradlew run"

[~]$ ./gradlew run
zsh: no such file or directory: ./gradlew

May I ask what I should to do to fix it or adjust so that JabRef could respond more timely, please? Thanks

@ThiloteE
Copy link
Member

ThiloteE commented Aug 26, 2023

That post is a little out of date. JabRef currently requires jdk 20 and for the next release, very likely a customized jdk 21 will be used that fixes "method too large" issues. So first install jdk20 and then try to use ./gradlew run or simply try the JabRef-5.10.dmg file from https://builds.jabref.org/main/, that I assume to also work for M1 now? - Is this correct @Siedlerchr?. Since this is a development version, please make sure to have a backup of your configuration/library file.

@Siedlerchr
Copy link
Member

You can use this version https://builds.jabref.org/renameArm64/ (development version from a couple of days ago)
The next release is coming soon and will feature arm64.
building yourself is a bit more complicated due to our custom jdk

@eustomaqua
Copy link

#7175 (comment)

Thank you so much! It seems work well now after re-installing jdk 20 and jabref-5.10
Just for the record, ./gradlew run seems not work as well. But I directly downloaded "JabRef-5.10.dmg" and installed it. Now using JabRef is smoother than ever

[~]$ java -version
openjdk version "20.0.2" 2023-07-18
OpenJDK Runtime Environment Temurin-20.0.2+9 (build 20.0.2+9)
OpenJDK 64-Bit Server VM Temurin-20.0.2+9 (build 20.0.2+9, mixed mode)
[~]$ ./gradlew run
zsh: no such file or directory: ./gradlew

@koppor
Copy link
Member

koppor commented Aug 28, 2023

Will be part of the next release. Development builds available at https://builds.jabref.org/main/.

image

@koppor koppor closed this as completed Aug 28, 2023
@github-project-automation github-project-automation bot moved this from Normal priority to Done in Features & Enhancements Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests