Revision as of 06:58, 6 September 2016

Java 9 @ JDT/Core (20160831)

Runtime images

• no more bootclasspath
  • who is affected by this? jdt.launching?
  • but -Xbootclasspath/a is still supported

• we can't rely on file names of modules.jimage or anything like that

• only publicly known file: jrt.fs.jar (only in JDK, not in JRE)
  • mostly wrapped for JDT/Core by class JRTUtil
    • should Util.isJrt() be in this util class, too?
  • provides the only documented access to content of java.home
    • In getJrtSystem(File) I see it rooted with the path of any IPackageFragmentRoot?, so what are possible arguments to this method?
      • [Jay] This would be the path that refers to the JRT file system. At the moment to the path of the jrt-fs.jar, but eventually the path to the java.home?
      • [Stephan] How about using JRT file system for reading user modules?
        • [Jay] My understanding is that the jrt-fs.jar can only be used to read the JRT (as the name implies, Java Run Time). Quick experiments show the jrt URI scheme doesn't support this.
        • I am able to read a JMOD's directory structure and content by renaming its extension to .jar. However, there appears to be a difference in the directory structure in comparison with a traditional JAR. The JMOD contains an additional level of folders and all classes go into a sub-folder "classes".
  • IClasspathEntry doesn't provide a kind corresponding to module

Finding types & packages in modules

• LookupEnvironment: no major changes atm
• new superclass ModuleEnvironment just below INameEnvironment
  • find type takes an additional argument: the module from the current site
  • gets a chance to wrap or filter the regular Answer, in particular injects the module reference into the found type (?) / compilation unit (?)

Discuss: Answering null for an inaccessible type may not suffice for good error reporting, perhaps answering a ProblemReferenceBinding is better? Would this require a ProblemCompilationUnit??

(No) Module Graph

Currently, no module graph is computed. ModuleBinding computes (keep? caching?) a flat list of modules / packages it requires

Are there use cases that require the full graph?

• should the compiler detect certain kinds of conflicts / name clashes that require the full graph?
• or is local analysis per focus module enough?
• where to find specification for errors we should detect? "State of the module"??
  • can the same module occur twice in the same universe?
  • multiple instances of the same package?
    • Can we avoid this by always compiling one module at a time?
      • Batch compiler would require some pre-scanning to resolve dependencies between source modules
    • additional magic in PackageBinding to disambiguate same-named packages

"What is a module?"

Decision has been made: module corresponds to a JavaProject.

To resolve modules from other projects / jmods we may need global state with a mapping module -> location. Isn't that the job of Target Platform? I.e., should a Target Platform be able to hold jmods in addition to jars?

What's the best location for module-info.java?

• Currently: root of a source folder, but how does this work with two source folders contributing to the same module? How to find the module-info.java of the containing module?
• Should users be free to place it anywhere? Root of project? META-INF/?
  • Could be direct child of IJavaProject and a special entry in .classpath
    • Would that break UI like JavaEditor (expecting it to be in a source folder)?

Commandline compilation

• single module takes module-info as a argument, would be fine with any location
• multi-module expects module-info to be at the root of each source path. This mode is not relevant inside the IDE

We should reach out to build technologies like m2e and gradle (said to be in good shape) to see how they will accommodate modules. How will they specify locations of modules? Just a folder (expecting module-info to be inside) or folder plus module-info?

Search

Different use cases may have different needs:

• search only directly visible modules / packages
• search all code that is "runtime reachable" from the current module

Is module-info indexed yet? bug 500622 tracks this

Can we search for a package? If not, why not?

What should search return? eg use case: search for a type which is referenced in the module (use/provides) - An IModule is required to contain this IJavaElement to pass for the search results.

DOM

Needed, because renaming a package etc. must update module-info, too.

Other

I will need to support external annotations per module.

Does module-info support javadoc?

Schedule

This is what I see at http://openjdk.java.net/projects/jdk9/ :

 Schedule
   2016/05/26 		Feature Complete
   2016/08/11 		All Tests Run
   2016/09/01 		Rampdown Start
   2016/10/20 		Zero Bug Bounce
   2016/12/01 		Rampdown Phase 2
   2017/01/26 		Final Release Candidate
   2017/03/23 		General Availability
 The milestone definitions are the same as those for JDK 8.
 Status
   We are past the Feature Complete milestone, but that does not mean
   that the feature set is frozen. If you own a JEP or a small enhancement
   that is not yet complete then you can request an extension via the 
   FC extension-request process.

However the ticket for JEP 261: Module System (https://bugs.openjdk.java.net/browse/JDK-8061972) has this comment:

 Mark Reinhold added a comment - 2016-06-22 08:22
 FC Extension Request
 The foundations of the module system were integrated this past March,
 and appear to be in pretty good shape. We expect further revisions as
 the JSR 376 EG works through its issue list [1], and in response to
 further feedback from the wider developer community.
 _
 Late changes in this area are not without risk, and at present that risk
 is difficult to estimate. We expect few if any changes, however, in the
 VM or the client libraries; most changes would be in the core libraries
 and the compiler (javac), for which test execution is fully automated
 and run on all supported platforms continuously.
 _
 Estimated completion: 2016/9/1 
 

Request made by Mark Reinhold, granted by Brian Goetz immediately after.

The mark [1] assumably is intended to refer to http://openjdk.java.net/projects/jigsaw/spec/issues/ but in the ticket there is no such link.