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

[BJ Hargrave]

But the systems are built in layers. Using OSGi and Guice as an example, 
Guice support will not be built into the OSGi implementation. It will best 
be provided by a layer on top of the module system. So a module declaring 
system osgi,guice will contain information for an OSGi module system 
implementation and information for the Guice layer. The OSGi layer will of 
course not understand the Guice information, so is the OSGi implementation 
supposed to declare the module in error?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Bryan Atsatt <bryan.atsatt at oracle.com>
To:
JSR 294 Expert Group <jsr294-modularity-eg at cs.oswego.edu>
Date:
2009/06/23 21:28
Subject:
Re: [jsr294-modularity-eg] Ignoring unknown directives...
Sent by:
jsr294-modularity-eg-bounces at cs.oswego.edu



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090624/494a2eb6/attachment-0001.html>