Raise minimum JDK version to 17

[J-N-K]

• Raise source/target level to 17 (except model classes due to missing support in Xtext https://github.com/eclipse/xtext/issues/1982)
• Remove Nashorn scripting engine
• Bump spotless to allow newer language features (requires JVM options due to https://github.com/diffplug/spotless/issues/834)

Signed-off-by: Jan N. Klug [email protected]

[J-N-K]

I agree with all the other points, but I would prefer to have separate PR for that (at least for OSGi and #2805). Nashorn is related to the Java 17 upgrade and should go here.

[dilyanpalauzov]

Provided that the JS-Transformation requires Nashorn, how will it work on JDK 17?

[J-N-K]

I guess installing the Nashorn add-on would work. But you could also switch to the new SCRIPT transformation and use whatever scripting language is available on your system, even DSL.

[andrewfg]

I am working on a binding where JDK v16 plus would improve the code greatly. => Can you advise when this PR might merge, so I can plan the coding better?

[wborn]

I think that a mid 2023 release of OH 4 using Java 17 (see discussion) means that this may get merged after OH 3.4 is released in December 2022.

[J-N-K]

I also had a look at upgrading Karaf to 4.4 and it seems to be quite challenging to due to a lot of dependency upgrades.

[wborn]

Yes Karaf 4 is a challenging upgrade. I also had a look a this in July and due to the Pax Web upgrade a lot of servlet logic needs to be reworked. IIRC I got most of it working except for servlets created by add-ons. Probably due to https://github.com/openhab/openhab-webui/pull/1521 some more rework is needed now too.

[J-N-K]

Hooray! With XText 2.29.0 we don't need a different java version for the model anymore.

[J-N-K]

We need to upload https://download.eclipse.org/tools/orbit/downloads/drops/R20221123021534/repository/plugins/io.github.classgraph_4.8.149.v20220915-0556.jar to the openhab-repo to make this work.

[J-N-K]

@kaikreuzer Can you take care of the upload? It would be great if we could get this merged soon after the release so that I can fix the other PR between Christmas and New Year.

[J-N-K]

I downgraded ecj to 3.30.0 because later versions spam the log with

Failed to init Classpath for jar file /Users/jan/Documents/git/openhab-core/bom/compile/pom.xml
java.util.zip.ZipException: zip END header not found
	at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1469)
	at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1477)
	at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1315)
	at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1277)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:709)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:243)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:186)
	at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:204)
	at org.eclipse.jdt.internal.compiler.batch.FileSystem.<init>(FileSystem.java:235)
	at org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3495)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4741)
	at org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.call(EclipseCompilerImpl.java:101)
	at org.eclipse.jdt.internal.compiler.tool.EclipseCompiler$1.call(EclipseCompiler.java:196)
	at org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler.performCompile(EclipseJavaCompiler.java:351)
	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1209)
	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:198)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:960)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

which is obviously correct (because a .pom is not a ZIP file), but not useful (even though compilation does not fail). I checked that the dependency is correctly declared as type pom, so I assume it's an issue in ECJ.

[J-N-K]

Additionally someone need to re-configure Jenkins so use Java 11 instead of Java 17.

[J-N-K]

@wborn Can you upload to the artifactory?

[wborn]

No, that's why I always ask @kaikreuzer to do that. :wink:

[kaikreuzer]

@kaikreuzer Can you take care of the upload?

Done!

[wborn]

I've updated the Jenkins CI/PR jobs to use Java 17. The release/sandbox builds probably still need to be reconfigured.

Some jobs may also need a new name:

• openHAB3-Distribution
• sandbox-openhab3-release

[wborn]

Done!

It's still failing and it seems to have gotten the wrong version @kaikreuzer, see:

https://openhab.jfrog.io/ui/native/libs-release/org/eclipse/orbit/bundles/io.github.classgraph/

[kaikreuzer]

it seems to have gotten the wrong version

Probably depends on what you claim the version is. If you look at the pom.xml within the jar, it says it is version 4.8.149-SNAPSHOT - and this is what Artifactory then automatically used to put it into the repo: https://openhab.jfrog.io/ui/native/libs-release/org/eclipse/orbit/bundles/io.github.classgraph/4.8.149-SNAPSHOT/

But since we are expected to only use release versions, I guess we simply pretend that this is release version 4.8.149-20221219.163231-1?

[J-N-K]

Maybe look at what was in the artifactory before. The old version had the same naming scheme.

[kaikreuzer]

Ok, now we have https://openhab.jfrog.io/ui/native/libs-release/org/eclipse/orbit/bundles/io.github.classgraph/4.8.149.v20220915-0556/

[J-N-K]

@kaikreuzer I probably know what the issue is: The file is named io.github.classgraph_4.8.149.v20220915-0556.jar, but it needs to be io.github.classgraph-4.8.149.v20220915-0556.jar (dash instead of underscore before version).

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-4-release-discussion/142257/50