ExceptionInInitializerError creating an ASTParser in an OSGI env #4438

[weissreto]

Only initializes the JavaModelManager if the org.eclipse.jdt.core bundle was started. This is checked via JavaCore.getPlugin(). This allows to use ASTParser in an OSGI-environment without to start the org.eclipse.jdt.core bundle.

#4438

What it does

See #4438

How to test

Use ASTParser in test code and depend on classes in org.eclipse.jdt.core.
Start the test code, in an OSGI environment, but do not start the bundle org.eclipse.jdt.core

Author checklist

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

[laeubi]

As the bundle is marked as lazy-autostart this check will always yields true. Also it dies check something else than what before was checked.

Maybe you want to elaborate a bit more what problem you face and what you want to solve here?

[weissreto]

Hi Christoph
Let me clarify the problem I am trying to solve.

My company offers a product for workflow and process management. This product consists of two main components:

• Design Part: This component is based on the Eclipse IDE, enhanced with custom plugins developed by us. In the Design Part, we use jdt.core to develop Java code, leveraging its full functionality.
• Engine Part: This component executes the workflows and processes developed in the Design Part. The Engine is built on OSGi and uses Eclipse Equinox as its implementation, meaning Platform.isRunning() returns true. The Engine also uses jdt.core, but only for specific tasks, such as converting old project versions to the latest ones (e.g., migrating javax.* to jakarta.*). Unlike the Design Part, the Engine does not utilize the full capabilities of jdt.core (e.g., no indexing). Instead, it only uses ASTParser.

To ensure the Engine has a fast startup, we prevent the jdt.core bundle from starting automatically. This is achieved by setting its start level to 100 in the bundles.info file of the SimpleConfigurator. As a result, the jdt.core bundle is not started within the Engine, and calling JavaCore.getPlugin() returns null. This causes a NullPointerException (NPE), which is documented in the issue.

What I want to achieve is for the ASTParser to function as it would in a non-OSGi environment. Instead of relying on Platform.isRunning() to check the platform state, I propose checking whether the jdt.core bundle is running.

[laeubi]

Two thing to consider:

1. In general it would be good to have a preference to disable indexing, this sound much more semantic to me than your current approach
2. This code here never uses JavaCore.getPlugin() return value so why not check it for null at the place where the NPE occurs?

Apart from that in both cases the code runs inside an OSGi environment what makes the PR title / commit message quite confusing. e.g. in Tycho we use the AST outside OSGi and then one might experience issues because the code is not aware of that always.

[weissreto]

Hi @laeubi
Sorry for my late response. It was a busy week. And in the next week I'm at a conference. I will consider your thoughs and will then decide how to proceed.
Thanks for the review

[weissreto]

Hi @laeubi

1. I agree that a preference to disable indexing and anything else that makes JDT startup slow would be a good option.
2. I fear that I have to put in null checks at a lot of places which makes it even worse. Putting it here is easy and the behaviour is like in a non OSGi case.
   But maybe our use case is to specific to have it in the code base at all?

[laeubi]

Putting it here is easy and the behavior is like in a non OSGi case.

Without OSGi the whole code in the activator is never called.

But maybe our use case is to specific to have it in the code base at all?

Not at all I wanted to disable indexing also quite often in other cases, so starting with a preference here seems useful (and flexible) than to try archiving it "indirectly".

[weissreto]

Close the PR and the issue. Better provide a configuration to disable the indexer instead of fixing this issues in a very uncommon use case.