Skip to main content
Jump to: navigation, search


The goal of this wiki page is to list down all the high level features that are being considered in Eclipse IDE for Java 9. The features shall include all the essential ones, nice-to-have and migration related features if any. Also, wherever possible please categorize the features as to which Eclipse component it falls under and if there are any dependencies. For tracking purposes, it would be ideal to highlight what state a particular feature is in. Possible states are Study, Requirement gathering, design, implementation, testing etc.

Java 9 progress
#Modules #Milling Project Coin Unicode support #JRT/JDK9 JMOD/JLink tools
#Parser (Sasikanth) NA NA
Compiler (Sasi/Stephan) July NA
Reconciler (Sasi) NA NA
Error recovery (Sasi/Stephan) NA NA NA
#Code generation (Sasi) NA
#Java Model (Jay) bug 490103
AST Rewrite (Manoj) NA NA NA
#Disassembler (Markus/Manoj) NA NA NA
Formatter NA NA NA
Indexer (Manoj) NA NA NA
Search (manoj) NA NA
#Code select (Jay) NA NA NA
#Code completion (Manoj) NA in progress NA
#APT (Jay) In progress NA NA NA NA
#JSR 199 (Jay) In progress NA NA NA NA
#Batch compiler (Jay) In progress NA NA NA
#Editor (Noopur) NA NA NA
#UI Tools (Noopur) NA NA NA
#Refactoring (Noopur) NA NA NA
#Quick fix/assist (Noopur) If time permits If time permits NA NA NA
#Launch (Sarika) Excl (3) NA NA NA
#Debug (Sarika) NA NA NA

   Substantially complete, with open items
   In Progress

Not Started yet

Not in September 2017 plan
NA Not Applicable


Java 9 EE and JRE 9 (80%)

The IDE should support JavaSE9 as a valid EE and allow mapping a valid JRE/JDK 9.

Jimage support (100%)

JDK/JRE 9 now ship with jimage files that contain all the platform resources. The resolved classpath of a project with JRE 9 will now contain a single entry representing the bootmodule.jimage. All JDT components should now be adjusted to work with the jimage format. Goal is to have all existing tests pass with a jigsaw build.

Parser support for (100%)

Grammar needs to be improved to accommodate new syntax changes in a The parser should take care of rejecting invalid code in a module-info with proper error. For instance, annotations are not supported in a module-info. Similarly it is not allowed to have regular code in a module-info.

Classfile support (100%)

The Classfile, ClassfileReader and friends should recognize a module-info.class and load the classfile content into a module, in a form useful to the resolution.

The Disassembler should recognize a module-info.class and load the classfile content from the different sections - see JVMS9 4.7.25-27 []

Code generation (80%)

Compiler need to be compiled into .class, in the format specified by the VM specification.

Module System

Module system is eclipse's implementation of the module system specified in JEP 261. Module system is responsible for 1. keeping track of modules in the current compilation context. 2. Help LookupEnvironment in finding packages and Types according to the module dependencies and readability.

Module resolution

The parser will take care of checking for incorrect syntax in a However, we still need a semantic analysis.
Specifically, we might want to validate the following:
That the exported packages and other entities specified actually exist in this module
that all required modules are present in the current compilation context

Batch compiler

JEP 261 specifies several new command line arguments. These need to be supported in ECJ. Notably -modulepath (shortly -mp), --module-sourcepath and -addexport.

JSR 199


APT support

Java Model

A big open question is where modules fits in the current Java model hierarchy. One way to go forward is to consider modules to be the following: 1. A kind of a package fragment root 2. A classpath location (IClasspathEntry, FileSystem.Classpath, ClasspathLocation etc.) This would mean that there could be multiple modules in a single Java projects. This is an open question that needs to be addressed (

DOM AST (100%)


Milling Project Coin (100%)



Editor support

Editor support for, module-info.class and Milling Project Coin is substantially complete.

Remaining issues for September release:
- Passing kind K_MODULE_INFO when formatting [1]. Depends on the outcome of - Formatter support for [2].

Completed tasks:
- Syntax coloring for new keywords in [3]
- Syntax coloring for new keywords in module-info.class: [4] and [5]
- Syntax coloring for IModuleDescription and module-info (.java and .class) files in declaration view and source hover: [6] and [7]
- Content assist for module references: [8]
- Content assist for types, packages and keywords works with existing UI support
- Mark occurrences for modules: [9]
- Handling private interface methods: [10] and [11]
- Switch ASTs to JLS9: [12]

UI Tools

Remaining issues for September release:
- Module declaration name should be validated while creation: [13]

Completed tasks:
- Support 9 as compiler compliance level: [14]
- Render module names in UI: [15]
- Support IJavaElements for modules in UI with new image: [16] and [17]
- Provide an action to create [18]
- Search for module declaration and references from Search dialog: [19]
- Ask for user selection on F3 if package is declared in multiple modules: [20]
- UI support to put a classpath entry on modulepath via "module" attribute: [21]
- UI for new option according to JEP 277 (advanced deprectation): [22]
- AST view and Java Element view updates: [23]

- Rename refactoring for type, package works with existing UI support
- Rename refactoring for modules: [24]

Milling Project Coin: (completed)
- Handling extract method refactoring for a resource used in try-with-resources: [25]
- Handling inline variable refactoring for a resource used in try-with-resources: [26]

Quick fix/assist

If time permits for the September release:
- Offer quick fix to add module for unresolved import and type: [27]
- Offer quick fixes to create private interface methods

Code completion

Code completion should work on completion of packages, types and module names in a Code completion support in, but with some follow up bugs. The top level bug: [28]

Code Selection

Code selection should work on completion of packages, types and module names in a Features such as navigation from/to module description to packages/types/modules and hover, Javadoc etc. should be supported. [29]


  1. JREContainer should be updated to work with a JRT based system where the system libraries are no longer packaged in a bunch of JAR files.
  2. Launching an application from a module project should compute the module path and set the -mp VM arguments appropriately.
  3. Provide a tab for the user to be able to add libraries to module path while launching, just like classpath.


Evaluation, code snippet etc., debugging should be tested for all module


Investigate scenarios of a PDE bundle with a module info (Vikas)


Export Java project into JMOD?

A Java project with a module or a module in a Java project can be exported to a JMOD. It is still not clear whether this format is open for use by others.

Export Java projects into Jimage?

User should be able to select multiple modules in the workspace and export it to a jimage. It is still not clear whether this format is open for use by others.

Modules in the package explorer.

It needs to be decided how we want to represent the module in the package explorer.

Migration path:

Convert a given Java project into module

Convert a source path into module

Generate module-info from MANIFEST?

==== Convert a PDE bundle into module? ====

Back to the top