[jsr294-modularity-eg] Requirements for modules in the Java language

[Alex Buckley]

Yes, splitting a package across multiple modules at compile-time and 
runtime is possible in OSGi and will be possible in Jigsaw too.

Whether types in that package are loaded into different classloaders (as 
I think Require-Bundle would assure) or the same classloaders (as a 
Jigsaw module loader could attempt) is a matter for requirement 10.

(Incidentally, it is difficult for a compiler to check that all source 
and classfiles within a package belong to the same module, since a 
compiler typically reads the source files it is given plus the 
source/classfiles referred to therein, and that's it. Unrelated 
source/classfiles that happen to be in a package it's compiling for are 
not of concern. So the requirement fits with that.)

Alex

Bryan Atsatt wrote:
>  > 4. It must be possible for different types in a single Java package to
>  > belong to different modules.
> 
> This is in support of OSGi's split-package (via Require-Bundle)? Are 
> there other expected use cases?
> 
> // Bryan
> 
> Alex Buckley wrote:
>> Comments welcome.
>>
>>
>> * Principles of modules in the Java language
>>
>> JSR 294 introduces the notion of "module" to solve the problems listed
>> previously.
>>
>> A module is a named set of packages that a) defines an encapsulation
>> boundary for its member types, b) describes its relationships with other
>> named modules, and c) enforces both encapsulation and relationships at
>> compile-time and runtime. A module is identified by a name and
>> optionally a version.
>>
>> Modules are part of the language to be delivered in the Java SE 7
>> platform, so can assume the use of an SE 7-compliant compiler, JVM, and
>> ClassFile format. In the SE 7 platform, a Java compiler cooperates with
>> a module system to enforce encapsulation and relationships at
>> compile-time. A JVM cooperates with a module system to enforce
>> encapsulation and relationships at runtime.
>>
>>
>> * Requirements for modules in the Java language
>>
>> 1. A module-private modifier for access control must be supported for
>> classes, interfaces, and their members. An artifact so modified can only
>> be accessed from types in the same module as the artifact.
>>
>> 2. It must be possible for the Java language to compute the module to
>> which a type belongs, to enforce access control.
>>
>> 3. It must be possible for types in different packages to belong to the
>> same module.
>>
>> 4. It must be possible for different types in a single Java package to
>> belong to different modules.
>>
>> 5. A module must be declared in a form which allows annotations to be
>> placed on it.
>>
>> 6. A module must be able to declare dependencies on other modules, by
>> specifying their identities in the Java language. The effect of a 
>> module M declaring a dependency on module N, where N does not 
>> otherwise restrict M's dependency, must be to make the public types of 
>> N observable at compile-time and runtime to all types in M.
>>
>> 7. A module must be able to declare multiple identities by which it may
>> satisfy another module's dependency.
>>
>> 8. A module must be able to restrict which other modules can declare a
>> dependency on it.
>>
>> 9. It must be possible for a module's dependency on another module to be
>> marked such that observable public types in the latter are "re-exported"
>> by the former. That is, if module L depends on module M, and module M
>> depends on module N, then M must be able to specify whether the
>> observable types of N are observable to L.
>>
>> 10. It must be possible for a module's dependency on another module to
>> be marked such that the same defining classloader is used for all types
>> in both modules.
>>
>> 11. It must be possible for a module's dependency on another module to
>> be marked as optional.
>>
>> 12. It must be possible for unit and regression tests outside a module
>> to access module-private artifacts within the module.
>>
>> 13. The Java language must not directly use the value of the version in
>> a module's identity, but may rely on the presence or absence of a
>> version in a module's identity.
>>
>>
>> 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
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg