View source for JDT Core/Java9/Notes 20160831

{{caution|As the date in the title suggests, this page is outdated}}

=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 <tt>modules.jimage</tt> or anything like that

* only publicly known file: <tt>jrt.fs.jar</tt> (only in JDK, not in JRE)
** mostly wrapped for JDT/Core by class <tt>JRTUtil</tt>
*** ''should Util.isJrt() be in this util class, too?''
** provides the only documented access to content of java.home
*** ''In <tt>getJrtSystem(File)</tt> 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 <tt>ModuleEnvironment</tt> just below <tt>INameEnvironment</tt>
** 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 <tt>null</tt> for an inaccessible type may not suffice for good error reporting, perhaps answering a <tt>ProblemReferenceBinding</tt> is better? Would this require a <tt>ProblemCompilationUnit</tt>??

==(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 <tt>module-info.java</tt>?
* 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 <tt>.classpath</tt>
*** 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 ([http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009157.html 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? [https://bugs.eclipse.org/500622 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==
We will need to support external annotations per module (Stephan).

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 <nowiki>[1]</nowiki> assumably is intended to refer to http://openjdk.java.net/projects/jigsaw/spec/issues/ but in the ticket there is no such link.