Add module-info.java to eclipse null annotations

[agentgt]

This change just adds a module-info.java

What it does

See #2538 . It adds a module-info.java to the eclipse annotations jar.

How to test

Create a jlink bundled application that uses org.eclipse.jdt.annotation module.

Author checklist

The following is not really applicable.

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[stephan-herrmann]

Some questions while I'm trying to understand the motivation:

• are you saying that jlink does not understand automatic modules, or what exactly breaks here?
• if using jlink is the reason for wanting module-info.java, then why would including these annotations in the application be useful? Is it just that the tool enforces annotations to be resolved? They don't have runtime retention and hence shouldn't matter for an application.
• what is the advantage of using yet another maven plugin at build time over simply maintaining the simplest possible module-info.java as source?

[agentgt]

are you saying that jlink does not understand automatic modules, or what exactly breaks here?

It breaks. It does not support automatic modules.

if using jlink is the reason for wanting module-info.java, then why would including these annotations in the application be useful? Is it just that the tool enforces annotations to be resolved? They don't have runtime retention and hence shouldn't matter for an application

They are not needed assuming you just stick to the annotations but sadly it is tricky across Maven and Gradle to make sure the jar does not get picked up. I had to exclude the dependency and do a <scope>provided</scope>. That is what I did in this opensource project: https://github.com/jstachio/rainbowgum/blob/main/test/rainbowgum-test-jlink/pom.xml a

what is the advantage of using yet another maven plugin at build time over simply maintaining the simplest possible module-info.java as source?

I didn't even try putting in a real module-info.java in src because I wasn't sure what the tycho-compiler plugin supports and does not and or what version of javac it targets. I suppose I could try that Monday to see what happens with the build. Does JDT target something greater than or equal to 9?

[iloveeclipse]

Does JDT target something greater than or equal to 9?

Java 17 :)

[stephan-herrmann]

I didn't even try putting in a real module-info.java in src because I wasn't sure what the tycho-compiler plugin supports and does not and or what version of javac it targets. I suppose I could try that Monday to see what happens with the build. Does JDT target something greater than or equal to 9?

So, there's the rub: currently this plugin targets JavaSE-1.8, but it may actually be the last one far and wide. Most plugins of JDT currently target JavaSE-17.

As for javac versions: we don't use javac at all 😄, but ecj. And I know tycho is frequently updating the version, so I guess that tycho would allow compiling even for Java 22.

So, when you try adding a real module-info.java you should

• update Bundle-RequiredExecutionEnvironment and compiler compliance (I suggest: 11)
• update the bundle version, I believe 2.3.100 should be good (Manifest and pom)

[agentgt]

As for javac versions: we don't use javac at all 😄, but ecj. And I know tycho is frequently updating the version, so I guess that tycho would allow compiling even for Java 22.

Yes I was pretty sure it was ecj. What I meant by not knowing what it supported is if it (tycho + ecj) supports multi-release jars for the case of having annotations jar still support JDK 8 but if we don't need to worry about that (as in we can update it to 11) then I will attempt to do the update path you recommend and update the PR.