View source for JDT Core/Java9/Open items

{{caution|This is an outdated working document that was used by the JDT team before we had final specifications for Java 9}}

=== Specification and reference material ===
The EG has not shared any news on final specification. Some of the critical topics like module graph haven't made to any official document yet (only specified in the State of the Module). This needs to be taken up with the EG (Jay)

=== IClasspathEntry ===
The IClasspathEntry limits (by way of API doc) us to only the entry kinds we already have. Ideally, the Java Run time could use a new entry kind that can represent the new JRT format being specified by the Jigsaw. Currently, we work around by continuing to use the same JREContainer and adding to it one library entry (jrt-fs.jar). This is misleading, because the jrt-fs.jar itself doesn't represent the JRT. The container should come up with alternate way to handle this. {{bug|490103}}(Jay)

=== Module Path Container ===
How do the user handle the module dependencies of a project. One of the possible answer is by way of Module Path Container. Module Path container is a new ClasspathContainer that helps to resolve modules in the workspace, user libraries or system libraries. This can be done by implementing a module registry that is equivalent to the Target Platform for Plug-in development (sasi) ({{bug|500637}})

There should be help in the UI for the user for configuring a Java 9 project. The following are some:
* Context menu in Configure to convert a project to a module {{bug|488748}} (Noopur)
* The module container is added to the project's build path when converted/created (Noopur)
* Add modules as JAR or JMOD files to the module container {{bug|500905}} (Jay)
* Add modules (internal/external) to the module via content assist while editing module-info? (Noopur)

=== Where does the module-info.java go in the IDE? ===
There's been discussion about various alternatives, such as: allowing anywhere a user wants in the module project, root of the module project or in the root of one of the source folders in the module project. What works against the first two is how it will work with other build tools like maven, ant etc. At the moment the third option seems like the winner. But it needs to be studied how the tools aforementioned work in scenarios of multiple source folders within a project.

=== Creating a new module-info ===
As of today, there exists a stop-gap measure that allows the user to create a module descriptor for an existing Java project. This however is not good enough to be the final solution. The UI probably needs change. Besides the temporary API JavaCore#createModuleFromPackageRoot() should return an API not a String. (Jay)

=== How to read JMOD files ===
Experiments show that JMOD files are based on Zip format. However, the content seem to be structured slightly differently to JAR files. To be specific, JMOD files can contain not just class files but other things as well. This is enabled by having an additional top level folder within the JMOD file. For example, this is what java.base.jmod contains:

*bin
**java.exe
*conf
*native
*classes
**java
***lang

Java model should come up with a new IModuleLocation for Jmod (a specialized ClasspathJar?) to provide specific implementation. (Jay)({{bug|500905}})

=== Using JRE 9 as opposed to JDK ===
JDT requires the jrt-fs.jar to be able to tap into the Java runtime libraries. As of this is not being shipped as part of JRE (neither JRE 9 nor JRE 8). There's an open issue in Oracle for this - [https://bugs.openjdk.java.net/browse/JDK-8153079 Bug]

=== Restricted keywords ===
Certain keywords being introduced in Java 9 are specific to module-info.java and can be used as identifiers everywhere else. The rules in which locations these words are keywords vs. identifiers are not yet precisely specified. Our parser/scanner is not ready for this out-of-the-box. And there are talks of more such restricted keywords in Project Valhala (Java 10?). We need to study on possible ways of achieving this (Stephan/Markus/Sasi) - {{bug|488541}}

=== Module graph ===
Study the need for a module graph in the compiler.
The State of the module talks about certain restrictions around multiple modules exporting the same package in the context of another module. Currently this is not taken care of. (Jay/Sasi)


=== Debug ===
* Overview of debug work for Java 9 (Sarika)
* Support for JLink/JEP 282 (Sarika)

== Recent JSR 376 module-info changes (bug 500636) ==
* ImportDeclaration - clarification - where is it used inside a module-info.java file ?

* From the JDT perspective, the following changes will have an impact:
** Annotations Supported above ModuleDeclaration as @Foo(1) @Foo(2) @Bar Module M.N {}
** Keywords Added  : open, opens, transitive, static 
** Keyword removed : public
** Accessibility Rules now allow public and protected types to be accessible instead of just public types.
** Open Module Vs Normal Module - Does JDT have an impact since the difference is in reflective access? JDT.Debug affected?
** Keyword opens <package> [to <module>].