Updates to platform components built on Java 17 causing upstream build issues

rougeSE commented 6 months ago

Steps to reproduce

We currently have a project that is building on Java 11 using the maven rap dependencies (along with others but these seem to be root cause).

<dependency>
  <groupId>org.eclipse.platform</groupId>
  <artifactId>org.eclipse.core.runtime</artifactId>
  <version>3.26.0</version>
</dependency>
<dependency>
  <groupId>org.eclipse.rap</groupId>
  <artifactId>org.eclipse.rap.rwt.osgi</artifactId>
  <version>3.24.0</version>
</dependency>
<dependency>
  <groupId>org.eclipse.rap</groupId>
  <artifactId>org.eclipse.rap.ui</artifactId>
  <version>3.24.0</version>
</dependency>

With these dependencies defined, we have been succuessfully compiling for months now, and then out of the blue we get a failure like.

[build.exec] [ERROR] /C:/Gitlab-Runner/builds/cQ4yTLFi/0/a-repo/src/main/java/a-package/AClass.java:[35,8] cannot access org.eclipse.core.runtime.IExecutableExtension
[build.exec] [ERROR]   bad class file: C:\Users\svc-jenkins\.m2\repository\org\eclipse\platform\org.eclipse.equinox.registry\3.12.0\org.eclipse.equinox.registry-3.12.0.jar(/org/eclipse/core/runtime/IExecutableExtension.class)
[build.exec] [ERROR]     class file has wrong version 61.0, should be 55.0

We have tracked this sudden build error down to a new release of a platform artifact, in the case of above, 3.12.0 was just released on 3/9/2024, and this new version apparently is only compatible with Java 17. This as occurred with numerous other artifacts with recent releases, such as, org.eclipse.core.commands, org.eclipse.core.jobs, org.eclipse.equinox.common.

The root cause seems to be that the higher level maven poms that they are using ranged versions for their dependencies. For example, the pom of org.eclipse.core.runtime has the following dependency.

<dependency>
      <groupId>org.eclipse.platform</groupId>
      <artifactId>org.eclipse.equinox.registry</artifactId>
      <version>[3.11.0,4.0.0)</version>
      <optional>false</optional>
</dependency>

With the apparent requirement of Java 17 on the recent registry release, is seems like registry should have been released using the 4.0.0 tag as to not to break the dependency chain, or a new version of these parent poms should be released with the proper ranges to lock out the inclusion of Java 17.

Workaround:

Currently, every time our build suddenly fails to compile for the reason shown above, we are having to go into our projects and explicitly list the previous version of the artifact that has broken the build. This started with a few artifacts and has increasingly grown over the past several months.

I expected: There to be a cleaner version division between legacy Java 11 support and the transition to Java 17 as a requirement. Seem like all java 17 should be in the 4.X as this is what all the existing poms seem to imply with the range of [3.x,4.0.0)

Tested under this environment:

OS & version: Windows 10 and Linux

Community

[x] I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

merks commented 6 months ago

This looks like the same type of issue as was raised here:

https://github.com/eclipse-equinox/p2/issues/481

FYI, any artifact published more recently does not generally use version ranges for dependencies but rather specifies a dependency on the specific version being used for that release.

This was the last release (2022-09 / 4.25) with ranges:

https://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.core.runtime/3.26.0/org.eclipse.core.runtime-3.26.0.pom

and this was the first release (2022-12 / 4.26) without ranges:

https://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.core.runtime/3.26.100/org.eclipse.core.runtime-3.26.100.pom

In other words, this issue has already been addressed.

Probably if you update to version 3.26.100 which is still based on Java 11---2023-06 / 4.28 was the first that needs java 17---you can avoid the issue.

akurtakov commented 6 months ago

The project rules are that we don't bump major version but the minor one for newer Java requirement as documented at https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/VersionNumbering.md#When-to-change-the-minor-segment

rougeSE commented 6 months ago

Thank you for the quick response the the link to the later pom with the ranges removed, I wish I would have noticed that later pom version as it would have limited our issue.

eclipse-platform / .github