Support Java 25 module import declarations (JEP 511)

Open
#8,367 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
compilers, tooling

Research direction

Start with ReloadableJava25ParserVisitor.visitImport and the parser/printer changes in #5997. Read the prior discussion of J.Import versus a separate module-import model, including ImportTree's JCImport and JCModuleImport forms. Done means import module java.base; parses without cursor desynchronization and passes the print idempotency check.

Written by the indexing model from the issue text.

Description

java java 25+ parser
What problem are you trying to solve?

import module java.base; (JEP 511) isn't handled by the parser. ReloadableJava25ParserVisitor.visitImport only looks at isStatic(), never ImportTree.isModule(), so the module keyword is left unconsumed and the source cursor desyncs. The result isn't a clean failure but corrupted output:

-import module java.base;
+import javale java.base;

Any project using module imports therefore fails the print idempotency check.

Prior work
  • #5993 was closed with the JEP 511 box unchecked.

  • #5997 implemented this as a module flag on J.Import (next to statik), and was closed unmerged:

    I don't approve of the approach. The JLS and compiler itself differentiate between module imports and non-imports, and I think it will add complexity to every import-related features if J.Import represents both. Closing and will redo at a later time.

    — @jkschneider, https://github.com/openrewrite/rewrite/pull/5997#issuecomment-3835776840

  • The review on that PR had already framed the choice. @Laurens-W noted that ImportTree can now be either a JCImport or a JCModuleImport, and laid out the two options: a new J.ModuleImport plus a shared Import interface (isStatic() / isModule() / getQualid()), which makes CompilationUnit return the interface rather than the implementation and requires refactoring the existing J.Import usages; or the module flag, which "leaves surface for issues later on".

  • @sambsnyd noted that a model change here needs a SaaS deployment queued after merge.

  • The parser and printer changes in #5997 remain a useful reference however the LST ends up being modelled.

Dominant language
Java
Stars
3.9k
Forks
599
Avg merge
9h 38m
Merged PRs (30d)
557

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openrewrite/rewrite

All issues in openrewrite/rewrite

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.