Proposal: #CompileTimeDependences: `requires static`

[Paul Benedict]

I also believe the keywords "static" and "dynamic" are not a good fit here.
I commend and sympathize with your attempt, Mark, but it is too much of a
mental stretch to figure out what they are supposed to mean. At first it
looks like "requires static" is analogous to "import static" -- (that's
where the mind goes) but I knew that couldn't be the case....

What I propose is to treat "requires" as you would treat a class or method
-- with access modifiers, so to speak. What are the modifiers? They should
align to how the SOTMS speaks of the environment: compile and runtime.
Thus, I think the keywords should be "compile" (javac) and "runtime"
(java). That's just sensible, I believe. The implied/default is both and
don't need to be specified. But the developer could explicitly list them
out if he/she wanted to:

module joda.beans {
    requires compile joda.collect;
    ...
}


I do not like "optional" -- it's not descriptive enough for what meaning it
should convey. Optional when? The question gets begged; thus a person is
forced to answer, again, with compile or runtime. Hence "compile" and
"runtime" seem most appropriate.

And if for whatever reason Java needs a third or fourth or etc. environment
qualifier, the road is open to add more.

Cheers,
Paul

On Wed, Jun 29, 2016 at 8:34 AM, Stephen Colebourne <scolebourne at joda.org>
wrote:

> Thank you for this proposal, which I believe satisfies the necessary
> semantics.
>
> As others have noted, the words used in the module-info file are not
> especially clear and serve to obscure what is going on. I think
> perhaps there should be a wider re-evaluation of the keywords.
>
>     module A {
>         requires B;
>         requires static C;
>         requires static public D;
>         exports dynamic E;
>    }
>
> The basic concept that I see is "A depends on B" so "depends" or
> "dependson" would be better than "requires".
>
>     module A {
>         depends B;
>         depends optionally C;
>         depends optionally export D;
>         exports runtime E;
>     }
>
> or
>
>     module A {
>         depends B;
>         depends compiletime C;
>         depends compiletime export D;
>         exports runtime E;
>    }
>
> or more radically:
>
>     module A {
>         depends B;
>
>        compiletime {
>           depends C;
>           depends publish D;
>        }
>        runtime {
>           exports E;
>       }
>    }
>
> FWIW the proposed use of "optional" by a number of people is
> consistent with Maven, where "optional" means mandatory at compiletime
> and optional therafter.
>
> Stephen
>
>
> On 29 June 2016 at 00:31,  <mark.reinhold at oracle.com> wrote:
> > 2016/6/28 15:50:52 -0700, Remi Forax <forax at univ-mlv.fr>:
> >> Apart the fact that 'static' should be spelled 'optional', there is no
> >> reason to reuse static as it doesn't convey the semantics we want,
> >> i.e. optional at runtime, i fully agree with this proposal.
> >
> > In this context `static` is intended to mean "at compile time" or,
> > equivalently, before the more "dynamic" phases of run time and link
> > time (the latter of which is more like run time than compile time).
> >
> > I agree that `static` is potentially confusing since its meaning here
> > is different from what `static` means when used on a member of a class.
> >
> > It does, however, fit nicely with its (nearly) dual directive, `exports
> > dynamic`, proposed for #ReflectiveAccessToNonExportedTypes.
> >
> > I think `optional` is a non-starter, since `requires optional` reads as
> > an oxymoron, and it's optional at run time but mandatory at compile
> > time, so in what sense is it, really, "optional"?
> >
> > Suggestions of other alternatives are welcome ...
> >
> > - Mark
>