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

[Bryan Atsatt]

Yep. And I think we need a statement like "a module system must treat 
unknown directives or operands as errors". If we had a standard way to 
mark any directive as optional, then we could allow module systems to 
ignore any optional directive, known or not.

// Bryan


Alex Buckley wrote:
> 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
>
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg