[jsr294-modularity-eg] Difference between Compile time and Run time
Alex.Buckley at Sun.COM
Tue Jul 14 14:37:39 EDT 2009
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.
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.
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
> 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
> 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
More information about the jsr294-modularity-eg