ASTParser should detect and report when no suitable system library has been configured #3047

[jarthana]

What it does

Fixes #3047

How to test

Author checklist

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

[stephan-herrmann]

Commit 19be8b3 got a bit more complex than expected for two reasons:

• Several tests were indeed ill-configured using minimal system libraries that didn't match the project compliance etc. Also one such library was found to be quite incomplete.
  • a bunch of tests configured for "1.8" indeed do not supply any system library at all:
    createJavaProject("P", new String[] { "" }, new String[0], "");
• based on the decision to look for module java.base, it get's a bit blurry if that module is not found:
  • I added a fallback looking for class java.lang.Object if no module was found at all.
  • the code needs to differentiate if explicit classpaths are provided or if that information should come from an IJavaProject
  • still at 1.8 the code keeps silent (for pragmatic reasons, partly because of the number of lib-less tests)

The current state is a compromise trying to raise the exception in most relevant situations.

We could probably simplify the code and also check at compliance 1.8 if we only look for class java.lang.Object. I didn't make this the one and only criterion because I feared that searching deep into details of all classpath entries might degrade performance, more so than just looking for module-info at the root of each entry.

If, however, we assume when RESOLVE_BINDING is requested, the compiler will need to lookup java.lang.Object anyway, then we could reduce the checks to that class lookup (but would need to "fix" more tests which don't have system libraries configured).

@jarthana wdyt?

[stephan-herrmann]

• Several tests were indeed ill-configured using minimal system libraries that didn't match the project compliance

Some locations seemed to suffer from the confusion between 1.8 and 18. E.g., project Converter_15_1 uses compliance "15" but as library "CONVERTER_JCL18_LIB" was used, which is for "1.8"!

[jarthana]

Looks good, Stephan. I just looked at what we do in the IDE. There, we seem to somehow turn that into a build path problem. Probably lot of work goes behind that.