Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "JDT Core/Java9/JLS9"

(started a working document while digging through JLS-9 draft 2016-12-16)
 
Line 43: Line 43:
 
7.7.1 is still empty as of 2016-12-16
 
7.7.1 is still empty as of 2016-12-16
  
 +
'''JLS has another definition of visibility in 6.4.1''':
 +
<blockquote>A declaration d is said to be visible at point p in a program if the scope of d includes
 +
p, and d is not shadowed by any other declaration at p.</blockquote>
 +
but this seems to be a different concept than the visibility between a module and a compilation unit,
 +
maybe because a compilation unit is not a declaration.
 +
Generalizing from this observation, we may have to respect '''overloading''' of all kinds of notions,
 +
i.e., ''property-x'' of ''element-a'' need not be related to ''property-x'' of ''element-b''.
  
 
''to be continued''
 
''to be continued''

Revision as of 10:39, 29 December 2016

This page is a working document of attempts to map current drafts of JLS to the semantics as it should be implemented by the compiler.

To determine legal program structures a number of concepts must be considered, including:

  • scope
  • visibility
  • importing
  • accessibility
  • observability

Due to lots of cross-references between definitions, it is difficult (impossible?) to introduce and define one concept at a time without already defining all the other concepts. E.g., scoping and visibility are defined in what looks like a cyclic definition:

  • 6.3: The scope of a declaration is the region of the program within which the entity declared by the declaration can be referred to using a simple name, provided it is visible (§6.4.1).
  • 6.4.1: A declaration d is said to be visible at point p in a program if the scope of d includes p, and d is not shadowed by any other declaration at p.

I.e., scoping depends on visibility and visibility depends on scoping.

Accessibility of a type

Let's try to define the algorithm for determining accessibility of a type.

Start at 6.6.1 Determining Accessibility:

If a top level class or interface type is declared public and is a member of a package that is exported by a module, then the type may be accessed by any code in the same module, and by any code in another module to which the package is exported, provided that the compilation unit in which the type is declared is visible to that other module (§7.3).

so our checklist for cross-module accessibility is

  • type is public
  • containing package is exported by a module
  • referring code location is within another module to which the package is exported
  • compilation unit is visible to the other module

When is a compilation unit visible to a given module?

7.3 Compilation Units

[...] The ordinary compilation units that are visible to M are the observable ordinary compilation units associated with modules read by M. […]

Most of this is determined by "the host system" (i.e., not specified by JLS):

  • observability of a compilation unit (7.3)
  • association of a compilation unit to a module (7.3)

Remains: source and target modules have a reads connection.

The host system must use the Java Platform Module System to determine which modules are read by M (§7.7.1).

7.7.1 is still empty as of 2016-12-16

JLS has another definition of visibility in 6.4.1:

A declaration d is said to be visible at point p in a program if the scope of d includes p, and d is not shadowed by any other declaration at p.

but this seems to be a different concept than the visibility between a module and a compilation unit, maybe because a compilation unit is not a declaration. Generalizing from this observation, we may have to respect overloading of all kinds of notions, i.e., property-x of element-a need not be related to property-x of element-b.

to be continued

Back to the top