The Jigsaw Expert Group is patching things up [UPDATE]
© Shutterstock / Rawpixel.com
Lucky number three. The third meeting of the Jigsaw Expert Group (they also met on May 17 and 22) offered an answer to the question on everyone’s lips: Is the group ready to move forward? Let’s have a look at the minutes.
Update: Third meeting
The Jigsaw Expert Group met for the third time on Tuesday, May 23, 2017 “to work toward closure on various technical issues and prepare to submit a revised Public Review Draft Specification to the JCP by 7 June.”
The meeting was very fruitful, it seems: with just one exeption, namely #RestrictedKeywords, there were no objections to the resolutions. Mark Reinhold enumerated four issues that should be investigated for a future release:
Reinhold promised to try to “condense the reasoning for why each was considered but not addressed at this time, and include that reasoning in an update to the specification.”
Getting down to business — JCP Public Review process
David Lloyd of Red Hat suggested publishing the revised specification with sufficient time for the JCP EC to provide comments prior to the PR Ballot submission. Oracle’s Brian Goetz mentioned that there’s a two-week voting period for JCP EC review, so “any added delay would lose valuable time.”
When IBM’s Tim Ellison asked whether it would be helpful to prioritize the “LATER” list, Reinhold replied that there were limits to what any particular EG could expect a hypothetical future EG to do. However, the latter was open to prioritizing the “LATER” list.
Update: Second meeting
The expert group met for the second time on May 22.
There were quite a few pending agenda items from the last meeting, including #ResolutionAtCompileTime, #CompilationWithConcealedPackages and #ModuleIdentifiers. While the first two items have a ‘pending’ status, the latter received the ‘LATER’ disposition.
According to Reinhold, after further study and prototyping by Alan Bateman (Oracle), “it was determined that multiple versions of modules of the same name could be handled in a future revision of this specification almost entirely by overloading the existing
String-consuming API methods.”
RESOLUTION: LATER, since the current specification has the necessary flexibility to extend the module system to handle multiple versions in a later release.
Check out all the agenda items here.
The Jigsaw Expert Group met via video conference on May 17 “in order to work toward closure on various technical issues and prepare to submit a revised Public Review Draft Specification to the JCP by 7 June.” According to the meeting minutes, Oracle’s Brian Goetz, who was also the moderator, said that the purpose of the meeting was to “reach closure on four categories of technical issues”:
- issues resolved since the first Public Review draft;
- issues raised by the JCP Executive Committee;
- currently open issues;
- and closed issues about which new information has recently become available.
Goetz revealed that the goal was to assign one of three dispositions to each new information item, existing open issue, and issue of concern to the JCP Executive Committee (EC):
- NOW — The issue must be addressed in this release.
- LATER — The issue may be resolved in some unspecified later release.
- NEVER — There is no interest in further work on this item.
The Expert Group met for the second time on May 22.
Two items of new information
Mark Reinhold,Chief Architect of the Java Platform Group at Oracle proposed two items:
- The first item is to implement a more-rapid release cadence for Java SE and the JDK. “People are exploring the possibility of shifting to a yearly or even a six-month cycle. If a big feature is ready, it goes in; otherwise, it waits for the next release. There is no formal proposal at this time; however, discussion is expected in the JCP and OpenJDK communities in the next few months.”
- The second item is a proposal posted to jigsaw-dev to allow illegal reflective access by default in JDK 9. To help the ecosystem “migrate to the modular Java platform at a more relaxed pace,” Reinhold proposed to allow illegal reflective access from code on the class path by default in JDK 9 and to disallow it in a future release. According to the minutes, “this proposal is technically not part of JSR 376, since 376 is just about the module system; it is part of the JSR 379 platform specification, which will contain the necessary conformance text.”
Tom Watson of IBM asked how the second proposal related to the unnamed module. Reinhold said that “unnamed modules would have access to every package in every explicit module.”
This issue was only included in the meeting to confirm the resolution. The specification “was revised to allow digits at the end of module names.
RESOLUTION: NOW, as previously decided.
This issue has also been resolved since the first Public Review submission and was only included in the meeting to confirm the resolution.
Reinhold said that this issue is “a familiar step in designing APIs. The
Layer classes which allow reflective access to modules were originally added to the
java.lang.reflect package, because that was the obvious place. On further thought, this decision was not aligned with the likely future of the platform, which is shifting from the old core-reflection APIs in
java.lang.refect to the method-handle APIs in the
java.lang.invoke package. This proposal moved
Layer, and the associated
java.lang package. Some renaming and a few other adjustments were also necessary.”
RESOLUTION: NOW, as previously decided.
Again, this issue was resolved since the first Public Review submission.
Reverse DNS is currently the preferred convention for naming modules, and maintainers of existing libraries may specify a preferred module name in the
MANIFEST.MF file of a JAR file containing code which is not modular. The implementation had been in the Jigsaw EA builds for over a week and that members of the London Java Community have been testing it, Reinhold added.
Brian Fox of Apache Maven emphasized the need for recommendations for when to use the JAR manifest entry while Robert Scholte, also from Apache Maven, opined that there may be a problem for dependencies if a module name is identified before the code itself is modularized. Fox added that it might be helpful to offer users a stable name for the code even before it was modularized and Scholte explained that the speculative name did not belong in Maven Central because it was not reliable. Rémi Forax, researcher and teacher at University Paris East Marne la Vallee, suggested a public FAQ containing possibly different recommendations for how to use the manifest entry by application and library writers.
Lloyd opined that “migration to JDK 9 would be in multiple phases for typical libraries. First, changes for compatibility and new APIs need to be addressed. If a JAR file’s manifest declares a module name prior to that point then it would appear that it’s compatible before it actually is, so the name should be declared in the manifest only when the JAR file is known to work on JDK 9. In the next phase of migration the code is explicitly modularized, and at that point its name is taken from its module declaration.”
According to Scholte, “a library maintainer should only start using module descriptors after all dependencies have been modularized or have a name via the
Automatic-Module-Name attribute in the manifest file. He offered to provide a sample project to further illustrate his concern. Fox noted that it was a challenge to wait for all dependencies to modularize and that determining a module name should be encouraged.”
Reinhold agreed with David Lloyd’s [of Red Hat] earlier comments, saying that “if you maintain a library then make it work with JDK 9 first. When the code is compatible, add a nice DNS module name to the JAR manifest and publish it to Central. During the transition period to full modularization, rely on Gradle or Maven to get all the dependencies right. IBM’s Tim Ellison thought that this migration problem did not need to be solved as part of the specification; a public FAQ or guidance would be sufficient aid for migration.”
This is an open issue and should be revised at the next meeting.
Reinhold suggested that room should be made “for identifying a module by more than just a simple
String name. If only a
String is used, it is likely that solutions for multiple versions would either require a violent API refactoring or the
String would need to encode additional information. Both are distasteful. The forward-looking proposal is to use a new class,
ModuleId, as the identifier. For JDK 9 it would simply be a wrapper around a
String. In the future the class could be enhanced to carry additional information. This change does not add a new feature; it simply leaves room in the design space for future evolution.”
Forax pointed out that the real issue is that the find algorithm would necessarily change and expressed his preference for an encoded
String over a new class and its associated penalties. “Whatever the choice, simply adding a new field would not work by default,” he concluded.
Ellison opined that “having something that encapsulates the version of the module was useful since any logic would be localized, rather than spread across multiple places.” He noted that parsing strings to extract version numbers would be error prone and burdensome and expressed concern about the impact of versioning to unnamed modules. Reinhold explained that this proposal isabout introducing a concrete class, not about having version constraints in a
requires directive and said that there would be an object that identifies a module which is potentially richer than the wrapped
String for JDK 9.
Lloyd opined that the algorithm used to identify a module should be one way (a graph) but Watson doesn’t see a need for future-proofing unless there was a need for module identity to go beyond a name and a version. However, seeing the proposed API would help with visualization and providing concrete suggestions.
This is an open issue.
Reinhold emphasized that this issue “had been sitting around for a while and said that there are a set of optional module-info class-file attributes which are not required by the module system but are generally useful for improving performance and for tools. He briefly outlined the current set of attributes and their intended uses. At the conclusion of the short list, Mark suggested that this list be finalized for this release. Additional attributes could be defined in a future release.”
Forax revealed that he played a bit with
module-info.class files and found some problems in cases where modules are renamed. Although Reinhold acknowledged the issue, he didn’t think “his situation was fixable in the remaining time. Rémi agreed with Mark’s characterization of being uncomfortable with the situation, but not objecting.”
Scholte wondered whether it would be possible to store compile time arguments in the module-info file and added that “there may be cases where knowledge of these arguments would be helpful at run time. Without such a mechanism, there would be no way for users to discover how code was built.”
According to Reinhold, “what belongs in
module-info files is just what is needed for the module system to operate at compile time and run time. Command-line flags which may be used to break in should be considered only as transitional tools to get to the future.” Furthermore, if the flags were stored in
module-info files, they would never go away.
RESOLUTION: NOW, as proposed: Standardize the attributes presently in the specification. A future specification may standardize additional attributes.
According toAlex Buckley of Oracle, this issue is “largely a technical specification issue. Compilers are powerful because they can see the source code from many modules at once. So how does the Java Language Specification (JLS) mandate how the compiler differentiates between classes of the same name? The request from the Eclipse team was to clarify the JLS for type identification. He continued saying that name resolution is the most twisty part of the JLS.”
Eclipse will review Buckley’s text and provide feedback during a later meeting.
RESOLUTION: PENDING: Eclipse to review the proposed specification, which has since been published.
This is an open issue.
Buckley said that “the compiler is now expected by the JLS to respect any `requires’ directives that it finds in the source of a module declaration. Historically the JLS has avoided defining how files are found. The class path and source path are exclusively defined by the compiler implementation. With JPMS, a compiler of the language must be connected to the rest of the module system to “resolve” dependencies and “read” another module. Whatever is true at run time must also be true at compile time. For most people this is a run-time issue, so the API specification will contain that information at a high level. The JLS will then refer to the API specification.”
Markus Keller of Eclipse said that as long as the JLS specifically pointed to the API specification then there would be something stable for compiler implementors. He said that he was looking forward to seeing the JLS and API updates.
RESOLUTION: PENDING: Oracle to provide updated specification for review.
Oracle’s Iris Clark took the meeting notes. The meeting was attended by Wayne Beaton (Eclipse), Alex Buckley (Oracle), Tim Ellison (IBM), Rémi Forax, Brian Fox (Apache Maven), Brian Goetz (Oracle, moderator), Markus Keller (Eclipse), David Lloyd (Red Hat), Mark Reinhold (Oracle), Robert Scholte (Apache Maven), and Tom Watson (IBM).