[jsr294-modularity-eg] Module identity and the module access decision

[BJ Hargrave]

In the module access decision, both at compile time and at runtime, one 
needs to know whether the 2 parties are in the same module or in different 
modules.

At runtime, a module can be associated with a type when it is defined via 
a parameter to defineClass or via data in the class file. This can be 
designed to allow for a simple and fast comparison (typeA.module == 
typeB.module).

Things are much more complicated at compile time since we don't have class 
loaders to associate modules with the classes. But the compiler also needs 
to address the question of whether the access is allowed by knowing if the 
2 parties are in the same module or in different modules. (Ideally, the 
compiler also needs to know about classloaders since that is part of 
package private access.) 

In the Language change proposal from Alex, it is suggested that a source 
file indicates of which module and version the type is a member via a 
module statement in the source (module com.foo at 1.0.1;). But it is not 
clear to me how the test is made. Are two types in the same module if they 
have the same module name string? How do versions play into this test? 
Must they have the same version? Is module identity based upon the pair 
(module-name,module-version)? It has been mentioned that module membership 
can be assigned at runtime via a new defineClass method. How does this 
work with a module name and version in the class file? Does the module 
provided to defineClass override the information in the class file?

Hal's proposal suggests the we simply need a means to identify to the 
compiler which types are "in-module" and which types are "out-module". 
Knowing this, the compiler can easily answer the module access decision. I 
am very much in favor of Hal's proposal and line of reasoning.

I have strong concerns about "baking" module membership into source code 
and then class files. While this may allow a high degree of static 
analysis and reasoning, it removes a significant and necessary amount of 
flexibility. 

Java EE defines distinct roles[1] in the development of applications and 
their deployment life cycle. Of interest here are the application 
component provider and the application assembler. The application 
component provider is the one writing, compiling, debugging the source 
code. The application component provider is producing modules. The 
application assembler will then, using the pallette of available modules 
(from open source, vendors, in-house), assemble some number of modules 
into an application. There must be enough flexibility in the modules on 
the pallette to allow the application assembler to assemble and reassemble 
the application as circumstances dictate. Vendors, M&A activity and other 
circumstances will change and the application assembler will need to 
respond by changing the set of modules which make up the application.

294 must not vest "too much power" in the application component provider 
by having decisions made in the source code (which result in high 
coupling) that inhibit the possibilities of the application assembler. The 
current proposal from Alex lean too far in this direction. Things such as 
"local" and "permits" in the language place onerous restrictions on the 
application assembler's ability to substitute modules. Even things such as 
modifying version information on dependencies requires source code changes 
(module-info.java) and recompilation. Such things may not even be possible 
if the application assembler does not have the source code or if the 
license on the source code inhibits the changes.

I have a strong fear that we are heading towards a solution that may be 
academically wonderful but is not practically useful in the real (messy) 
world.

[1] 
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/platform_technologies/platform_roles/index.html
-- 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090218/f6e3feb6/attachment-0001.html>