[jsr294-modularity-eg] 294 EG conf call, 2009-04-15
BJ Hargrave
hargrave at us.ibm.com
Wed Apr 29 12:49:25 EDT 2009
I think Peter properly points out the absurdity of defining specific
keywords (require, export, etc). Since the keywords have open ended
operands, the keywords themselves have no meaning.
Even having these keywords is a result of the decision to put the module
information in class files. This information would be much better
expressed as annotations but since the module info is a class file, it
must be loaded in an indeterminate class loader state (since this class
file contains the dependent modules necessary to have a determinate class
loader state). As such, loading the annotation classes is a major
chicken-and-egg issue. So now some of the module data is expressed as
keywords and the rest as annotations. The keywords are only because we
can't put them in annotations because we can't load the annotation classes
because we don't have a determinate class loader state yet (whew).
To me is seems patently wrong to have to load a class file (in an
indeterminate class loading state) in order to define the class loader
state for loading classes. One way I think of this is that this is
equivalent to putting javac command line switches in a class file. javac
has to compile/read a class file in order to know how to set the compiler
up to compile the source files. This just screams that the module
information should not be in class files and should be in some text
format. Putting it in class files also makes it very awkward for
management systems to reason about modules.
The argument that javac must only process java source files and not text
files seems quite absurd now. The module info source files as now proposed
look very little like java source code. We now have a DSL that sort of
looks like java but isn't. Why don't we just admit this and design a DSL
for a text file that javac and the module systems can read?
--
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:
Peter Kriens <peter.kriens at aqute.biz>
To:
JSR 294 Expert Group <jsr294-modularity-eg at cs.oswego.edu>
Date:
2009/04/23 03:44
Subject:
Re: [jsr294-modularity-eg] 294 EG conf call, 2009-04-15
Sent by:
jsr294-modularity-eg-bounces at cs.oswego.edu
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
_______________________________________________
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/20090429/8a466ec2/attachment.html>
More information about the jsr294-modularity-eg
mailing list