I’ve just recently started using lift on a project that is using Java 16 with specific language features that were introduced in this version, and I noticed in the configuration documentation this line where it says jdk11: A boolean field indicating use of OpenJDK11 instead of OpenJDK8 that seems to mean that Java 8 is used by default, and you can optionally opt in to using Java 11. However, there isn’t any option for Java 12+ versions. As a result, I get the below section in the lift build logs:
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 1.8.0-292 is not in the allowed range [16.0,).
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVendor warned with message:
Private Build is not an included Required Java Vendor
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.RequireMavenVersion warned with message:
Detected Maven Version: 3.6.3 is not in the allowed range [3.8.1,).
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Skipping TestApp
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.571 s
[INFO] Finished at: 2021-09-10T23:55:53Z
[INFO] ------------------------------------------------------------------------
I am using the default Java 8 implementation in lift, and my project requires Java 16, but it would fail anyways with Java 11. Also, I have the maven enforcer plugin with some rules set to check for vendor and version requirements of Java, which are where those extra messages in the output are coming from. With all this said, lift does scan my project code and will successfully detect issues if there are issues.
My question is, will lift now or in the near feature support more recent versions of Java like the upcoming Java 17 LTS?
Thanks for the report. Indeed, we don’t currently have a Java 16 build environment included on the Lift platform. I’ll make sure this is captured as a feature request.
Thanks, maybe it would be better to do it for Java 17 LTS, which releases this month I think, as this is a long term release like 8 and 11. This is a better idea if every release version can’t be supported because most companies will likely only use LTS versions.
I’ve been trying to make a pretty simple maven project work in Lift using JDK 11. Whenever it runs, however, I get "Lift was unable to use your project’s build system to produce a compilation database. " for multiple Tools (ErrorProne, FindSecBugs, Infer).
My .lift.toml file currently only has jdk11 = true. I previously tried various “build” settings but none worked, e.g. build = "mvn -B compile"
Looking at the logs I see this error several times:
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project ansible-vault-experimental: Fatal error compiling: invalid flag: --release → [Help 1]
My guess is this is because I am using the <release> tag in the maven-compiler-plugin, which is the correct configuration to use on JDK 9 and beyond, but I suspect that maybe Lift is actually running the Maven build using JDK 8 – but I’m not sure. In any case, GitHub actions have no problems building the code using Maven and JDK 11, and the project builds fine locally on my workstation, laptop, etc.
Here’s a link to the PR I created in one of my repositories to try Lift out:
Note that one of the results (it says “6 New issues discovered”) actually ran FindSecBugs and Infer successfully when I (temporarily) changed the POM to use the older (pre-Java 9) <source> and <target> tags instead of <release> in the maven compiler plugin configuration. But ErrorProne still failed due to class file versions conflicts with several of the libraries.
Hi @scottleber, it appears the location of your config file inside of the src directory is causing those settings to not be applied to your build. Lift will find each directory with a .lift.toml or .lift/config.toml file and treat that as a unique project directory and trying to build from there. If you move your config to the root it should work for you.
Great to hear! Java 17, the next LTS, released a month ago. Are there plans to support Java 17 instead of Java 16? I have a few projects I’m going to update soon, but I would like to keep Lift up.
@scottleber Sorry we missed your last message. We’re currently working on fixing the ErrorProne issue when working with JDK11. You should see an improvement by the end of this week, if not reach out and we’ll take another look.
@NotMyFault We have work scheduled to add support for JDK17 but haven’t started it yet. That will likely land early 2022. We are also going to improve the configuration so that JDK selection isn’t a boolean.
Works perfectly now with Java 17, thanks. I did see that the flavor of Java used is called “Private Build”. Is this based on any project like Azul or Adoptium?
@stevenjdh Where did you see “Private Build”? The Java17 we run is OpenJDK 17, if anything about it is behaving in an unexpected then we’ll be happy to take a look.
The minor versions might be different, but what the analysis runs should be as new or newer than the below.
$ java -version
openjdk version "17.0.3" 2022-04-19
OpenJDK Runtime Environment (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1)
OpenJDK 64-Bit Server VM (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)
$ javac -version
javac 17.0.3
In the build logs of lift. I use a maven enforcer plugin with my builds that will report any flavors not whitelisted, and Private Build is what it found as the name, which you can see below. This could be what the Ubuntu version of OpenJDK is set use. I don’t see any issues, it was just something curious I noticed as I haven’t encountered this before.
