[jsr294-modularity-eg] Ignoring unknown directives...

[Alex Buckley]

We agreed that 'system' (or some close syntactic cousin) is reserved in 
the grammar for module-info.java and therefore has a ClassFile encoding; 
and that it is optional in module-info.java. It could be mandatory in 
module-info.class, since that would pull in the supported directives and 
behavior of the module's desired module system. Does that help?

Alex

Bryan Atsatt wrote:
> In today's call, it was suggested that an unknown directive (a.k.a. 
> 'keyword' in my 5/14 message, partially copied below) could simply be 
> ignored by a system that does not understand it. The more I think about 
> this, the more I believe it is flat out wrong, violating the principle 
> of least surprise and introducing indeterminate behavior.
> 
> If I design a module relying on a specific set of semantics (e.g. 
> friendship), and your module system decides it can load my classes but 
> silently ignore some of my directives (e.g. 'permits'), I'm going to be 
> one very annoyed customer when the bugs (or worse) start coming in to 
> me. Sure, there may be trivial cases where I won't care, but... that 
> should be my choice. At minimum I need a way to declare that some 
> behavior is required, but it seems vastly more intuitive to make that 
> the default and provide syntax to explicitly mark optional behavior.
> 
> A model that allows me to state the semantics I expect at a high level 
> (e.g. "system jigsaw at 2.1;" or "system jigsaw guice;" or "system 
> EE at 7.0;") must result in failures if these constraints are not met by an 
> available implementation, which in turn constrains the supported 
> directives. If such constraints are implied by system configuration 
> rather than being explicitly declared, they must be stored in the 
> module-info.class file (as if they were declared) in order to preserve 
> them across systems with different configurations.
> 
> If the model allows me to qualify some semantics as optional at the 
> module level (e.g. "system jigsaw [guice];"), and/or at the directive 
> level (e.g. "[requires bar];"), then I can build a flexible but 
> deterministic system.
> 
> // Bryan
> 
> 
> Bryan Atsatt wrote:
>> treat all declarations uniformly as a 'keyword' followed by a list of 
>> ' ' separated strings, so:
>>
>>    requires module m:1.1 local;
>>    requires module n:1.0 vendor=Sun optional;
>>    permits foo:1.0;
>>    permits bar vendor=Sun;
>>    classpath a.jar b.jar c.jar;
>>
>> can all be accessed via the same raw/low-level collection semantics:
>>
>>   Set<List<String>> get(String keyWord);
>>
>> Calling info.get("requires") would return:
>>
>>   {"module", "m:1.1", "local"}
>>   {"module", "n:1.0", "vendor=Sun", "optional"}
>>
>> and info.get("permits") would return:
>>
>>   {"foo:1.0"}
>>   {"bar ", "vendor=Sun"}
>>
>> and info.get("classpath") would return:
>>
>>   {"a.jar", "b.jar", "c.jar"}
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg