Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support Java 25 module import declarations (JEP 511)

Aperta
  • Qualcosa non va?
#8,367 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
compilers, tooling

Direzione di ricerca

Inizia da ReloadableJava25ParserVisitor.visitImport e dalle modifiche al parser/printer in #5997. Leggi la discussione precedente su J.Import rispetto a un modello separato per l’importazione dei moduli, incluse le forme JCImport e JCModuleImport di ImportTree. È completato quando import module java.base; viene analizzato senza desincronizzazione del cursore e supera il controllo di idempotenza della stampa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
3.7k
Fork
571
Merge medio
20h 46m
PR unite (30g)
211

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openrewrite/rewrite

Tutte le issue di openrewrite/rewrite

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.