fix: CommonViewerSorter has been deprecated in favor of CommonViewerComparator in Eclipse 2026-03

[FlorianKroiss]

No description provided.

[FlorianKroiss]

The following test case started failing:

  org.eclipse.lsp4e.test.outline.OutlineContentTest.testOutlineSorting -- Time elapsed: 5.332 s <<< FAILURE!
  org.opentest4j.AssertionFailedError: Condition not met within expected time. ==> expected: <true> but was: <false>
  	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:158)
  	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:139)
  	at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:69)
  	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:41)
  	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:228)
  	at org.eclipse.lsp4e.test.utils.TestUtils.waitForAndAssertCondition(TestUtils.java:342)
  	at org.eclipse.lsp4e.test.utils.TestUtils.waitForAndAssertCondition(TestUtils.java:309)
  	at org.eclipse.lsp4e.test.outline.OutlineContentTest.testOutlineSorting(OutlineContentTest.java:143)

I guess this is because of the 2026-03 release and the "latest" URLs being updated.

See eclipse-platform/eclipse.platform.ui@e738501#diff-df20bfcf89f97209c401261c76a33a325ffb0f95d60ae2a2196560496b7b59b9

[travkin79]

Hi @FlorianKroiss and @rubenporras,
What is the LSP4E policy concerning backward compatibility? Is there some kind of oldest Eclipse version that we stay compatible with? TM4E for example, does use multiple target platforms (see https://github.com/eclipse-tm4e/tm4e/tree/main/target-platforms).

It seems, this change made the LSP4E version 0.30.1 incompatible with e.g. Eclipse 2025-12 (which my team mates still have to use). See the following stacktrace:

java.lang.NoClassDefFoundError: org/eclipse/ui/navigator/CommonViewerComparator
at org.eclipse.lsp4e.outline.EditorToOutlineAdapterFactory.createOutlinePage(EditorToOutlineAdapterFactory.java:92)
at org.eclipse.lsp4e.outline.EditorToOutlineAdapterFactory.lambda$3(EditorToOutlineAdapterFactory.java:70)
at java.base/java.util.Optional.map(Optional.java:260)

[iloveeclipse]

Looking at Copilot bug tracker, there are lot of people requesting even Eclipse 4.30 support (and getting it, see microsoft/copilot-eclipse-feedback#169). Once they will get latest Copilot with latest Lsp4e, all such users will see troubles as well.

What I would say is: for such a very "low level" component like lsp4e, it would be great to support not only the latest Eclipse platform, but at least some releases before latest.

With that, a revert of the change here would be really appreciated.

[iloveeclipse]

The following test case started failing:

If this is caused by eclipse-platform/eclipse.platform.ui#3621 and if the change in platform is not compatible, it should be reported to platform.

@akurtakov : I assume, the assumption in eclipse-platform/eclipse.platform.ui#3621 was that the change is backwards compatible to existing plugins?

[iloveeclipse]

I've created #1515.

[FlorianKroiss]

I'm sorry for causing this problem. I did not see that the class was newly introduced and just wanted to fix the test by following the deprecation hint.

What is the LSP4E policy concerning backward compatibility?

I don't think we have one? But we should do what tm4e does. In hindsight, @sebthom even warned us that this very problem will happen sooner or later #1428 (comment)

[iloveeclipse]

I'm sorry for causing this problem. I did not see that the class was newly introduced and just wanted to fix the test by following the deprecation hint.

No problem, the intent was clear. Let discuss a fix for the specific issue here: #1516 and the (probably longer) discussion belongs to a dedicated ticket about LSP4E compatibility in general.

[akurtakov]

@akurtakov : I assume, the assumption in eclipse-platform/eclipse.platform.ui#3621 was that the change is backwards compatible to existing plugins?

For existing plugins - nothing changes as long as the old API is there. Most places are already using Comparators and not Sorters thus this is kind of continuing what has been started in years ago to move away of Sorters.

[iloveeclipse]

For existing plugins - nothing changes as long as the old API is there.

Hmm. The original issue was this one.

[akurtakov]

So switching to the new API makes it behave like the old API but the old API itself doesn't ? It somehow doesn't make sense to me unless there is some code somewhere doing instanceof check for ViewerSorter.