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

[Bryan Atsatt]

We are talking about locating a single implementation object (i.e. a 
ModuleSystem subtype) that can both validate the contents of a 
ModuleInfo as well as provide resolution based on it. While we could 
potentially split validation across multiple such objects, the compiler 
can't be responsible for combining multiple resolution results into a 
single one. So it seems reasonable to simply require any system that 
combines runtimes, layered or not, to provide a single, combined 
implementation. In your example, that implementation would have to 
combine logic for both OSGi and Guice.



BJ Hargrave wrote:
> 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_ <http://www.osgi.org/>_
> __hargrave at us.ibm.com_ <mailto: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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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-observer/attachments/20090624/e11f615c/attachment-0001.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg