[jsr294-modularity-eg] Simple Module System Proposal
Richard S. Hall
heavy at sun.com
Tue Sep 29 06:00:07 EDT 2009
On 9/24/09 20:16, Alex Buckley wrote:
> BJ Hargrave wrote:
>> > For the users I have in mind, multiple loaders and dynamism are edge
>> > cases, configurable through module-system-specific annotations.
>> The set of users you have in mind is not interested in modularity.
>> Just named and versions jar files which express dependencies on other
>> named and versioned jar files. Having named and versioned jars files
>> is fine and has proven useful to a large audience of maven users. But
>> doing that does not require Java language changes and module-info
>> source files. Putting a name and a version on a jar file does not
>> make it a module.
> If I may summarize: Applications are, in your view, either so simple
> as to need only basic Maven-like functionality, or so complex as to
> need dynamic visibility over multiple versions with strong encapsulation.
> This echoes Peter's view that "Nobody needs modularity for a Hello
> World program, and letting this use case drive the design seems plain
> wrong" and "small applications do not have to bother with modularity".
> If Maven suffices for versioning and dependency tracking - not "real"
> modularity but still of some value, in your view - why does the Simple
> Module System claim the same ground by standardizing versions and
> dependencies in the language?
To me, this line of discussion completely misses the important point. If
294 modules are required to be loaded by a single class loader, then
they are useless in any environments that are either dynamic or support
side-by-side versions, which throws their reuse out the window. Thus,
there is very little benefit of the SMS proposal over the "big hook"
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer