Java 8 no longer works #187
Comments
|
see discussions in eclipse/xtext#1976 it should also work to run the build with Java 11 against 8 source&target |
|
Workaround till the plugin adds the BOM automatically: |
|
@oehme How this workaround could look like for Gradle 4? (But the problem is the same for ...) |
|
There should be the way to use explicit versions as you can find in a few of the 100 comments in the Xtext issue |
|
@kuniss you can use |
Worked well for me. 🤝 |
|
i assume to fix this we have to
maybe we also can use some reflection, |
|
I think the first question should be: How much do we care about keeping support for these outdated Xtext, Gradle and Java versions? I already have a rewrite of the plugin in progress and this is the main open question: What will our minimum requirements be? |
|
@oehme i would be perfectly fine with Xtext 2.17.1+ (the first with a dev bom) |
|
The question is: Why support Java 8? Java 11 is the current LTS and has been out forever. We'll soon have the next LTS (Java 17). So spending extra effort to support Java 8 is something I'd need a really good reason for. |
|
Xtext still supports Java 8, so it would be nice to have a fix that also works on Java 8, for Java 11 we can sit out the problem for now, but it will reappear once platform messes with java 17 |
|
Okay, I'll think about an approach that'll keep maximum compatibility for now and just fixes this current issue in a patch release. Independently of this I still want to modernize/simplify this plugin, so that patch might be the last version to support Java 8/Gradle 4 etc. |
|
👍 |
|
Java 8 is still alive and will remain in use for a long time. It takes time for large companies to upgrade things like this. They also may have support contracts that extend support & security patches beyond the public EOL schedule. Below is the hotfix plugin I wrote to work around this issue to support Java 8 (and 6 sadly): |
EMF has open version ranges pulling in whatever the latest core runtime version is, thereby breaking Java 8 compatibility. This change fixes those versions back up. For newer Xtext/Gradle versions it uses the Xtext BOM. For older versions it does some hand-picked version fixes. To test this properly, we're now not just testing against different Gradle versions. I've also raised the maximum versions to the latest ones that we can support without major test rewrites. Fixes #187 Fixes #189
EMF has open version ranges pulling in whatever the latest core runtime version is, thereby breaking Java 8 compatibility. This change fixes those versions back up. For newer Xtext/Gradle versions it uses the Xtext BOM. For older versions it does some hand-picked version fixes. To test this properly, we're now not just testing against different Gradle versions. I've also raised the maximum versions to the latest ones that we can support without major test rewrites. Fixes #187 Fixes #189
|
Version 2.0.9 of the plugin fixes this. |
Create the xtextTooling Configuration for each SourceSet right away rather than lazily. This makes it visible in the output of the `dependencies` task and allows users to easily customize it in their build scripts, e.g. when there is another issue like #187 Use lazy callback APIs like `eachDependency` (to align versions for Xtext itself) and `withDependencies` (to add the BOM when that Xtext version has one) instead of using the Gradle-interna LazilyInitializedFileCollection. Load all dependencies, including the Xtext languages into the xtextTooling Configuration so that all version numbers are aligned. Previously it was possible for the xtextLanguages Configuration to bring in incompatible versions of libraries like eclipse.core.resources, which was especially visible when trying to use Xcore with this plugin. Now everything is aligned with the Xtext BOM and/or our dependency resolution rules. Remove the complicated "classpathInferrer" logic in favor of this new approach. This also means that the Xtend plugin is now much simpler, since it only needs to add the xtend.core dependency to the xtextTooling Configurations and that version will automatically be aligned by our resolution rules. This raises the minimum Gradle version to 4.7, which seems very reasonable given that the latest is 7.2.
org.eclipse.platform:org.eclipse.equinox.common:3.15.0 was recently published and it gets pulled in from transitive dependency ranges. As a result attempting to run generateXtext fails on any version of xtend and the gradle plugin with a class version error.
Expected
xtend 2.25.0 and xtext-gradle-plugin 2.0.8 supports compiling java 8
Actual
Using java 8 fails
The text was updated successfully, but these errors were encountered: