Iris Clark
The Expert Group met via video conference on Thursday, 17 May 2017 at 15:00 UTC 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.
Attendees: Wayne Beaton (Eclipse, about 15 minutes late), 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).
The intent of these minutes is capture the conversational flow of the discussion and to record decisions. If you are only interested in the latter, search for the word “RESOLUTION” throughout the text.
These minutes were taken during the meeting. All participants had the opportunity to review and correct them for accuracy and completeness prior to publication.
Mark started the meeting by thanking everyone for joining. He immediately introduced Brian Goetz as the meeting moderator, who would ensure that everyone has a chance to be heard and keep the conversation running smoothly.
Brian began by reiterating his goal to keep the meeting running efficiently and reminded everybody that there were many issues to cover and not much time to resolve them. His first request was that people use the “raise hand” feature of the conference system to indicate a desire to speak. A roll call established the attendees.
Iris Clark from Oracle was introduced to take notes. In the name of transparency, draft minutes will be made available to attendees for review as soon as practical. After a 24-hour review period for accuracy and completeness, the minutes will be sent to the public EG list.
It was determined that this meeting would run 90 minutes to accommodate those with hard stops. There would be no meeting on Friday to accommodate travel plans and those in Europe.
Brian stated that the goal of the meeting was to work efficiently 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. He reminded attendees to make their cases in this forum rather than on a mailing list or in the court of public opinion.
The meetings will work through an agenda which has been seeded with a few new information items, existing open issues, and issues of concern to the JCP Executive Committee (EC). For each item, the goal is to assign one of three dispositions:
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.
Caution should be exercised for the “NOW” disposition, given the short time frame.
This is the initial agenda:
Two “new information” items
Review of issues resolved since the first Public Review (PR) submission
Other open issues
One issue of specific interest to the JCP EC
Additional items may be added after these have been addressed.
Tim expressed his concern that limiting discussion to these meetings alone would prevent others in the community from contributing to the conversation and resolution. Brian said that this ground rule should not be read as intent to ignore anybody’s input. It is about the EG working together and discussing concerns during these meetings rather than using a list or the court of public opinion for decisions. He continued saying that the JCP EC was unhappy with the use of the court of public opinion because it reflects poorly on the JCP, and the EC had encouraged EG members to talk directly with each other.
Mark brought forward two items of new information.
The first item has been mentioned by a few people from Oracle at a couple of JCP EC meetings, and discussed informally at recent developer conferences. The general idea is that the ecosystem would be better served by a more-rapid release cadence for Java SE and the JDK. Since the inception of Java, big features or a handful of big features have driven major releases every two to three years. This was reasonable in the 1990’s and 2000’s. Going forward, Java needs to move at a faster pace in order to remain competitive. People are therefore 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. It is relevant to these EG meetings because “LATER” may be sooner than expected. It could be twelve months after Java SE 9 GA, or even six months. This doesn’t mean that everything will occur in the next year, just that there are likely to be more opportunities for changes to be made.
The second item is a proposal posted to jigsaw-dev to allow illegal reflective access by default in JDK 9. As more and more people have tested JDK 9 EA builds it has become clear in wide discussions over the past few months that turning off reflective access from code on the class path is too aggressive for the initial release. The proposal is to allow this access by default in JDK 9, and disallow it in a future release. A warning will be issued on the first access. This proposal will not address all migration concerns, but it changes the migration from one huge step to multiple smaller steps spread across multiple releases. 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 had a question about how this proposal related to the unnamed module. Mark provided a quick answer saying that unnamed modules would have access to every package in every explicit module. He referenced the proposal for additional details.
This issue was resolved since the first PR submission. It is included in this meeting to confirm that resolution.
Mark summarized the issue saying that this had been a controversial topic for a while. After broad feedback, the specification was revised to allow digits at the end of module names. Brian asked for and received no feedback or objections.
RESOLUTION: NOW, as previously decided.
This issue was resolved since the first PR submission. It is included in this meeting to confirm that resolution.
Mark described this issue as a familiar step in designing APIs. The Module
and 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 Module, Layer, and the associated
InstantiationException to the java.lang package. Some renaming and a few
other adjustments were also necessary. Mark said that there were previously
no comments and while a few people did notice this change, it did not seem to
be a problem.
Brian solicited for feedback and comments. Tim replied saying that everything was fine and he was happy about the resolution to the previous issue as well.
RESOLUTION: NOW, as previously decided.
This issue was resolved since the first PR submission. It is included in this meeting to confirm that resolution.
Mark repeated his thanks to all who helped describe the issues around Maven.
Reverse DNS is now 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.
Mark reported that 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.
Brian Fox thanked Mark for continuing to listen and said he was happy with the resolution. He emphasized the need for recommendations for when to use the JAR manifest entry. Robert thought that there may be a problem for dependencies if a module name is identified before the code itself is modularized. Brian Fox believed it was helpful to provide users with a stable name for the code even before it was modularized. Robert explained that the speculative name did not belong in Maven Central because it was not reliable. Rémi pointed out that while the tools were all in place, what the Community needed was guidance for how to use them effectively. He suggested a public FAQ containing possibly different recommendations for how to use the manifest entry by application and library writers.
David thought 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.
Robert believed that 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. Brian Fox noted
that it was a challenge to wait for all dependencies to modularize and that
determining a module name should be encouraged.
Mark agreed with David’s earlier thoughts, 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. Tim 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.
RESOLUTION: NOW, as previously decided here and here. Additional guidance should be provided in an addendum to the specification or in a separate document.
This is an open issue.
Mark opened this discussion by noting that he raised this issue yesterday. In feedback over the last couple of years, and in particular over the last few months, it’s become clear that many developers expected the module system to handle multiple versions. We chose specifically not to do that in this release, but at this point it might be wise to leave room in the specification so that it can be extended to handle multiple versions in a future release.
In the issue he suggested, specifically, that we should make room 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.
David described a similar situation encountered in 2012 in JBoss Modules. A field was added for the version number. The wrapper object added some overhead, but it did not really buy anything. The information could have been encoded in the name and that is what JBoss Modules does now.
Rémi noted that the problem is that the find algorithm would necessarily
change. He preferred an encoded String over a new class and its associated
penalties. He continued saying that whatever the choice, simply adding a new
field would not work by default.
Tim’s opinion was 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. Tim expressed concern about the
impact of versioning to unnamed modules. Mark said that the proposal was
about introducing a concrete class, not about having version constraints in a
requires directive. There would be an object that identifies a module which
is potentially richer than the wrapped String for JDK 9. David added that
the algorithm used to identify a module should be one way (a graph). Tom said
that he did not 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.
Brian summarized saying that the general sense was that people wanted to think about the proposal. It should be revisited at the next meeting. Mark committed to post draft Javadoc for the API next Monday or Tuesday.
This is an open issue.
Mark opened the discussion by saying that this issue had been sitting around for a while. 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.
Rémi said that he’d played a bit with module-info.class files. He
discovered some problems in cases where modules are renamed. Mark understood
the issue, but did not 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.
Robert wondered whether it would be possible to store compile time arguments in the module-info file. He thought, while unattractive, 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. Rémi believed that propagation of this information should be left to the build tool. Tim objected to this standardization despite its potential usefulness.
Mark stated that notionally 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. Mark theorized that if the flags
were stored in module-info files, they would never go away. Robert agreed
with this.
RESOLUTION: NOW, as proposed: Standardize the attributes presently in the specification. A future specification may standardize additional attributes.
This is an open issue.
Alex defined this as 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.
Markus said that the proposed changes sounded good but he needed to read and consider the details.
Brian recapped the issue saying that there is agreement in spirit that the identity of a class should include provenance. Eclipse will review Alex’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.
Alex summarized saying 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 confirmed 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. Tim stressed that Markus was the expert; however he reserved the right to comment.
Brian’s summary was that there was agreement in spirit but time was needed to review the specification.
RESOLUTION: PENDING: Oracle to provide updated specification for review.
Brian estimated that two more hours would be needed for the remaining agenda items:
He surveyed availability on Monday. After a short discussion, a meeting at 15:00 UTC for 90 minutes was agreed upon. Due to attendance, the discussion of #RestrictedKeywords would be deferred until Tuesday.
At this point the EG adjourned.