Take release level into account when check for java9

[laeubi]

Currently in SearchableEnvironment we only check if the project level is larger java9plus but when constructing a release specific SearchableEnvironment this needs to take the release option into account instead.

Fix #4399

@stephan-herrmann can you review / merge this?

[stephan-herrmann]

Could we please have a unit test? ReconcilerMultiReleaseTests seems to have all the infrastructure needed for this, right?

[laeubi]

@stephan-herrmann sorry I forget about this but now was hit by the problem as well... I adjusted the test and hope it is ready for a submission now!

[laeubi]

Build is green, so would be ready for submission!

[stephan-herrmann]

@stephan-herrmann sorry I forget about this but now was hit by the problem as well... I adjusted the test and hope it is ready for a submission now!

Sorry, I'm still more than busy with the fallout from #4293

[laeubi]

@stephan-herrmann sorry I forget about this but now was hit by the problem as well... I adjusted the test and hope it is ready for a submission now!

Sorry, I'm still more than busy with the fallout from #4293

I understand that but given only one line changes and covered by test you might consider it somewhere in between. If I can help anything let me know but it feels you are the expert and probably can handle it better than me :-)

[stephan-herrmann]

FYI, the build problem is caused by eclipse-pde/eclipse.pde#2096

[laeubi]

FYI, the build problem is caused by eclipse-pde/eclipse.pde#2096

I take a look into this, and hope it is resolved soon (at worst we need to revert the changes in API tools) if this is resolved do you think we can have this for M3?

[laeubi]

@stephan-herrmann kindly request your review, build is green again!

[stephan-herrmann]

@stephan-herrmann kindly request your review, build is green again!

looking through my list of review requests I didn't find this PR :)

Anyway, I found it again, looking into it now.

[stephan-herrmann]

Please provide a test case that shows the bug (i.e., fails without the fix).

[laeubi]

@stephan-herrmann I have simplified the test project find it here now it works without the m2e part
mrproject_plain.zip.

If I import that project, then go to the java15 folder and open MultiReleaseClass I get

Regarding the test it seems that I do something wrong previously used JCL_8_LIB and did not failed... I'll investigate on this but I'm quite sure this change is need I just seem to fail write correct reconcile tests :-\

[laeubi]

I played around with the test and it seems to reproduce the issue but sometimes when switching between branches the test is not updated and give strange results... I have now put the changes on a new PR that hopefully will show the testfailure:

• Test showing MR problem with testcase #4612

[laeubi]

@stephan-herrmann this one now shows the failure on master:

https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Github/job/PR-4612/1/testReport/junit/org.eclipse.jdt.core.tests.model/ReconcilerMultiReleaseTests/testNoErrorsAfterEdit/

I have rebased my change here and now we should see no failure anymore.

[stephan-herrmann]

I have rebased my change here and now we should see no failure anymore.

The test shows a different error, which is only the result of using jclMin, which doesn't have System.getProperty(). And since it's a different error, it's not fixed in this PR.

[laeubi]

I have rebased my change here and now we should see no failure anymore.

The test shows a different error, which is only the result of using jclMin, which doesn't have System.getProperty(). And since it's a different error, it's not fixed in this PR.

Then I need some hint from the JDT experts here, I can see the error clearly in the IDE (see screenshot above) but have no clue how to get the same setup in the tests, whatever I try I either get no errors at all or even completely different ones like java.lang.Object not found...

[stephan-herrmann]

If I import that project, then go to the java15 folder and open MultiReleaseClass I get ...

Now I see it, and here's the difference between the example project and the unit test: the latter fails to set "module=true" on the JCL_21_LIB classpath entry. Simply because the project compliance is 1.8. It seems you need to modify one more classpath entry after createJavaProject()

[laeubi]

It seems you need to modify one more classpath entry after createJavaProject()

I now created it as java 21 project, then set compliance manually to java 1.8... this still gives more errors than in the IDE but at least fails without and succeeds with the patch... the module=true is automatically set somewhere in the magic of the test helper classes.

[stephan-herrmann]

Updated test reproduces the problem, which is effectively fixed by this PR. We're good.

[laeubi]

@stephan-herrmann thanks for taking care of this. As M3 is soon I likely will need to delay other work to the next release, but this bug was really a blocker so good it is solved now!