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

[Bryan Atsatt]

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