Implement per-source-folder module-info for multi-release compilation by laeubi · Pull Request #4534 · eclipse-jdt/eclipse.jdt.core

laeubi · 2025-10-17T11:15:54Z

See issue

MR compilation should respect release-specific module-info #4268

@stephan-herrmann this now works for the compilation part but not for the reconciler yet, where I need to check where to inject the info best.

I see two options here:

We merge this one and fix the reconciler in another PR (might also be easier to review)
We wait until i fixed that as well and delay this a bit more

laeubi · 2025-10-17T13:13:15Z

The reconciler case should now work as well (testcase is missing).

stephan-herrmann · 2025-10-19T10:33:40Z

Did you see the compile errors?

laeubi · 2026-02-20T04:00:50Z

Now there are API errors, I think I'll wait until the next stream opens to fix those...

laeubi · 2026-05-26T04:46:27Z

Now there are API errors, I think I'll wait until the next stream opens to fix those...

It seems I totally missed this - sorry for that. @stephan-herrmann should we go on with this to merge it for the next release stream? Was you able to test if this is fixing your JPMS issues you have seen?

laeubi · 2026-06-01T14:35:11Z

@stephan-herrmann finally build is green can you review/merge?

laeubi · 2026-06-17T06:42:09Z

@stephan-herrmann a friendly reminder for review, it would be good to have this in the M1 to allow extended testing period.

stephan-herrmann · 2026-06-18T12:44:49Z

@stephan-herrmann a friendly reminder for review, it would be good to have this in the M1 to allow extended testing period.

After a large burst of work on type inference I'm back on it now.

stephan-herrmann · 2026-06-18T15:02:54Z

For some call paths that are not yet release aware I filed #5149.

The following observation, however, might be good to fix in this PR:

Using the project from the new test case: Go to any of the Test classes, then select any of the Window or Element type references. Try hover, or Go To Declaration (F3 or ctrl+click) and observe the same inconsistency in all versions:

Window is correctly resolved
Element offers a selection of 4 types named "Element"

stephan-herrmann · 2026-06-18T15:07:34Z

@laeubi I tried to polish the javadoc for new API, please double check if anything is amiss now.

For the build failure I'm sure you understand better than me what is going on here (some baseline checks).

laeubi · 2026-06-18T16:25:46Z

Using the project from the new test case: Go to any of the Test classes, then select any of the Window or Element type references. Try hover, or Go To Declaration (F3 or ctrl+click) and observe the same inconsistency in all versions

Is this directly related to classes changed here / module support in general? If not I would prefer to better make smaller PRs than include more than the minimal required to fix one issue at a time.

laeubi · 2026-06-18T16:29:27Z

I tried to polish the javadoc for new API, please double check if anything is amiss now.

I added one comment to a change that looks suspicious the rest seems fine so far.

For the build failure I'm sure you understand better than me what is going on here (some baseline checks).

I think I likely need to re-base the PR if you are fine with that

stephan-herrmann · 2026-06-18T17:58:26Z

Using the project from the new test case: Go to any of the Test classes, then select any of the Window or Element type references. Try hover, or Go To Declaration (F3 or ctrl+click) and observe the same inconsistency in all versions

Is this directly related to classes changed here / module support in general? If not I would prefer to better make smaller PRs than include more than the minimal required to fix one issue at a time.

This problem can only be reproduced in an MR project with module-info.java, making the feature introduced here appear incomplete / broken. I haven't analyzed where in the code things go wrong.

stephan-herrmann · 2026-06-18T18:01:27Z

I think I likely need to re-base the PR if you are fine with that

If it's a pure rebase with no further changes hidden inside that's fine.

* javadoc of new API * code layout

laeubi · 2026-06-22T06:16:09Z

If it's a pure rebase with no further changes hidden inside that's fine.

I triggered the rebase now, lets see if it helps already...

This problem can only be reproduced in an MR project with module-info.java, making the feature introduced here appear incomplete / broken.

I can try to take a look but strictly speaking this PR was about compilation so possibly still better to have it in an extra PR as it more seem to surface at the UI.

Resolve types and modules from the source folder's own release specific module-info.java instead of always using the base module. Fixes duplicate Hover/Open-Declaration results for types only reachable via a higher release module-info.

laeubi · 2026-06-22T07:15:41Z

Openable.codeSelect (the entry point for Hover / Open Declaration) created its SearchableEnvironment with NO_RELEASE, so it always built the base module (src, which requires nothing) — regardless of which folder's Test.java was open. Consequently org.w3c.dom.Element is not found in the module graph (java.xml not readable), the binding can't be resolved, and SelectionEngine falls back to a module-unaware textual findTypes("Element") that returns all 4 JDK types named Element. Window "worked" only because exactly one accessible type is named Window.

I tried to add a test and fix the issue for this case now by adding MR awareness to the Openable.codeSelect ...

Make ASTParser binding resolution, code completion, IType.resolveType and type hierarchy resolution honor a release specific module-info.java in multi-release modular projects. Consolidate release lookup into shared JavaProject.getRelease helpers and add reconcile/AST tests.

laeubi · 2026-06-22T10:13:01Z

I now also addressed some other call sites where release awareness was missing. Let me know if you are fine with these or if I should better split up things into individual PRs.

laeubi mentioned this pull request Oct 17, 2025

MR compilation should respect release-specific module-info #4268

Open

laeubi force-pushed the mr_module_support branch from df8762b to 3d604f1 Compare February 19, 2026 05:02

laeubi force-pushed the mr_module_support branch from fab1c0b to c14baaf Compare May 26, 2026 04:44

laeubi force-pushed the mr_module_support branch 5 times, most recently from 09a568a to a8e95f3 Compare June 1, 2026 11:55

laeubi mentioned this pull request Jun 4, 2026

Support additional module-info.java for tests, if that ends up being de-facto standard #1465

Open

stephan-herrmann mentioned this pull request Jun 18, 2026

Check call flows passing JavaProject.NO_RELEASE into multi-release aware methods #5149

Open

laeubi commented Jun 18, 2026

View reviewed changes

Comment thread ...eclipse.jdt.core.tests.builder/src/org/eclipse/jdt/core/tests/builder/MultiReleaseTests.java

laeubi and others added 2 commits June 22, 2026 08:08

Implement per-source-folder module-info for multi-release compilation

011bf7d

polish:

61274b7

* javadoc of new API * code layout

laeubi force-pushed the mr_module_support branch from 68161a9 to 61274b7 Compare June 22, 2026 06:08

laeubi added 2 commits June 22, 2026 10:46

Add test for modular reconciling

7239a5e

Uh oh!

Conversation

laeubi commented Oct 17, 2025

Uh oh!

laeubi commented Oct 17, 2025

Uh oh!

stephan-herrmann commented Oct 19, 2025

Uh oh!

laeubi commented Feb 20, 2026

Uh oh!

laeubi commented May 26, 2026

Uh oh!

laeubi commented Jun 1, 2026

Uh oh!

laeubi commented Jun 17, 2026

Uh oh!

stephan-herrmann commented Jun 18, 2026

Uh oh!

stephan-herrmann commented Jun 18, 2026

Uh oh!

stephan-herrmann commented Jun 18, 2026

Uh oh!

laeubi commented Jun 18, 2026

Uh oh!

Uh oh!

laeubi commented Jun 18, 2026

Uh oh!

stephan-herrmann commented Jun 18, 2026

Uh oh!

stephan-herrmann commented Jun 18, 2026

Uh oh!

laeubi commented Jun 22, 2026

Uh oh!

laeubi commented Jun 22, 2026

Uh oh!

laeubi commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants