Java runtime support changing to require v11 in Q4

[phaumer]

Dear community.
As you know Z Open Editor uses powerful parsers for the latest version for COBOL, PL/I, HLASM and REXX that have been implemented in Java and are shared across several editor offerings provided by IBM. To be able to support the latest editor platforms (Eclipse Java SDKs) and editor runtime configurations (Red Hat OpenShift Dev Spaces with UDI) we decided that we need to move our Java requirement up to at least version 11 now. We waited as long as we could, but now that Java 11 also runs on z/OS it is time to move up.

We do see in our telemetry that around 35% of our users are still running with Java 8 right now, but we hope that the upgrade will be an easy one. The current version of Z Open Editor 2, that is available right now, fully supports Java 11 as well as 17. So you can switch right away and do not have to wait for our next major version update that will require it. It is expected to arrive in early 4th quarter.

Also see our formal announcement here: https://www.ibm.com/support/pages/node/6611949

[YvesMichon]

Hi,
Can't you bundle java runtime within the plugin ? It wil be independant of the version installed on the computer ?
It's not so easy to change Java version. It's very dependant with other enterprise software that have not plan to change Java version in Q4 !

[phaumer]

Thanks for the feedback @YvesMichon.

We can recommend that users install VS Code with the Java Runtime bundled as it is provided by Microsoft: https://code.visualstudio.com/docs/languages/java#_install-visual-studio-code-for-java

As we are just a VS Code extension we do not want to run any code that would make modification to someones workstation. I think we would get into trouble for that from a security point of view.

We see that other VS Code extensions such as Red Hat's Java extension does download Java "locally" into their extension directory the first time a Java program is opened, but we think that is a bad user experience, because (a) the download can take minutes without any good progress report and user might think that the extension just does not work and (b) every time there is an update to the extension it gets reinstalled in the VS Code extensions folder clearing that Java download and the whole thing needs to be downloaded again.

[phaumer]

Oh, one more thought: You do not have to make the new Java the default Java on your machine. If you are allowed, then you could just download a Java package as a zip or tar file from here: https://developer.ibm.com/languages/java/semeru-runtimes/downloads and unzip it somewhere in your home directory without running any installers. You can then just use the Z Open Editor user setting called zopeneditor.JAVA_HOME to point to that unzipped folder.

I personally have many different java version all unzipped in a java folder and use that setting for testing. For example, on my Mac I use
"zopeneditor.JAVA_HOME": "/Users/phaumer/Dev/java/jdk-11.0.15+10-ibm/Contents/Home",
and my PC
"zopeneditor.JAVA_HOME": "C:\\IBM\\jdk-17+35",
right now.

[FALLAI-Denis]

Hi @phaumer , @YvesMichon

I am from the same company and same team as Yves.

In some companies, users are not allowed to install software themselves, or even download software from the Internet. Nor is it within their competence and responsibility to install software.

We need to implement a managed solution.

I propose to implement the following solution:

• develop a private extension that will embed the Java runtime of our choice, and which is compatible with all extensions requiring a Java runtime environment
• on startup, this extension will change all user settings variables of other "well-known" extensions we use that require a Java runtime, including Z Open Editor

To change Java runtime version, simply rebuild and redistribute the extension by embedding a new Java runtime.
And if it was necessary to have several Java runtime versions, then the extension could embed several Java runtimes.

This solution can be independent of any site context if we put the list of settings variables from other extensions as parameters.
It could thus be offered on the MarketPlace.

There may be a problem of priority to manage in the starting of the extensions... the extension carrying the Java runtime should start before the other extensions which need the Java runtime. I don't know if VS Code can handle this...

Does this solution seem to you to be viable and to be a good approach to the problem?

Extension name proposition: BYOJ, for Bring Your Own Java 😊

[phaumer]

That is a great idea, but just to be clear, our team will not attempt such an extension as bundling and re-shipping Java distributions is a legally very complicated activity.

As we never announced any future changes here before you can see that we are not taking this lightly and know that it is not easy for everyone to upgrade. Hence, we tried to warn people as early as we could.

[FALLAI-Denis]

We agree that it is not up to a software publisher to take charge of the development of the proposed extension, but this is clearly a user site issue.
We will study the feasibility of this development, possibly we will share it.

Thank you for your information on the upcoming changes, even if the deadline seems a bit short to me.
Others do not have the same thoughtfulness with their users.

[FALLAI-Denis]

@phaumer

For your information, we did it 😊.

Our private extension embeds one or more Java runtimes.