Support for JDK 11

[JoelProminic]

@joshtynjala added some logic for #742 to require JDK 11+ for the language server on Java Projects. However, SDK Installer is currently installing JDK 8, and I am not sure if all of the other projects will support JDK.

I think we want to avoid bundling the Oracle JDK 11 installation with Moonshine, because it does require a license for commercial applications. We could use either Open JDK or AdoptOpenJDK instead.

I did some quick tests and I see that the Java Maven and Gradle projects on macOS report this error when opening with AdoptOpenJDK 11.

: Error #1009
: TypeError: Error #1009
: 	at actionScripts.languageServer::JavaLanguageServerManager/extractVersionStringFromStandardErrorOutput()
: 	at actionScripts.languageServer::JavaLanguageServerManager/javaVersionProcess_exitHandler()

@piotrzarzycki21 reported that the Payara server we use for Primefaces Visual Editor projects has a dependency on Java 8, though this may be fixed now:

: Nov 25, 2020 5:53:57 PM net.prominic.PayaraEmbeddedLauncher main
: SEVERE: null
: org.glassfish.embeddable.GlassFishException: Exception while executing command.
: 	at com.sun.enterprise.glassfish.bootstrap.ConfiguratorImpl.configure(ConfiguratorImpl.java:75)
: 	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.configure(GlassFishImpl.java:75)
: 	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.<init>(GlassFishImpl.java:69)
: 	at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1.<init>(StaticGlassFishRuntime.java:112)
: 	at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:112)
: 	at net.prominic.PayaraEmbeddedLauncher.main(PayaraEmbeddedLauncher.java:38)

We need to do some more testing and investigation to confirm what we would need to do to support JDK 11 (or higher) as the default JDK for Moonshine.

[joshtynjala]

I did some quick tests and I see that the Java Maven and Gradle projects on macOS report this error when opening with AdoptOpenJDK 11.

@JoelProminic Can you run java -version in a terminal and copy/paste the output here? Thanks!

I actually tested with AdoptOpenJDK 11 on macOS too, so I'm curious if you ended up with a different build that reports a differently formatted version number.

[piotrzarzycki21]

Guys the only dependency on Java 8 which we have is Payara which we are using to Preview PrimeFaces Visual Editor stuff in the browser. I just did an upgrade, cause they claim on some blog that support for Java 11 has been added. It's working perfectly. In my opinion we can switch in SDK Installer to Java 11.

[JoelProminic]

@joshtynjala, here is the full version information for the AdoptOpenJDK build I am using. I am iusing the Hotspot JVM instead of OpenJ9.

$ /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java -version
openjdk version "11.0.9.1" 2020-11-04
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)

I tried this again, and I still see this error for each Java project:

: TypeError: Error #1009
: 	at actionScripts.languageServer::JavaLanguageServerManager/extractVersionStringFromStandardErrorOutput()
: 	at actionScripts.languageServer::JavaLanguageServerManager/javaVersionProcess_exitHandler()
:
: Click here to Report a Bug

[joshtynjala]

Thank you! That's exactly what I needed. I looks like the version number can optionally have four parts (like 11.0.9.1), which contradicts Oracle's Java documentation. I just found another document, specifically for OpenJDK, where I see that they allow four or more version parts. I'll update my version checking code to take that into account.

[joshtynjala]

@JoelProminic I've updated the Java version number parsing. Does that work for you?

[JoelProminic]

I can run Java Maven and Gradle projects now.

For future reference, I got this error for an old Java Gradle project:

: Dec 7, 2020, 3:53:07 PM Error occured while building workspace. Details: 
:  message: The project cannot be built until build path errors are resolved; code: 0; resource: /Users/-user-/Documents/Flex/temp_workspace/TestJavaGradle_JDK11;
:  message: Unbound classpath container: 'JRE System Library [JavaSE-15]' in project 'TestJavaGradle_JDK11'; code: 963; resource: /Users/-user-/Documents/Flex/temp_workspace/TestJavaGradle_JDK11;

After some investigation, I found that the Gradle daemon was running with Java 15 for this project, and the eclipse configuration files had references to Java 15. I must have created this project when testing OpenJDK 15.

I resolved this by running the eclipse Gradle command from Moonshine.

TODO on this issue:

• Test AdoptOpenJDK 11 (and Open JDK) with all project types
• Update Moonshine SDK Installer to intall JDK 11 (if there are no problems with the other projects).

[piotrzarzycki21]

@joshtynjala whenever I open Flex Air Desktop App - I'm getting following error:

 Error #1009
: TypeError: Error #1009
: 	at actionScripts.languageServer::ActionScriptLanguageServerManager/extractVersionStringFromStandardErrorOutput()
: 	at actionScripts.languageServer::ActionScriptLanguageServerManager/javaVersionProcess_exitHandler()
:
: Click here to Report a Bug

I'm using Open JDK 11

[joshtynjala]

@piotrzarzycki21 I can see where there might be a null exception. My latest commit should fix that.

[piotrzarzycki21]

@joshtynjala It helped to see something different than previous information. I see now, when I open Adobe Air Flex project

Java version 8 or newer is required. Version not supported: Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m -Xmx2g
: openjdk version "11" 2018-09-25
: OpenJDK Runtime Environment 18.9 (build 11+28)
: OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode). ActionScript & MXML code intelligence disabled for project: NewFlexDesktopProject.

[joshtynjala]

Oh wow, so there might not even be a minor version!

[piotrzarzycki21]

Yeah! It looks like openjdk provides it's version without minor ;) If you can fix that quickly would be good - if not I will get back to previous version of Moonshine, cause right now code intelligence won't work, unless I change java ;)

[joshtynjala]

@piotrzarzycki21 My latest commit should allow the minor part of the version to be optional!

[piotrzarzycki21]

@piotrzarzycki21 I can see where there might be a null exception. My latest commit should fix that.

It's working now Josh! Thank you!

[rat-moonshine]

If we finalize with AdoptOpenJDK11, based on the existing download URLs, this location we can use for pointing a download build - https://github.com/AdoptOpenJDK/openjdk11-binaries/releases.

[piotrzarzycki21]

One of the possible idea to do not run into an issue where JDK 8 is needed would be have two entries (JDK 8 and 11) in Moonshine SDK Installer.

[piotrzarzycki21]

It would also leads to split settings into two entry:

JDK main one and JDK for Language Server.

[rat-moonshine]

It would also leads to split settings into two entry:

JDK main one and JDK for Language Server.

From a user perspective, this would create confusion. Moreover, if I would be that user, it'd be annoying (and doubtful) for me to install multiple JDKs even if provided through the MSDKI.

[JoelProminic]

I need to revisit my project that requires JDK 8 to see if I can make it work with Java 11. If I still have problems, I'll write up the use case for this issue so that we can discuss our options for supporting older projects.

[rat-moonshine]

If we finalize with AdoptOpenJDK11, based on the existing download URLs, this location we can use for pointing a download build - https://github.com/AdoptOpenJDK/openjdk11-binaries/releases.

Unfortunately, the link contains all the pre-release entries, and I don't see any zip/tar.gz version of complete binary distribution as we can found for OpenJDK 8.

[joshtynjala]

Yes, as I understand it, setting the source/target values in pom.xml/build.gradle should change which JDK class paths are used by the language server. The most obvious place to test the language server changes, where you should see a difference in Moonshine after you change the source/target compatibility values and the JDK paths, is probably by which errors/warnings appear in the Problems view.

The error messages that you quoted appear to come from the console output of build commands. The language server does not handle building projects, and I have not changed the build process to use JDK 8. I was assuming that @rat-moonshine was working on that part, but I can look into it if, you think I'd be best suited for that task. For Java builds, I think Moonshine runs either gradle or mvn in a shell, depending on the Java project type. I don't actually know how to tell gradle or mvn to use a specific JDK. Maybe by changing the JAVA_HOME environment variable to a different value?

[JoelProminic]

Yeah, changing JAVA_HOME will control which JDK Maven or Gradle use. This is already implemented in @rat-moonshine's changes. I expected that this would also need to be changed for the language server environment, but maybe I am misunderstanding your solution.

[joshtynjala]

I tried adding the above settings to the example projects and building with JDK 11, but it still gave errors for the missing CORBA dependencies

Wait... isn't that the expected behavior? Why are you trying to build them with JDK 11? These Domino API projects need to be built with JDK 8, right?

I downloaded 2021_03_26__TestJavaMaven_Domino.zip and imported it into Moonshine running from the features/issue_38_jdk11 branch. On my machine, when I set the JDK type to 8, it is successfully building with Ctrl+B (to be clear, I should mention again that this build command has nothing to do with the language server). The build fails with the Default JDK (11 on my machine) selected, which is what I would expect.

Additionally, I see errors in the problems view as reported by the language server when I first open the project. That's expected, and after I add maven.compiler.target and maven.compiler.source to pom.xml, the errors in the Problems view are resolved.

[JoelProminic]

Yes, I expected the build to fail with JDK 11 even with those compliance settings. I was expecting the language server to get similar errors, but maybe that will not be a problem unless I try to use the classes with a dependency on CORBA. It is a good sign if the compliance settings clear all the Problems with my test projects - I expected an error for at least NotesException.

I did a quick test with JDK 8 and the compliance settings and confirmed that they did not interfere with my normal build.

Some options to set the compliance options for Java Maven/Gradle projects:

• Add documentation to remind users to add these settings when working with JDK 8 projects
• Set this option for any templates we make that require JDK 8 (i.e. DXL Importer Project for Domino Agent Support #668)
• Automatically add or remove these lines when choosing between "Default JDK" and "JDK 8". This would make sense with how we have implemented JDK 8 support, but we would need to be careful with any existing compliance settings that the user added.

[rat-moonshine]

One more thing: Is there an event dispatched on the global dispatcher when java8Path is updated? I couldn't find one.

FilePluginEvent.EVENT_JAVA_TYPEAHEAD_PATH_SAVE is dispatched when javaPathForTypeahead is updated. We currently automatically restart the Java language server when javaPathForTypeahead changes. We should do the same when java8Path changes too.

As we have Java8SettingsProvider for Java.8, I see a said event dispatch is comment-out. I don't remember now why I did so. Restoring this event will meet the needs?

The modified event should use model.java8Path instead of model.javaPathForTypeAhead as its parameter. Maybe, I just forgot to restore this event since model.java8Path wasn't available at that time.

[rat-moonshine]

I was assuming that @rat-moonshine was working on that part, but I can look into it if, you think I'd be best suited for that task.

For build plugins, including Gradle and Grails, I only ensured that correct JAVA_PATH is set (during a build) by temp-environment-util based on the project's own settings. Glimpse of those changes are at here: 352bcda.

[joshtynjala]

As we have Java8SettingsProvider for Java.8, I see a said event dispatch is comment-out. I don't remember now why I did so. Restoring this event will meet the needs?

@rat-moonshine Yes, either restoring the event or creating a new event would be fine.

[rat-moonshine]

Okay. I have restored by the same event with Java.8 path information. Please, check.

[joshtynjala]

Alright, then. Language server changes seem to be good to go.

[JoelProminic]

I tried the new build. I found that it worked well for the example *_Domino projects I attached above, as long as I added the compatibility lines.

However, when I test with my "real" projects, I'm getting errors like this on the console when the language server starts:

:  message: The project was not built since its build path is incomplete. Cannot find the class file for org.omg.CORBA.UserException. Fix the build path then try building this project; code: 0; resource: /Users/-user-/Documents/Flex/workspace/DominoServerProcessor;
:  message: The type org.omg.CORBA.UserException cannot be resolved. It is indirectly referenced from required .class files; code: 16777540; resource: /Users/-user-/Documents/Flex/workspace/DominoServerProcessor/src/net/prominic/domino/report/GroupDocIdentifier.java; line: 1

I can't share this project since it has some Prominic-specific information. I don't see anything special about the GroupDocIdentifier class, so I think this might be one of many errors in the current state. I'll investigate this further and let you know if I can reproduce this error with a smaller project.

[piotrzarzycki21]

@JoelProminic If you won't have time to look into that more I would like to ask @rat-moonshine for merge these branch along with branch from SDK Installer. I will use stuff daily and see what is happening.

[JoelProminic]

Yes, I'm fine with merging this branch. It seems to be working for this project at least. I don't think anyone besides me is doing practical work with Java in Moonshine, but it will be good to confirm it isn't breaking anything for other projects.

[rat-moonshine]

Both the Moonshine and Moonshine-SDK-Installer JDK.11 branch now merged into 'master'.

[piotrzarzycki21]

@rat-moonshine I see that Moonshine build correctly on Bamboo, but Nightly of SDK Installer is probably failing - could you check that ?

[rat-moonshine]

@rat-moonshine I see that Moonshine build correctly on Bamboo, but Nightly of SDK Installer is probably failing - could you check that ?

Okay, i will.

[rat-moonshine]

@rat-moonshine I see that Moonshine build correctly on Bamboo, but Nightly of SDK Installer is probably failing - could you check that ?

Okay, i will.

I see when I re-run the build, it completed successfully. I'm not sure why the macOS build failed earlier with plist error.

[piotrzarzycki21]

I just tried SDK installer and was able to install Java 11 without the problem. I see it has been setup in Moonshine as well.

[JoelProminic]

I see some remaining errors for OpenJDK 8 in the Moonshine settings:

1. Install and configure OpenJDK 8 with the latest master build (I tested with 1910 on macOS and 416 on Windows)
2. Open Help > About. BUG: OpenJDK 8 shows "Not Installed."
3. Click the "Fix this" link for OpenJDK 8. This opens the Getting Started tab with By Feature
4. Scroll to the bottom and find the OpenJDK 8 entry for the Domino feature.
5. Click the gear. BUG: the settings tab doesn't open
6. Manually open the settings and choose the Default tab. Confirm that the OpenJDK 8 path is set and valid.

[rat-moonshine]

I see some remaining errors for OpenJDK 8 in the Moonshine settings:

1. Install and configure OpenJDK 8 with the latest master build (I tested with 1910 on macOS and 416 on Windows)
2. Open Help > About. BUG: OpenJDK 8 shows "Not Installed."
3. Click the "Fix this" link for OpenJDK 8. This opens the Getting Started tab with By Feature
4. Scroll to the bottom and find the OpenJDK 8 entry for the Domino feature.
5. Click the gear. BUG: the settings tab doesn't open
6. Manually open the settings and choose the Default tab. Confirm that the OpenJDK 8 path is set and valid.

This be fixed now. Please check.

[piotrzarzycki21]

I'm closing this issue. We have been tested this for several weeks now.