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

Eclipse IDE for Java Developers - Windows on ARM #597

Closed
daliasheasha opened this issue Sep 9, 2022 · 5 comments
Closed

Eclipse IDE for Java Developers - Windows on ARM #597

daliasheasha opened this issue Sep 9, 2022 · 5 comments

Comments

@daliasheasha
Copy link

Eclipse IDE for Java Developers is not available for Windows on ARM devices:
image

When I tried to run the Windows _86_64 version of Eclipse on a Surface Pro X device with the Microsoft Build of OpenJDK for ARM, I get the following error:
image

The Java Engineering Group at Microsoft would like to help get Eclipse to run on Surface Pro X. Is there anything our team can do to help produce an Eclipse distribution that is compatible with ARM devices running Windows?

@laeubi
Copy link
Contributor

laeubi commented Sep 10, 2022

Eclipse IDE for Java Developers is not available for Windows on ARM devices

There are two parts here:

  1. Eclipse includes native launcher artifacts compiled for each supported platform you can find them here: https://github.com/eclipse-equinox/equinox.binaries so one would need to create a suitable launcher package and port the code to ARM
  2. Eclipse uses SWT as its bridge to native widgets, here again, one needs to add a new binary module to make Eclipse (or any SWT application) run https://github.com/eclipse-platform/eclipse.platform.swt.binaries/tree/master/bundles

The Java Engineering Group at Microsoft would like to help get Eclipse to run on Surface Pro X. Is there anything our team can do to help produce an Eclipse distribution that is compatible with ARM devices running Windows?

If you are eager to help that is great, I think the best would be to download the code from the repository and see if/how that could be compiled for your target platform to get best integration. Beside that, we (the Eclipse Platform Team) would later on require a build-host of the Windows ARM Platform to build and run tests for the new Windows ARM Platform, and I don't know if Eclipse Foundation has such devices already, so if you could offer a Build-Node for that purpose that would be great.

@merks
Copy link
Contributor

merks commented Sep 10, 2022

The final packages that you are testing in your screen capture are produced by the EPP project:

https://projects.eclipse.org/projects/technology.packaging

The packages embed a JRE and the JustJ project would need to produce a Windows ARM JRE:

https://www.eclipse.org/justj/

This too would require a Windows ARM build host to drive the process as seen here:

https://ci.eclipse.org/justj/job/build-jres/

I think that would be relatively straightforward to make work...

To make the overall story complete, Oomph would need to provide installers using the platform's Windows ARM support and the JustJ Windows ARM JRE.

https://projects.eclipse.org/projects/tools.oomph

Given that there is a native fragment written in C in involved, and that I'm not sure if the existing compiled native fragment would work on ARM, that could be some non-trivial amount of work:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.jreinfo.win32.x86_64

@mickaelistria
Copy link
Contributor

I think the answers from @laeubi and @merks are exhaustive as to what needs to be done to support another architecture (win32/arm).
As for how to do that, you'll need to get in touch with the Eclipse JustJ project and this Eclipse Platform project to contribute the particular architecture support (it's usually mostly some build information to copy-paste and adapt from another architecture, eg win32/x86_64) and also get in touch with those projects and the Eclipse infra team to contribute a win32/ARM machine to the build farm, which would be used by projects in order to produce the native bits and also for testing. Then once the code and the build machines are available, we'll be able to configure the CI to have builds targeting this environment and upon success, to start promoting them wider to users by updating the promotion scripts and other websites.

@sravanlakkimsetti
Copy link
Member

From platform project, there are 4 different native components that needs to built on ARM

  1. Launcher (https://github.com/eclipse-equinox/equinox/tree/master/features/org.eclipse.equinox.executable.feature and https://github.com/eclipse-equinox/equinox.binaries)
  2. SWT (https://github.com/eclipse-platform/eclipse.platform.swt and https://github.com/eclipse-platform/eclipse.platform.swt.binaries)
  3. Core.net (https://github.com/eclipse-platform/eclipse.platform/tree/master/team/bundles)
  4. Filesystem and resources (https://github.com/eclipse-platform/eclipse.platform/tree/master/resources/bundles)

Out of these SWT is regularly build at least once a week, and Launcher once in 3 months.
Because of regular builds we would like to have arm build machine added to the build farm on https://ci.eclipse.org/releng.

For the code changes I am not expecting major changes other than building on arm processor(for linux we used arm machine, In case of Mac we used cross compiling facilities from Xcode using x86_64 machine).

Code repositories mentioned against each component at the top.

For JustJ project we will need to add arm machine to their build farm at https://ci.eclipse.org/justj. Probably could use the same machine added to platform's build farm.

For testing purposes we would need another machine attached to https://ci.eclipse.org/releng.

In a nutshell getting a build node with windows on arm64 would be starting point(this should be attached to https://ci.eclipse.org/releng and https://ci.eclipse.org/justj . Code change should be fairly straight forward.

@akurtakov akurtakov transferred this issue from eclipse-platform/eclipse.platform Sep 28, 2022
@akurtakov
Copy link
Member

I'm closing this one as duplicate of #577 where actual work has happened but is blocked by resources limitation. Even if we make cross compiling working (as the guy is trying) I don't think we should throw out bits that haven't seen at least basic smoke testing. That's why I say reason to not progress further for now is missing build/test machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants