Proposal: #CompileTimeDependences: `requires static`

Nicolai Parlog nipa at codefx.org
Fri Jul 1 05:45:43 UTC 2016


 Hi!

Because the naming discussion is more lively over here, I'll crosspost:

> Having the symmetric pair "static vs dynamic" looks nice but it
> takes a lot of words to explain why exactly these terms apply here.
> We seem to be looking for qualifiers for "requires" and "exports".
> Maybe just using other terms solves the problem?
> 
> requires & consumes exports & contains

So it would look as follows:

	module com.xyz {
		requires guava;
		requires joda;
		consumes hibernate;
		exports com.xyz.a;
		exports com.xyz.b;
		contains com.xyz.c;
	}

 so long ... Nicolai



On 29.06.2016 01: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
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx



More information about the jpms-spec-observers mailing list