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

0 files   -     54  0 suites   - 54   0s ⏱️ - 37m 9s
0 tests  -  4 665  0 ✅  -  4 643  0 💤  -  22  0 ❌ ±0 
0 runs   - 12 435  0 ✅  - 12 279  0 💤  - 156  0 ❌ ±0 

Results for commit 459844e. ± Comparison against base commit a877760.

♻️ 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 now 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.