Details
-
Bug
-
Resolution: Fixed
-
P4
-
11
Description
Consider this snippet from http://www.eclipse.org/eclipse/news/4.8/jdt.php#module-info-paste
-----
import java.sql.Driver;
module hello {
exports org.example;
requires java.sql;
provides Driver with org.example.DriverImpl;
}
-----
The `import` declaration should obviously put the simple type name `Driver` in scope in the body of the module declaration, for use in the `provides` directive (or a `uses` directive). Compilers do this. Sadly, 6.3 forgot about the body of the module declaration when top-level and nested types are imported:
-----
The scope of a type imported by a single-type-import declaration (§7.5.1) or a type-import-on-demand declaration (§7.5.2) is ***all the class and interface type declarations (§7.6) in the compilation unit in which the import declaration appears***, as well as any annotations on the module declaration or package declaration of the compilation unit.
The scope of a member imported by a single-static-import declaration (§7.5.3) or a static-import-on-demand declaration (§7.5.4) is ***all the class and interface type declarations in the compilation unit in which the import declaration appears***, as well as any annotations on the module declaration or package declaration of the compilation unit.
------
Both of the starred clauses should say "... ***the module declaration and*** all the class and interface type declarations of the compilation unit ...".
Happily, putting the simple type name `Driver` in scope for the `provides` and `uses` directives does not obscure the simple module name `Driver` that may be uttered by `requires` and `exports ... to` directives. Obscuring occurs only when there is ambiguity about whether a name is one kind of name versus another, but 6.5.1 is unambiguous about names in the body of a module declaration: names in a `provides` or `uses` directive are always type names, and names in a `requires` directive or after the `to` in an `exports ... to` directive are always module names.
-----
import java.sql.Driver;
module hello {
exports org.example;
requires java.sql;
provides Driver with org.example.DriverImpl;
}
-----
The `import` declaration should obviously put the simple type name `Driver` in scope in the body of the module declaration, for use in the `provides` directive (or a `uses` directive). Compilers do this. Sadly, 6.3 forgot about the body of the module declaration when top-level and nested types are imported:
-----
The scope of a type imported by a single-type-import declaration (§7.5.1) or a type-import-on-demand declaration (§7.5.2) is ***all the class and interface type declarations (§7.6) in the compilation unit in which the import declaration appears***, as well as any annotations on the module declaration or package declaration of the compilation unit.
The scope of a member imported by a single-static-import declaration (§7.5.3) or a static-import-on-demand declaration (§7.5.4) is ***all the class and interface type declarations in the compilation unit in which the import declaration appears***, as well as any annotations on the module declaration or package declaration of the compilation unit.
------
Both of the starred clauses should say "... ***the module declaration and*** all the class and interface type declarations of the compilation unit ...".
Happily, putting the simple type name `Driver` in scope for the `provides` and `uses` directives does not obscure the simple module name `Driver` that may be uttered by `requires` and `exports ... to` directives. Obscuring occurs only when there is ambiguity about whether a name is one kind of name versus another, but 6.5.1 is unambiguous about names in the body of a module declaration: names in a `provides` or `uses` directive are always type names, and names in a `requires` directive or after the `to` in an `exports ... to` directive are always module names.