Instantiate ClassFileReader via reflection

[cdietrich]

Fixes #3089

[LorenzoBettini]

Aren't we going to move to the new jdt anyway? As part to the Java 17 minimum version?

In any case, I'd avoid code duplication and put the code in some utility method.

[cdietrich]

problems

• new jdt maven wont be published before the Xtext release
• likely newer platform artifacts will even require java 21 to run.

=> we would have to drop out from 2024-09 or explode there and or set minimal version to 21
i dont know what the exact plans there are though

[cdietrich]

@LorenzoBettini where would the parkplatz for this utility be

[LorenzoBettini]

@LorenzoBettini where would the parkplatz for this utility be

For example, xtext.java?

In general, we might also want to create some kind of JDT Facade to isolate the rest of the code as much as possible from this kind of problems; that's something I've always wanted to propose but always forgot to.

[cdietrich]

but xbase.testing does not depend to does it?

[LorenzoBettini]

I would go with the project that uses JDT internals, which are used by both projects involved in this PR, and move that utility method there; I don't have an Xtext workspace at the moment.

In any case, I can work on that later or in the near future without blocking this PR.

[cdietrich]

lets see what @szarnekow says

[szarnekow]

I would land this here. It’s unfortunate that JDT breaks in such a simple way but there’s not much we can do about that. Subsequently we could perform a systematic refactoring to extract code into a new bundle. That won’t help with old versions though. Same as this PR does only help for future versions

[LorenzoBettini]

@cdietrich so shall we merge this?