[jsr294-modularity-eg] 294 EG conf call, 2009-04-08

[Peter Kriens]

I think you are highlighting one of the main issues I felt when we  
started this approach. There are two views to modules that need to be  
addressed separately. Interestingly, .NET seemed to have addressed  
this with the "internal" keyword and nested namespaces.

- Is a module a JAR that contains a collection of different  
functionalities?
- Is a module as packages should have been?

My nested approach tried to merge these two concepts, giving a  
deployment module concept (top level modules) as well as namespace  
modules. I think Alex (Sun) wants to have its cake and eat it too with  
one type of module for both targets.

Kind regards,

	Peter Kriens


On 21 apr 2009, at 09:33, Roman Elizarov wrote:

> Hello Alex!
>
> It is clear that you work from the assumptions that are opposite to
> mine. You write:
>
> AB> Finding module-info is easy when each package becomes a module,
> AB> but that's not the common case. The common case is multiple
> AB> packages joining a module.
>
> I belive that the most common case is the opposite -- a single package
> will become a module in the majority of cases, since most libraries
> are simple.
>
> AB> As for module names, we don't know how they will be structured.
> AB> Linux distros cope quite well with short names (+versions) for
> AB> rpm/deb files.
>
> They do. But I belive that this is a bad naming practice and should be
> discouraged. We don't need yet another names space and naming
> convention for modules. When I use a library, why do I have to
> remember an additional piece of information (its module name) in
> addition to its package name? When we are talking about "language
> modules" we (language designers) should impose or suggest the naming
> convention to the users of that language. If we don't know how they
> will be structured, then we probably should not make it a language
> feature. Leave it out of the language and stick with deployment-only
> modules, then.
>
> AB> A non-answer is "module membership in A.java and B.java", since
> AB> the EG has clearly expressed its opposition to that. Another
> AB> non-answer is "a command-line switch", since that means only one
> AB> module at a time can be compiled.
>
> What is the problem with "package declares module membership in its
> package-info" approach?
>
> Sincerely,
> Roman Elizarov
>