[jsr294-modularity-eg] 294 EG conf call, 2009-04-15

[Peter Kriens]

I would like to formalize my objections against the current direction.

The require and permit keywords (and now maybe provided as well ) are  
said to be "special" because they are some archetypical concepts of a  
module system. Even if they are, I think we can all agree that they  
have no semantics in the proposal, except the archetypical concept  
that "something" is needed in "some" way, depending on the module  
system. For all the language care, the following would be allowed and  
up to the module system. For example, a dms module system could do:

	module dms com.acme {
		require copyright	Some Alliance (c) 2009;
		require name		Silly Module;
		require bundle		com.acme.bar;
		require license		Apache 2.0;
		permit  description	This bundle demonstrates that require and
					permit have no semantics;
	};

The current approach is making the Jigsaw semantics the default  
(without specifying them, nor making clear they are the Jigsaw  
semantics), while the OSGi spec must now suddenly try to wrangle their  
much richer semantics through the shoehorn of two (three?) ill fitting  
and undefined keywords. Not only does this put OSGi at a disadvantage,  
but it also commits the much graver sin of trying to specify something  
that has not been tested in practice yet.

At the end of the last call we were considering a provided keyword,  
that could be leveraged by the OSGi module to export packages. We were  
discussing the semantics of a concept that we could only vaguely  
define because I do not expect Jigsaw to follow the OSGi semantics and  
I do not expect them to come up in the current time frame that would  
match our rather rich model with directives and attributes.

We are in the situation that we unfortunately have a need to use the  
same real estate for different semantics. Though I do understand that  
likely more than 90% of the Java programmers are not using OSGi as  
Alex stated, I do know for sure that 0% of the Java programmers are  
using Jigsaw. The only -real- experience we're having with a serious  
module system is OSGi. Forcing OSGi to shoehorn through ill-defined  
keywords seems hard to defend with any technical argument. Especially,  
because the proposal already takes the heavy hit of semantics based on  
module systems. So why not make it clear what we are doing instead of  
trying to hide it?

Therefore, the approach I would prefer is the following:

1) Only one module-info.java file, just like package-info, the name is  
fixed.
2) The file allows multiple module systems to specify their metadata
3) There is a standard meta-syntax for the module system section  
shared between module systems. This could be based on key-value pairs,  
JSON, or maybe something like the OSGi header syntax:

	ms     ::= ( FQN '{' header * '}' ) *
	header ::= keyword  clause ( ',' clause )*
	clause ::= name ( ';' key '=' value )*

4) The keywords in this module section are up to the module system so  
they will have a clear source for their semantics

For example:

	module com.acme;
	jigsaw {
		require M1 @ 3.4.5+;
		require M13 @ 23.4+;
		permit  M2;
	}

This proposal is neutral and can look just as good as the constrained  
require, permit, provided proposal that is now on the table. And here  
I immediately can see that jigsaw provides the semantics for require ...

Kind regards,

	Peter Kriens










On 20 apr 2009, at 23:54, Alex Buckley wrote:

> // EG members, feel free to add/edit points I haven't noted correctly.
>
>
> * Attendees
>
> Alex Buckley, Bryan Atsatt, BJ Hargrave, Peter Kriens, Bob Lee,
> Daniel Leuck
> Apologies: Richard Hall, Michal Cierniak
>
>
> * Module dependencies in source/class files
>
> Everything there is to be said about the use of annotations for  
> dependencies has been said. Representing multiple dependencies  
> requires contortions, and a compiler is required to identify special  
> annotation types to decode dependency annotations. This is a problem  
> when types are no longer found on a global classpath. It is cleaner  
> for a compiler, and easier to read for a developer, if dependencies  
> are read and written in the language. Peter's objection is noted.
>
> Bryan proposed a syntax for 'requires' based on name:value pairs, e.g.
>
> module M @ 5.0 {
>  requires module:N  version:"1.0+" optional:true;
>  requires package:P version:"(1.0,2.0]";
>  permits  module:O;  // Module O is M's friend
>  permits  anyoneWhoRequires:4.5+;  // M v5.0 is compatible with 4.5+
> }
>
> Bryan also proposed that a module-info.java file should belong to  
> one module system only. There is a terrible loss of clarity and  
> coherence if one file contains multiple sets of dependencies each  
> with their own granularity (module/package/service) and version  
> scheme. Dan agreed that context-sensitive dependencies were  
> undesirable.
>
> Some suggestions for how to denote the "owning" module system of a  
> module compilation unit are:
>
> 1) module M @ 5.0 {..}  then  javac -modulesystem osgi module- 
> info.java
>
> 2) osgi module M @ 5.0 {..}
>
> 3) module M @ 5.0 { system osgi @ 4.2; requires package ... }
>
> Denoting the owning module system is optional. The resulting  
> classfile has an optional attribute (probably documented in the JVM  
> Spec) denoting the owning module system.
>
>
> * Next meeting
>
> Wednesday 22 April. 10am US West, 1pm US East.
>
> - Module dependency syntax and semantics
> - Plans for EDR and J1
>
>
> Alex
> _______________________________________________
> 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/20090423/bee0f1af/attachment.html>