Support s390x for Red Hat Dev Spaces 3.x with VS Code running on Linux on Z

[phaumer]

Now that Red Hat Dev Spaces 3.3 make VS Code the default editor it would be important to support all the platforms on which Dev Spaces can run. Supporting Linux on Z with s390x is important for IBM z customers.

Environment

• Operating System: Linux on Z
• JDK version: 11 and up
• Visual Studio Code version: 1.53.2 and up
• Java extension version: 1.14.2022121311

Steps To Reproduce

1. Deploy Dev Spaces on OpenShift for Linux on Z and start a Java workspace
2. Search for Java in the Extensions view: it is greyed out

[Please attach a sample project reproducing the error]
Please attach logs

Current Result

Expected Result

Works With should list Linux s390x

Additional Informations

[azatsarynnyy]

Just for the record: the downstream DevSpaces issue.

[rgrunber]

Some background : What makes vscode-java platform specific, is that we provide a JRE 17 from https://www.eclipse.org/justj/?page=download/index.html . Currently this is supported on win32-x64, linux-x64, linux-arm64, darwin-x64, darwin-arm64 . For all other platforms that the marketplace supports, we publish an extension that just doesn't contain a JRE and just attempts to discover a compatible one on the system.

The limitation is currently the marketplace (VS Code Marketplace & Open VSX). According to https://code.visualstudio.com/api/working-with-extensions/publishing-extension :

The currently available platforms are: win32-x64, win32-ia32, win32-arm64, linux-x64, linux-arm64, linux-armhf, alpine-x64, alpine-arm64, darwin-x64 and darwin-arm64.

So we can't publish for IBM Power / Z because they aren't supported. There is a universal extension that we still "publish" at https://github.com/redhat-developer/vscode-java/releases/tag/v1.13.0 (specifically https://github.com/redhat-developer/vscode-java/releases/download/v1.13.0/[email protected]). It's the same thing we use on the platforms where we don't ship a JRE (eg. win32-ia32). I think if one were to use that, it should work.

[phaumer]

Thanks @rgrunber. Can that be published on Open-VSX? It could be under a different name perhaps? I think including a JRE is not needed as most people want to use the exact same version that they use in production. Also the OpenJDK for s390x is not useful, performance-wise, as it runs in mixed-mode by default. We are replacing it with IBM Semeru on our images.

[rgrunber]

@filiptronicek , I noticed you're a contributor to Open VSX, and you helped us get pre-releases/platform-specific extensions published there. Is there a way we could support an unsupported platform on Open VSX using the "universal" platform in some way (ie. use it as a fallback) ? I always thought once a switch is made to platform-specific publishing, the "universal" vsix is completely ignored. If it can't be supported this way, do you know how likely it would be to have Open VSX add support for IBM Power / IBM Z if a request were made ?

[filiptronicek]

Hey all,
to make this as simple as can be, the best approach would be to publish a Universal release of the extension version. The universal release is secondary in the compatibility check, hence can be used as a fallback for all "other" platforms. That should work with Linux on Z, and should be the same in the Microsoft Marketplace as in Open VSX - if you don't care for the integrated JRE there, the better.

The "clean way" would of course be to add the platform to the target platform list, but sadly this has to be done not just in Open VSX, but also in https://github.com/microsoft/vscode [1] for VS Code to actually be able to interpret the version that it wants to get from the marketplace.

cc @rgrunber @phaumer

[rgrunber]

Hey all, to make this as simple as can be, the best approach would be to publish a Universal release of the extension version. The universal release is secondary in the compatibility check, hence can be used as a fallback for all "other" platforms. That should work with Linux on Z, and should be the same in the Microsoft Marketplace as in Open VSX - if you don't care for the integrated JRE there, the better.

That's great! So to publish a universal vsix (as a fallback for unsupported platforms, on Open VSX, at least), it's just ovsx publish -p ... --target universal ? I think that would be good enough if so.

[filiptronicek]

That's great! So to publish a universal vsix (as a fallback for unsupported platforms, on Open VSX, at least), it's just ovsx publish -p ... --target universal ? I think that would be good enough if so.

It's only important that the .vsix package itself is targeted for the universal platform. It is always the default, so no need to specify --target in ovsx publish (should work anyway, though).

[rgrunber]

Right, because vsce package (or ovsx) can take a --target also. We specify it there for platforms where the vsix would differ (different JRE embedded). We use --target on vsce publish for platforms where the universal vsix is used, mainly for convenience. It's possible to provide multiple targets to --target, as opposed to manually packaging the same vsix a few different times.

Ok so just adding an extra vsce/ovsx publish, at the end, with no --target is the way. CC'ing @CsCherrYY for awareness, in case any of this is very ovsx-specific and somehow vsce doesn't support it. I know when we first started publishing platform-specific stuff on the VS Code Marketplace, I got the impression there was no going back to using a "universal" vsix, and everything from then on had to be targeted.

[filiptronicek]

in case any of this is very ovsx-specific and somehow vsce doesn't support it

We try to keep ovsx as close to vsce as possible, so if you find some inconsistencies please let me know 🙂. This should all be the same for both

[CsCherrYY]

see: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions

When publishing platform-specific extensions, a separate package needs to be published for every platform that has platform-specific content. You can still publish a package without the --target flag and that package will be used as a fallback for all platforms for which there is no specific platform-specific package.

So IMO it's OK to use no --target to publish a general version.

[rgrunber]

@phaumer, v1.14.2023011609 should be the first pre-release with this build change included. Can you verify on a Z system, that both VS Code Marketplace & Open VSX can install this pre-release ? I would think the "Install Pre-release" should be available from the "Install" button drop down option when the vscode-java extension's page is opened from the Extensions tab.

If it works, 1.14.0 will be the first release to support this, but we're aiming to release that tomorrow.

[rgrunber]

I tried to simulate an unknown platform with a local build and if I check the Java extension I see :

The only pre-release is the most recent one and the most recent release version is 1.1.0, which was the last one where we shipped a generic version. So it looks like the change should work going forward.

[phaumer]

@rgrunber thanks!
I manually downloaded the universal extension from open-vsx and uploaded into a workspace (that was running Dev Spaces 3.3 on Linux on Z) with the Java-Gradle workspace using the UDI. I was able to install it with a right-click and things look great.

I also tried with a workspace that uses one of our own images that only has Java 11 and here the extension did not activate complaining that it could not find a JRE 17 or higher. I guess you need to add that prereq to your Readme now as the statement "Download and install a Java Development Kit for your project (Java 1.5 or above is supported)" could be confusing as it does only apply to the development JDK, but not the requirement for running the universal vsix.

[rgrunber]

You mean https://github.com/redhat-developer/vscode-java#quick-start ? It refers to the JDK to be used by the project, not the one used by extension to start up. If you look below it under Features, you'll see we mention "Supports code from 1.5 to Java 19".

We have an explanation on the Java 17 requirement at https://github.com/redhat-developer/vscode-java/wiki/JDK-Requirements#about-the-java-17-requirement , though maybe we could link to it in the README.

[phaumer]

@rgrunber "Supports code from 1.5 to Java 19" is exactly the confusing part. It needs to say "The universal VS Code extension requires Java 17 to run, but it can then support parsing code from 1.5 to Java 19".