[jsr294-modularity-eg] Difference between Compile time and Run time

[Alex Buckley]

1) 294 does not assume compile-time class space == runtime class space.

There are two obvious disparities between compile-time and runtime:
- Compile-time dependency not needed at runtime (e.g. SOURCE annotations)
- Runtime dependency not identified at compile-time (e.g. 
Class.forName("foo"))

It is up to a module system to handle these scenarios in its own way at 
resolution. 294 recognizes the existence of the scenarios thus:

- The former may be expressed with the directive_flags item in the 
ClassFile, e.g. module-info.class. This is the raison d'etre for 
ACC_IGNORED. (ACC_OPTIONAL in the early draft you saw.)

- The latter may be expressed with the 'optional' reserved keyword that 
Bryan proposed last week. Alternatively, source code analysis could 
discover runtime dependencies at compile-time and insert suitable 
dependencies marked ACC_SYNTHESIZED into the ClassFile.

These general notations give a module system much freedom.

2) 294 does not mandate module dependencies. Fan-out and refactoring are 
issues for a module system. Since you have mentioned OSGi's use of 
package dependencies, I will mention Jigsaw's use of virtual modules, 
which subsume package dependencies under certain conditions.

Alex

Peter Kriens wrote:
> As promised yesterday in the call:
> 
> The current design uses the module-info file to define the dependencies. 
> There seems an implicit assumption that the runtime class space == 
> compile time class space. However, I argue that this architectural 
> decision is too constraining.
> 
> During compile time you verify that what is available in the class space 
> matches the assumptions in the source code, it is ok to fail because 
> that reflects a user error. If the module dependencies are met, the 
> runtime is not allowed to fail. It seems to be fundamentally wrong to 
> use identical information for these different roles. The compiler can 
> use the source file but it should encode its decisions so that the 
> runtime is only confronted with actual dependencies as picked by the 
> compiler.
> 
> I raised the annotation example because it is defined in the JLS and 
> clearly shows that a compile time dependency is not the same as a 
> runtime dependency. The compiler knows exactly that CLASS and RUNTIME 
> annotations are never used in runtime and should therefore not cause a 
> runtime dependency, however, we throw away all those decisions we make 
> in compilation.
> 
> And then there is the fan-out issue. A 294 Module is a .NET 
> assembly/OSGi bundle/Ruby gem type of module because you're supposed to 
> add your module dependencies to the module-info file. This granularity 
> suffers from the fan-out problem because of the "cost", developers will 
> put many, often unrelated parts together. This will mean that the 
> dependencies will usually be larger than each part really needs. This 
> issues causes maven to download 30 Mb when you write a hello world. It 
> is crucial to minimize this chain reaction imho. By only encoding the 
> actual assumptions in the dependencies, you can minimize this chain 
> reaction.
> 
> And last but not least, the refactoring. Large scale modules like the 
> 294 modules are likely to be refactored often, moving parts to other 
> places. This will break all the modules that depend on them. This is the 
> key reason OSGi uses package dependencies because of their smaller 
> granularity packages are not as heavily refactored large modules.
> 
> To conclude, I see the use of module dependencies on source level but I 
> am afraid encoding these source level dependencies in the class file as 
> given will cause the problems outlined in this mail.
> 
> Kind regards,
> 
>     Peter Kriens
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg