Update to Java 11 as minimal Java version #1972

cdietrich · 2021-05-17T07:37:37Z

As Platform / JDT and other Dependencies like LSP4J move to Java 11+ only we will have to follow one day.

Questions to the community:

any arguments/reasons to still support Java 8
which minimal Eclipse Target version do you need? Phonto, 2019-x 2020-x 2021-x

ewillink · 2021-05-17T12:12:05Z

Yes. One day. But Java 8 is a LTS version that remains valid until 2030, so I see no imperative to lose support for Java 8 users.

Since Xtext is useable in a standalone context, the rush to Java 11 by the platform does not need to be emulated by the Xtext runtime.

I see no reason why an Xtext-based parser/serializer should not run on Java 8.

cdietrich · 2021-05-17T12:14:25Z

the problem is here platform and lsp4j rushing.
so i have no clue on how to use newer platform/jdt maven dependcies (e.g. to support java 17 in fall) and lsp4j that need java 11 at the same keeping the java 8 on Xtext side. do you have any proposals or ideas @ewillink

ewillink · 2021-05-21T07:17:39Z

There are two separate issues.

a) The minimum Java version that you must use to develop. The platform pretty much mandates Java 11.

b) The minimum Java version that a standalone user must use to run. For EMF its still Java 5. For much of modeling it has crept to Java 8.

Provided you continue to specify a Java 8 BREE in plugins useable standalone , the Java compiler will ensure that Java 8 class files are produced.

For OCL builds Java 8 tooling was used for many years only recently changing to Java 11, but no BREEs were changed so the Classic OCL builds are successfully tested every week against a Java 5 installation, and the Pivot/Xtext-based OCL builds are successfully compatibility tested against Java 8/11 as appropriate for the Eclipse platform under test.

My understanding is that you may use source Java >=N language constructs and still have target Java N class files. You may not however use Java > N APIs. cf the bugs raised against EMF / QVTo for using the Java 6 String.length() method while claiming a Java 5 BREE.

cdietrich · 2021-05-21T07:18:42Z

the problem is: i have nobody to help me with that tooling stuff.

ewillink · 2021-05-21T07:23:34Z

You don't need to do anything. Just don't change the existing BREEs and so don't break the existing users. Just install and use a newer Java JVM if that's what you need.

Take no notice of the new inadequate BREE warning; a Bugzilla is pending to tame its enthusiasm.

(I can't see how to subscribe to this thread.)

cdietrich · 2021-05-21T07:25:48Z

we use gradle, maven and tycho. it needs to hild true for all of these.
it also needs to hold true for maven/gradle dependencies to platform and jdt and lsp4j

ewillink · 2021-05-21T07:36:56Z

I have a simplistic view. Xtext is currently not broken.

If you have time to make Xtext 'better' then it should not result in Xtext being broken for existing usage.

cdietrich · 2021-05-21T07:37:57Z

so you will never update to Java 17 then?

ewillink · 2021-05-21T08:33:28Z

Java moves so fast that I certainly no longer chase it. From what I see Java > 8 gives my code nothing that I need and through modules gives me endless things that break. While some of the new constructs are tantalizing, as soon as you see them in a debugger they just don't work. cf Xtend which has nice enhancements that are hard to support in debugger / refactor / ... tooling. NB Java 8 is LTS till 2030.

However I will check that OCL releases are useable with Java 17 by selecting Java 17 occasionally for a Jenkins build, and perhaps permanently if e.g. Eclipse 4.23 / Tycho 3.5 mandates it.

dhuebner · 2021-05-21T08:49:44Z

I think there are any technical reasons to start compiling against Java > 8. What I could imagine is that we need to switch to a library that uses newer Java Types in there public API (that are not part of Java8).
AFAIK eclipse jdt still provides compatibility / compliance level down to java 1.3

cdietrich · 2021-05-21T08:53:03Z

yes. the question is how do you avoid

using them in apu
using them in impl so that you at runtime are forced to newer java version too.

dhuebner · 2021-05-21T09:02:29Z

@cdietrich You said

JDT and other Dependencies like LSP4J

JDT is important for Xbase/Xtend and LSP4J, well for LSP. Both are not related to Xtext core at least not at compile time (afaik)

Maybe we should wait until we have a concrete problem and then look for a solution?

cdietrich · 2021-05-21T09:04:02Z

Of course lsp4j is a core dependency so are other platform dependencies

dhuebner · 2021-05-21T09:05:05Z

Really? Than we need to get rid of it

cdietrich · 2021-05-21T09:06:20Z

Well then we would ditch the lsp feature completely

ewillink · 2021-05-21T09:07:40Z

After installing a Java 5 JVM in Window->Java->Installed JREs , I find that plugins that claim BREE 5 report a compile-time error when the Java 6 String.length() is used. At compile-time I am confident that, despite using Java 11 as the tooling JVM, plugins are checked for Java 5/8 compliance as required. At build time I find that Tycho uses the BREE to determine the class file version so again my Java 5/6/8 BREE plugins have Java 5/6/8 class versions even though the Tycho tooling is using Java 11.

cdietrich · 2021-05-21T09:08:48Z

Again our code is gradle and maven. Not Tycho. These no nothing about BREEs

dhuebner · 2021-05-21T09:11:48Z

Xtext jars are hopefully still osgi budles? If so I think it would be wrong to set gradle/maven compile source/target level to something higher than the BREE entry. So I think it also about BREE here.

cdietrich · 2021-05-21T09:12:40Z

Yes they are but there is zero validation at compile time

cdietrich · 2021-05-21T09:13:31Z

And if you set compile version different from Bree it would be useless as you then will get class’s version errors at runtime if you use older java to execute

ewillink · 2021-05-21T09:19:21Z

wrt LSP, i'm not fussed since I don't use that feature.

I think there is confusion wrt waht standalone means becuase you probably don't use uit.

The following plugins are used to support an Xtext-based standalone parser/serializer.

org.eclipse.xtext
org.eclipse.xtext.util
org.eclipse.emf.mwe.core
org.eclipse.emf.mwe.utils
org.eclipse.emf.mwe2.runtime
com.google.inject
com.google.guava

They need to stay at Java <=8 BREE to avoid losing standalone support for the LTS Java 8.
Other plugins such as org.eclipse.xtext.ui are so dependent on the platform that replicating the platform BREE is sensible/necessary.

Since I know almost nothing about LSP, I cannot be sure but I suspect it has platform dependencies and so can happily got to Java 11.

cdietrich · 2021-05-21T09:34:19Z

yes but how to ensure that.

a there are these transitive deps (core.runtime/contenttype/jobs/equinox.app/common/preferences/registry/osgi) if platform decides then to compile and run with 11 only and our code directly or transitively (e.g. via emf) uses java 11 classes it will explode
we have to use a java 11 to run our build who prevents us from using java 11 api

ewillink · 2021-05-21T09:59:34Z

There is no problem using Java 11 for build. Build is not standalone. The JDT tooling warns you about non-BREE API at edit time. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=572771

When EMF classes access platform facilities you will find that they are all carefully coded to catch class load exceptions so class versions are already handled. See EMFPlugin.IS_ECLIPSE_RUNNING. Most of the standalone conditionalization comes from testing for a null singleton for e.g. the workspace/platform.

There is a small corner of JDT that provides version defaults for genmodel that needed regression fixing recently when the JDT developers overlooked the need to support standalone. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=540122

cdietrich · 2021-05-21T10:00:51Z

again: gradle does not know anything about BREE

ewillink · 2021-05-21T10:30:47Z

And I know nothing about gradle which AFAIAA is not a recommended tool for production of Eclipse project releases. So long as gradle has a bug in failing to produce Java classes that comply with the manifest BREE you should consider another standard tool.

cdietrich · 2021-05-21T10:34:56Z

then we are agan at: redo the whole build a a ton of work :(

ewillink · 2021-05-21T10:47:55Z

Reverting to Tycho might be good, but I really doubt that gradle is so inflexible. In so far as gradle is like Maven then it should be possible to specify a specific class binary version in the pom.xml equivalent for the two Xtext plugins that are used standalone.

cdietrich · 2021-05-21T10:49:59Z

actually many other plugins are used standalone too e.g. the xbase and xtend ones which are used by xtend-maven-plugin and transitively use jdt.

cdietrich · 2021-06-16T05:38:48Z

see also #1976
its already exploding with the new platform maven artifacts published tonight :(

cdietrich · 2021-06-16T13:42:08Z

see also https://www.eclipse.org/lists/cross-project-issues-dev/msg18499.html

OLibutzki · 2021-06-17T20:39:20Z

any arguments/reasons to still support Java 8

We use Xtext in an application which still uses Java8 (yes, the JavaEE world moves slowly).

Xtext is used at runtime as we interpret a DSL. The BOM the Xtext project provides helps us to ensure that all the libraries are Java8 compatible, although there are horrible version ranges in the Eclipse (e.g. JDT) pom files which might break your build over night.

Just to let you know how people use Xtext...

boris-unckel · 2021-06-21T14:42:15Z

The transitive dependencies of existing xtext versions already lead to Java 11 need, if you don't care manually:

[INFO] \- org.eclipse.xtext:org.eclipse.xtext.generator:jar:2.21.0:compile
[INFO]    +- org.eclipse.xtext:org.eclipse.xtext.ecore:jar:2.21.0:compile
[INFO]    |  \- org.eclipse.xtext:org.eclipse.xtext:jar:2.21.0:compile
[INFO]    |     +- org.eclipse.xtext:org.eclipse.xtext.util:jar:2.21.0:compile
[INFO]    |     +- org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.21.0:compile
[INFO]    |     |  +- org.eclipse.xtext:org.eclipse.xtext.xbase.lib:jar:2.21.0:compile
[INFO]    |     |  |  \- com.google.guava:guava:jar:27.1-jre:compile
[INFO]    |     |  |     +- com.google.guava:failureaccess:jar:1.0.1:compile
[INFO]    |     |  |     +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile
[INFO]    |     |  |     +- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO]    |     |  |     +- org.checkerframework:checker-qual:jar:2.5.2:compile
[INFO]    |     |  |     +- com.google.errorprone:error_prone_annotations:jar:2.2.0:compile
[INFO]    |     |  |     +- com.google.j2objc:j2objc-annotations:jar:1.1:compile
[INFO]    |     |  |     \- org.codehaus.mojo:animal-sniffer-annotations:jar:1.17:compile
[INFO]    |     |  \- org.eclipse.xtend:org.eclipse.xtend.lib.macro:jar:2.21.0:compile
[INFO]    |     +- log4j:log4j:jar:1.2.17:compile
[INFO]    |     +- org.eclipse.platform:org.eclipse.osgi:jar:3.15.100:compile
[INFO]    |     +- org.eclipse.emf:org.eclipse.emf.ecore.xmi:jar:2.16.0:compile
[INFO]    |     +- com.google.inject:guice:jar:3.0:compile
[INFO]    |     |  +- javax.inject:javax.inject:jar:1:compile
[INFO]    |     |  \- aopalliance:aopalliance:jar:1.0:compile
[INFO]    |     \- org.antlr:antlr-runtime:jar:3.2:compile
[INFO]    +- org.eclipse.xtext:org.eclipse.xtext.xtext.generator:jar:2.21.0:compile
[INFO]    |  +- org.eclipse.emf:org.eclipse.emf.codegen.ecore:jar:2.20.0:compile
[INFO]    |  |  \- org.eclipse.emf:org.eclipse.emf.ecore:jar:2.24.0:compile (version selected from constraint [2.20.0,3.0.0))
[INFO]    |  +- org.eclipse.emf:org.eclipse.emf.mwe.utils:jar:1.5.2:compile
[INFO]    |  |  \- org.eclipse.emf:org.eclipse.emf.mwe.core:jar:1.5.2:compile (version selected from constraint [1.5.2,1.5.2])
[INFO]    |  |     +- commons-cli:commons-cli:jar:1.2:compile
[INFO]    |  |     \- commons-logging:commons-logging:jar:1.1.3:compile
[INFO]    |  +- org.eclipse.emf:org.eclipse.emf.mwe2.lib:jar:2.11.2:compile
[INFO]    |  |  \- org.eclipse.emf:org.eclipse.emf.mwe2.runtime:jar:2.11.2:compile (version selected from constraint [2.11.2,2.11.2])
[INFO]    |  \- com.ibm.icu:icu4j:jar:52.1:compile
[INFO]    +- org.eclipse.emf:org.eclipse.emf.codegen:jar:2.19.0:compile
[INFO]    |  +- org.eclipse.platform:org.eclipse.core.runtime:jar:3.22.0:compile (version selected from constraint [3.6.0,4.0.0))
[INFO]    |  |  +- org.eclipse.platform:org.eclipse.equinox.common:jar:3.15.0:compile (version selected from constraint [3.14.0,4.0.0))

where
https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.equinox.common/3.15.0

unzip org.eclipse.equinox.common-3.15.0.jar

javap -verbose org/eclipse/core/runtime/ProgressMonitorWrapper.class | grep major

major version: 55 which is Java 11.

cdietrich · 2021-06-21T14:43:13Z

see also #1976

cdietrich · 2021-07-30T07:21:04Z

Update to Java 11 as minimal Java version #1972

Update to Java 11 as minimal Java version #1972

Comments

cdietrich commented May 17, 2021

ewillink commented May 17, 2021

cdietrich commented May 17, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

dhuebner commented May 21, 2021 • edited Loading

cdietrich commented May 21, 2021

dhuebner commented May 21, 2021

cdietrich commented May 21, 2021

dhuebner commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

dhuebner commented May 21, 2021

cdietrich commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021 • edited Loading

cdietrich commented May 21, 2021 • edited Loading

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

ewillink commented May 21, 2021

cdietrich commented May 21, 2021

cdietrich commented Jun 16, 2021

cdietrich commented Jun 16, 2021

OLibutzki commented Jun 17, 2021 • edited Loading

boris-unckel commented Jun 21, 2021

cdietrich commented Jun 21, 2021

cdietrich commented Jul 30, 2021

cdietrich commented Oct 4, 2021

cdietrich commented Apr 27, 2022

cdietrich commented Oct 12, 2022

dhuebner commented May 21, 2021 •

edited

Loading

ewillink commented May 21, 2021 •

edited

Loading

cdietrich commented May 21, 2021 •

edited

Loading

OLibutzki commented Jun 17, 2021 •

edited

Loading