Remove remaining pseudo dependency of E4-Injector to jakarta annotations

[HannesWell]

This ensures that the E4-Injector does not work with any specific annotation class.

The pseudo dependency was introduced when resolving Bug 301462, but just returning an empty array as dependencies of the ClassRequestor also passes the then added DisposeClassLinkTest.
I stepped through the code a bit when using the ClassRequestor and the pseudoVariable doesn't seem to have an effect.
Or does anyone know a reason to keep it?

Follow-up on

• Support multiple versions of annotation classes in E4 Injector #1566

[HannesWell]

Even with invalidJavadoc turned to warning the javadoc links below report errors because the jakarta.annotation/inject annotations are not accessible anymore.
The only way I found to silence the errors was to add them back as additional.bundles in the build.properties below.
Does anyone know a JDT preference to ignore inaccessible types in javadoc? Or is this a bug?

[laeubi]

eclipse-jdt/eclipse.jdt.core#4923

Apart from that I think the javadoc references are not that valuable so we can remove them if needed.

[HannesWell]

Thanks for the pointer.

Apart from that I think the javadoc references are not that valuable so we can remove them if needed.

Yes, they are not essential. But I think they're nice to have and if possible, I'd like to retain them

[github-actions]

Test Results

    54 files  ±0      54 suites  ±0   36m 23s ⏱️ + 1m 36s
 4 667 tests ±0   4 645 ✅ ±0   22 💤 ±0  0 ❌ ±0 
11 895 runs  ±0  11 742 ✅ ±0  153 💤 ±0  0 ❌ ±0 

Results for commit d7d0151. ± Comparison against base commit 7f435dc.

♻️ This comment has been updated with latest results.

[akurtakov]

That way the DI will not make sure there is at least one annotation provider - it opens the door for products crafted with either javax or jakarta or both or none even.
This might have the implication that target platforms will have neither thus projects need modifications in their target platforms in order to migrate to new eclipse version.

[laeubi]

The pseudo dependency was introduced when resolving Bug 301462, but just returning an empty array as dependencies of the ClassRequestor also passes the then added DisposeClassLinkTest.

Sadly the bugzilla link is inaccessible - do you have a copy of what this is talking about?

I stepped through the code a bit when using the ClassRequestor and the pseudoVariable doesn't seem to have an effect.

Is this maybe somewhere else used (e.g. via reflection?) as it is a public static field ... it might be used for some kind of triggering a (reinjection) of dependencies.

[HannesWell]

The pseudo dependency was introduced when resolving Bug 301462, but just returning an empty array as dependencies of the ClassRequestor also passes the then added DisposeClassLinkTest.

Sadly the bugzilla link is inaccessible - do you have a copy of what this is talking about?

Bugzilla seems to have had some temporary issues today. It was available when I wrote the comment and is now available again for me. But besides that the resolving commit might provide more context: 6cf3c7c

I stepped through the code a bit when using the ClassRequestor and the pseudoVariable doesn't seem to have an effect.

Is this maybe somewhere else used (e.g. via reflection?) as it is a public static field ... it might be used for some kind of triggering a (reinjection) of dependencies.

I didn't find any such reflective reference. And something like that was also not done in the commit that introduced that class. My assumption is that it was just added to return a non empty array in calcDependentObjects().
But as far as I can tell, just returning an empty array seems to have no drawbacks. The DisposeClassLinkTest, introduced with 6cf3c7c, still passes.

[HannesWell]

That way the DI will not make sure there is at least one annotation provider - it opens the door for products crafted with either javax or jakarta or both or none even. This might have the implication that target platforms will have neither thus projects need modifications in their target platforms in order to migrate to new eclipse version.

That's in theory correct, but the other very basic e4-core/di Plug-ins still require it:

Therefore I'd assume that the chances are relatively low that one can really avoid the jakarta annotation bundles or that one would not have them in the in the TP transitively. But the chances are not zero.

My primary goal was to make the o.e.e4.core.di independent from any specific annotation package in order to ensure by design that it doesn't rely on specific class instances but just relies on names.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 131684691742b0bc37deecdedaa7d3bce5b11745 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sat, 30 May 2026 04:37:50 +0000
Subject: [PATCH] Version bump(s) for 4.41 stream


diff --git a/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF b/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
index fa1bd583a4..16709d0eaf 100644
--- a/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
+++ b/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.e4.core.di
-Bundle-Version: 1.9.800.qualifier
+Bundle-Version: 1.9.900.qualifier
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.54.0

Further information are available in Common Build Issues - Missing version increments.

[HannesWell]

I've now replaced the currently erroring JavaDoc links by code elements, which could be reverted when the JavaDoc processing in ECJ is less strict.

I stepped through the code a bit when using the ClassRequestor and the pseudoVariable doesn't seem to have an effect.

Is this maybe somewhere else used (e.g. via reflection?) as it is a public static field ... it might be used for some kind of triggering a (reinjection) of dependencies.

I didn't find any such reflective reference. And something like that was also not done in the commit that introduced that class. My assumption is that it was just added to return a non empty array in calcDependentObjects(). But as far as I can tell, just returning an empty array seems to have no drawbacks. The DisposeClassLinkTest, introduced with 6cf3c7c, still passes.

My proposal is to submit this soon, so we would have sufficient time for fixes in case the conclusion is wrong that this is a save change.

[akurtakov]

I agree, please merge as soon as you're comfortable with the change to get as big testing window as possible.

[vogella]

I think this causes the failing test in the I-Build.

org.eclipse.e4.ui.tests.workbench.PartRenderingEngineTests	testBut336225()	Failure	The shell should not have been disposed first ==> expected: <false> but was: <true>

org.opentest4j.AssertionFailedError: The shell should not have been disposed first ==> expected: <false> but was: <true>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertFalse.failNotFalse(AssertFalse.java:63)
at org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:36)
at org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:239)
at org.eclipse.e4.ui.tests.workbench.PartRenderingEngineTests.testBut336225(PartRenderingEngineTests.java:1751)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

I assume the pseudoVariable has a influence in the ordering of @PreDestroy

[HannesWell]

I assume the pseudoVariable has a influence in the ordering of @PreDestroy

Yes, that seems to be the case.

The pseudo dependency was introduced when resolving Bug 301462, but just returning an empty array as dependencies of the ClassRequestor also passes the then added DisposeClassLinkTest.

At the same time, it seems that that test is not sufficient to cover all cases and should be enhanced. But I don't know all details from the test that failed...