[jsr294-modularity-eg] Scope

Fri May 1 17:51:06 EDT 2009

I did not specifically comment on requirement 6 in [4].

6 as stated has issues given were we are now anyway. It does not include 
dependency types other than module-level dependencies. Other module 
systems will have other dependency types (for example, packages and 
fragments in OSGi.)

This is where we get to difficulty in how dependencies can be specified 
for 294[1]. Since we need to allow for different kind of dependencies and 
the type of dependencies vary based upon the module system, we are 
proposing a "requires" language keyword which takes an open ended 
argument[2] which can only be validated by the target module system. That 
is, the JLS can specify the keyword but can say nothing about the 
arguments. All the JLS (or JVMS) can say is that the arguments must be 
stored in the module-info (class) file in a certain way. 

We also discussed needing a "provides" keyword as a counterpart to 
"requires". The kinds of things a module can provide are again module 
system specific,  can only be validated by the target module system, and 
so the JLS/JVMS must allow for an open ended argument which is packaged in 
the module-info file in a certain way.

This of course implies that a compiler needs to know how to locate a 
module system and have an interface to it by which the module system can 
receive and validate the requires and provides operands and also supply 
types to the compiler as requested during compilation (similar to what a 
module system will need to do at runtime.)

This definition of requires and provides are generalized enough that they 
are useful and necessary for any module system (or dependency resolution 
system). However we (the EG) get into trouble as we step beyond these 2 
keywords. "permits" has been proposed for a module-friends concept desired 
by Jigsaw but having no analog in OSGi. OSGi might like a "classpath" 
keyword (see Bundle-ClassPath) since the OSGi module system will need that 
information to properly locate types in an OSGi bundle when requested by 
the compiler (or at runtime).

Since there has been resistance in the EG to having an open ended set of 
keywords in which permits, classpath, etc. could be defined by a given 
module system, we seem to be left with using annotations as a means of 
extending (beyond that semantically suggested by requires and provides) 
the module data in the module-info file. Since OSGi must have the 
classpath data to properly locate types in an OSGi module (for the 
compiler or at runtime), a module-info file for OSGi must include an OSGi 
@Classpath annotation (for anything other than the default classpath) 
which seems to me will end up with the same "chicken-and-egg" annotation 
class loading issues we are told disallow requires and provides from being 
annotations. Assuming this is indeed the case and that the keywords are 
limited to requires and provides, an OSGi module will likely be required 
to specify the classpath via the requires or provides keyword so that the 
classpath data is available to the OSGi module system even though, 
semantically, the concept of classpath does not fit into requires or 
provides. For example:

{
        system osgi;
        requires classpath path="/,somejar.jar";
        ...
}

So we are still working through a number of issues on how module 
dependencies are to be specified. We have general consensus on the module 
access modifier ("accessibility") but we are far from in full agreement on 
the module data in module-info which is used to establish dependencies 
thus visibility ("visibility"). If I understand Peter's concerns here, 
Peter is saying: lets focus upon what we agree ("accessibility") and punt 
upon what we don't ("visibility"). At least for now.

[1] I have already stated my objections to using a class file over a text 
file for the module data, so I wont rehash that.
[2] We discussed regularizing the syntax form of the argument to be like 
annotations for developer familiarity and so that the compiler can provide 
some syntactic error detection. But within such a syntax framework, the 
content of the argument are still open ended.
-- 

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:
Alex Buckley <Alex.Buckley at sun.com>
To:
JSR 294 Expert Group <jsr294-modularity-eg at cs.oswego.edu>
Date:
2009/04/24 02:31
Subject:
Re: [jsr294-modularity-eg] Scope
Sent by:
jsr294-modularity-eg-bounces at cs.oswego.edu

// BJ, please read, there's a question for you at the end!

Peter,

The links you gave are rather out of date. Superpackages are so 2007!

I clearly placed visibility in scope when 294 restarted in 2009 [1] [2] 
[3]. BJ commented at the time [4] on how some requirements described 
properties of a module system and were therefore outside the scope of 
294; I promised to remove them and the corresponding language 
constructs. But I do not recall BJ arguing specifically against 
requirement 6:

6. A module must be able to declare dependencies on other modules, by 
specifying their identities in the Java language. ...

BJ's other mail at the time [5] dealt primarily with module membership 
(where we all now agree) and made only the slightest passing reference 
to dependencies.

Certainly, Peter, the EG minutes show you have led the charge against 
dependencies in source. But perhaps I have underestimated BJ's concern 
about visibility, and he believes it should not be in scope?

Alex

[1]
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000184.html

[2]
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000186.html

[3]
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000187.html

[4]
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-February/000211.html

[5]
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-February/000213.html

Peter Kriens wrote:
> As a matter of order, I'm having a bit of problem where we are ending up 

> in the JSR 294 effort.
> I made it very clear before we started that I was interested in the 
> accessibility aspects of JSR 294; I fully supported Richard's proposal 
> to focus on that hard nut instead of visibility. My motivation was 
> mainly driven by Mark Reinhold's promise:
> 
>     ... Sun plans now to work directly with the OSGi Alliance so that a
>     future version of the OSGi Framework may fully leverage the features
>     of JSR 294 and thereby achieve tighter integration with the
>     language. [1]
> 
> 
> However, we seem now to have ended up at attempting to develop a module 
> system in the Java language that happens to be Jigsaw in disguise. This 
> is neither in the original scope of Jigsaw, nor JSR 294. To quote Mark 
> Reinhold on Jigsaw (underlining mine):
> 
>     This effort will, of necessity, create a simple, low-level module
>     system whose design will be focused narrowly upon the goal of
>     modularizing the JDK. This module system will be available for
>     developers to use in their own code, and will be fully supported by
>     Sun, but it will not be an ofﬁcial part of the Java SE 7 Platform
>     Speciﬁcation and might not be supported by other SE 7
>     implementations. [1]
> 
> 
> And one only has to read [2], the superpackages blog that founded JSR 
> 294, that JSR 294 was focused on accessibility and left the visibility 
> to JSR 277. This was confirmed in [3], and [4] from Alex when he 
> introduced the module keyword.
> 
> Let's face it, defining the semantics of the module keyword already 
> seems a daunting task enough, but at least achievable.
> 
> Kind regards,
> 
> Peter Kriens
> 
> [1] http://blogs.sun.com/mr/entry/jigsaw
> [2] 
http://blogs.sun.com/gbracha/entry/developing_modules_for_development
> [3] http://blogs.sun.com/andreas/entry/superpackages_in_jsr_294
> [4] 
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2008-March/000171.html

> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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/20090501/413f7145/attachment-0001.html>