Get annotation processing going with Eclipse Compiler for Java

[arouel]

Problem

I'm writing a HTTP feature for Helidon (related to #8897) and want to work with Eclipse IDE, but the Helidon annotation processors throw an exception because the Eclipse Compiler for Java (ECJ) behaves slightly different compared to javac.

Solution

Two changes were necessary to get the annotation processing going:

• Due to the implementation of IdeFilerImpl:236 there is no handling for javax.tools.StandardLocation.SOURCE_PATH implemented and therefore the search for module-info.java fails with a thrown IllegalArgumentException. Ignoring this exception when compiling with the ECJ is fine.
• There is also a case where the ECJ cannot resolve a type name and the Element parameter is null. Returning an empty Optional enables the caller to fall back.
• Due to the implementation of IdeInputFileObject:50 the deletion of a FileObject throws an IllegalStateException. Ignoring any exception when compiling with the ECJ should be fine.

I have successfully tested the changes suggested here in a current Eclipse IDE (Version: 2024-06 (4.32.0)) on my local computer.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: [email protected] (@arouel)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[arouel]

Should we consider catching IOException and IllegalArgumentException instead?

[tomas-langer]

I think catching Exception is sufficient here, as it shows that there was "a" problem getting the module-info.java. As we have some fallback mechanism here, and we do not require it, it should be fine.
It may be interesting to find an alternative for Eclipse IDE (is there "any" way to get the module info?), because we use the module info to get the module name, which is used in some generated types (the worst case here is that the used name will be unnamed/package-name) for documentation purposes.

[arouel]

I double-checked the ECJ implementation and it only handles javax.tools.StandardLocation values that point to generated source code. Which means, we can't do anything here. We would need to adapt the ECJ and implement the missing cases we need.

[tomas-langer]

If you want to go forward with this PR, kindly sign the OCA, as otherwise we cannot accept your contribution.

[arouel]

@tomas-langer I added one more commit to handle the last case I had issues with when using Eclipse IDE. Can you have a look at it as well? I signed the OCA already, I guess it needs a bit to be approved.