Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Java9/Features"
| Line 8: | Line 8: | ||
== Compiler/Builder == | == Compiler/Builder == | ||
| − | === Java 9 EE and JRE 9 === | + | ==== Java 9 EE and JRE 9 ==== |
The IDE should support JavaSE9 as a valid EE and allow mapping a valid JRE/JDK 9. | The IDE should support JavaSE9 as a valid EE and allow mapping a valid JRE/JDK 9. | ||
| − | === Jimage support === | + | ==== Jimage support ==== |
JDK/JRE 9 now ship with jimage files that contain all the platform resources. The resolved classpath of a project | 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 | 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. | be adjusted to work with the jimage format. Goal is to have all existing tests pass with a jigsaw build. | ||
| − | === Parser support for module-info.java === | + | ==== Parser support for module-info.java ==== |
Grammar needs to be improved to accommodate new syntax changes in a module-info.java. The parser should take care | Grammar needs to be improved to accommodate new syntax changes in a module-info.java. 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. | 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. | Similarly it is not allowed to have regular code in a module-info. | ||
| − | === Classfile support === | + | ==== Classfile support ==== |
The Classfile, ClassfileReader and friends should recognize a module-info.class and load the classfile content into | 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. | a module, in a form useful to the resolution. | ||
| − | === Code generation === | + | ==== Code generation ==== |
Compiler module-info.java need to be compiled into .class, in the format specified by the VM specification. | Compiler module-info.java need to be compiled into .class, in the format specified by the VM specification. | ||
| − | === Module resolution === | + | ==== Module resolution ==== |
The parser will take care of checking for incorrect syntax in a module-info.java. However, we still need a semantic analysis. | The parser will take care of checking for incorrect syntax in a module-info.java. However, we still need a semantic analysis. | ||
Specifically, we might want to validate the following: | Specifically, we might want to validate the following: | ||
| Line 29: | Line 29: | ||
that all required modules are present in the current compilation context | that all required modules are present in the current compilation context | ||
| − | === Module System === | + | ==== Module System ==== |
Module system is eclipse's implementation of the module system specified in JEP 261. Module system is responsible for | 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. | 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. | 2. Help LookupEnvironment in finding packages and Types according to the module dependencies and readability. | ||
| − | === Batch compiler === | + | ==== Batch compiler ==== |
JEP 261 specifies several new command line arguments. These need to be supported in ECJ. Notably -modulepath (shortly -mp) and -addexport. | JEP 261 specifies several new command line arguments. These need to be supported in ECJ. Notably -modulepath (shortly -mp) and -addexport. | ||
| − | === JSR 199 support === | + | ==== JSR 199 support ==== |
| − | === APT support === | + | ==== APT support ==== |
| − | === Code Assist === | + | ==== Code Assist ==== |
| − | === Java Model === | + | ==== Java Model ==== |
A big open question is where modules fits in the current Java model hierarchy. One way to go forward is to consider | 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: | modules to be the following: | ||
| Line 48: | Line 48: | ||
that needs to be addressed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=479483) | that needs to be addressed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=479483) | ||
| − | === DOM AST === | + | ==== DOM AST ==== |
It needs to be seen where and how we want to use modules in the UI. | It needs to be seen where and how we want to use modules in the UI. | ||
| Line 54: | Line 54: | ||
== UI == | == UI == | ||
| − | === Syntax highlighting === | + | ==== Syntax highlighting ==== |
Editor should highlight the keywords in a module-info.java when opened in a Java editor. | Editor should highlight the keywords in a module-info.java when opened in a Java editor. | ||
| − | === Code completion === | + | ==== Code completion ==== |
Code completion should work on completion of packages, types and module names in a module-info.java | Code completion should work on completion of packages, types and module names in a module-info.java | ||
| − | === Quick assist/fix === | + | ==== Quick assist/fix ==== |
What kind of assistance do we want to provide here? | What kind of assistance do we want to provide here? | ||
| − | === Classfile viewer === | + | ==== Classfile viewer ==== |
Being able to load/view module-info.class in the Classfile viewer. | Being able to load/view module-info.class in the Classfile viewer. | ||
| − | === Export Java project into JMOD? === | + | ==== 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 | 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. | not clear whether this format is open for use by others. | ||
| − | === Export Java projects into Jimage? === | + | ==== 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 | 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. | not clear whether this format is open for use by others. | ||
| − | === Modules in the package explorer. === | + | ==== Modules in the package explorer. ==== |
It needs to be decided how we want to represent the module in the package explorer. | It needs to be decided how we want to represent the module in the package explorer. | ||
| Line 75: | Line 75: | ||
== Migration path: == | == Migration path: == | ||
| − | === Convert a given Java project into module === | + | ==== Convert a given Java project into module ==== |
| − | === Convert a source path into module === | + | ==== Convert a source path into module ==== |
| − | === Generate module-info from MANIFEST? === | + | ==== Generate module-info from MANIFEST? ==== |
| − | === Convert a PDE bundle into module? === | + | ==== Convert a PDE bundle into module? ==== |
Revision as of 04:23, 10 February 2016
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.
Contents
Compiler/Builder
Java 9 EE and JRE 9
The IDE should support JavaSE9 as a valid EE and allow mapping a valid JRE/JDK 9.
Jimage support
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 module-info.java
Grammar needs to be improved to accommodate new syntax changes in a module-info.java. 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
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.
Code generation
Compiler module-info.java need to be compiled into .class, in the format specified by the VM specification.
Module resolution
The parser will take care of checking for incorrect syntax in a module-info.java. 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
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.
Batch compiler
JEP 261 specifies several new command line arguments. These need to be supported in ECJ. Notably -modulepath (shortly -mp) and -addexport.
JSR 199 support
APT support
Code Assist
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 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=479483)
DOM AST
It needs to be seen where and how we want to use modules in the UI.
UI
Syntax highlighting
Editor should highlight the keywords in a module-info.java when opened in a Java editor.
Code completion
Code completion should work on completion of packages, types and module names in a module-info.java
Quick assist/fix
What kind of assistance do we want to provide here?
Classfile viewer
Being able to load/view module-info.class in the Classfile viewer.
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.