MR compilation should respect release-specific module-info

[stephan-herrmann]

With #3900 it is possible to place several module-info.java into the roots of several source folders.

This is not yet handled correctly.

Sources from src9 can (sometimes) use dependencies defined in src24/module-info.java and similar confusion. Some of this even differs between full and incremental builds. There seems to be some randomness which module-info is used when during compilation.

[danthe1st]

Would implementing this also solve #1465?

[stephan-herrmann]

Would implementing this also solve #1465?

Not directly. With #3900 source folders are marked for different JDK versions, which isn't useful for the case of tests.

But thanks for reminding me. I might have news for that issue shortly.

[laeubi]

@stephan-herrmann can you probably add a test-case here that shows the issue:

https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.tests.builder/src/org/eclipse/jdt/core/tests/builder/MultiReleaseTests.java

[stephan-herrmann]

@stephan-herrmann can you probably add a test-case here that shows the issue:

https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.tests.builder/src/org/eclipse/jdt/core/tests/builder/MultiReleaseTests.java

Since it's not only one problem, I'm rather attaching a project as a basis for your experimentation:

MRmodular.zip

Expectations:

• the following field declarations should have errors (all others should be OK):
  • w11, element11
  • element17
  • w24
• the same result should be given from full build, incremental builds (triggered on any source file), reconciler/editor.

While the project looks like non-sense, please note that a relevant use case for MR compilation may indeed be to consume implementations that have migrated from external to jdk or vice versa, which means that different module dependencies may be needed per jdk version. In the future even an advanced use case might be considered: validating that the same code compiles fine against different JDK versions by leveraging different module dependencies! (in the example this is simplified by replicating Test.java).

From a tooling perspective a slightly simplified use case would be: for version JDK X we require module M and use its API, whereas for version X-1 we have to implement equivalent functionality on or own.

[stephan-herrmann]

Perhaps these observations are related: #3608 (comment)

[laeubi]

@stephan-herrmann I was struggling a bit why I did not get your expected problems described here until I realized that java.desktop seem to transitive require java.xml if I understand it right here:

https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html#modules.summary

so for your testcase actually element17 is expected to not show an error correct?

[laeubi]

@stephan-herrmann I have now made a firs step here:

• Implement per-source-folder module-info for multi-release compilation #4534

including your testcase.

[stephan-herrmann]

@stephan-herrmann I was struggling a bit why I did not get your expected problems described here until I realized that java.desktop seem to transitive require java.xml if I understand it right here:

https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/module-summary.html#modules.summary

so for your testcase actually element17 is expected to not show an error correct?

You're right. Sorry, my bad.

To restore the original intention I suggest to add one more type reference to all Test classes, where the necessary requires exists in the 24 variant of module-info .

Keeping the xml reference is actually useful, so we also cover one instance of requires transitive 😄