Updated conformance text for Java SE 9 (JSR 379)

Volker Simonis volker.simonis at gmail.com
Tue Jul 25 20:55:25 UTC 2017


<mark.reinhold at oracle.com> schrieb am Di. 25. Juli 2017 um 21:39:

> // Replying to both EG lists, for the record.
>
> 2017/7/25 11:15:57 -0700, volker.simonis at gmail.com:
> > On Tue, Jul 11, 2017 at 7:10 PM,  <mark.reinhold at oracle.com> wrote:
> >> Attached below is revised and expanded text for the "Conformance"
> >> subsection of the "Modular platform" section [1] of the Java SE 9
> >> (JSR 379) specification.  ...
> >>
> >> ----
> >>
> >> ...
> >>
> >> As an aid to migration, an Implementation may relax the strong
> >> encapsulation of the modules that it includes as follows:
> >>
> >>  - An Implementation may provide a means to invoke its run-time system
> >>    with one or more packages of one or more of its modules open to code
> >>    in all unnamed modules, i.e., to code on the class path.  The first
> >>    access to an element of such a package by a program via a reflection
> >>    API must cause a warning to be issued on the standard error stream.
> >>    Later accesses may also cause warnings to be issued.
> >>
> >>  - An Implementation may, by default, open one or more packages of one
> >>    or more of its modules to code in all unnamed modules.  If it does so
> >>    then it must issue warnings as described in the previous paragraph.
> >>    If it does so then it must, further, provide a means to invoke its
> >>    run-time system without opening any packages of any of its modules.
> >>
> >>    (The Reference Implementation's run-time system behaves this way by
> >>     default, and because this is the default it can also be invoked
> >>     without opening any of its packages via the command-line option
> >>     `--illegal-access=deny`.)
> >
> > This is still not totally clear to me. Does it mean the specification
> > requires at least one warning for each package where we have an
> > illegal access, for each module where we have an illegal access or is
> > one single warning per invocation of the VM enough?
>
> One single warning per invocation of the VM.  You're right -- this could
> be more clear.  How about:
>
>   - An Implementation may provide a means to invoke its run-time system
>     with one or more packages of one or more of its modules open to code
>     in all unnamed modules, i.e., to code on the class path.  If the
>     run-time system is invoked in this way, and if by doing so some
>     invocations of the reflection APIs succeed where otherwise they
>     would have failed, then the first such invocation must cause a
>     warning to be issued on the standard error stream.  Later such
>     invocations may also cause warnings to be issued.
>
> Is that better?
>

That's fine!

Thanks,
Volker


> - Mark
>


More information about the java-se-9-spec-observers mailing list