[jsr294-modularity-eg] 294 EG conf call, 2009-02-18

[Alex Buckley]

// EG members, feel free to add/edit points I haven't noted correctly.


* Attendees

Alex Buckley, Sam Pullara, Bryan Atsatt, Richard Hall, Michal Cierniak, 
BJ Hargrave, Peter Kriens, Daniel Leuck, Doug Lea


* Scope of language changes

Complete support that a module-private accessibility level is 
worthwhile. Daniel's experience in .NET is that "internal" accessibility 
(a.k.a. module-private) is very common.

General support for module membership in package-info.java, and in the 
main for module membership in individual source files.

Complete support for NOT giving a version when module membership is 
declared in source or in the Module attribute of a normal classfile.

Complete support for modifying defineClass() to allow a classloader to 
set a class's module membership at runtime, regardless of the content of 
the classfile.

Some support for no module membership in source, but having versioned 
dependencies there instead.

A compiler switch has been proposed to set the module membership of 
source files provided on the command line if they (or their package-info 
files) do not already declare such membership. This isn't good enough 
for implicit dependencies, e.g. if A.java is compiled explicit but its 
requires B.java to be (re)compiled, then a command-line flag cannot 
easily give B's module or the modules for its implicit dependencies. 
General support for dropping the switch and having the compiler get 
module membership for B from a package-info file, which may or may not 
live in the same directory tree as B.

Peter's container model also addresses implicit module membership. Some 
support for this model. Will discuss more next time.

Will discuss BJ's mail "Module identity and the module access decision", 
and the power vested in the provider v. the assembler, next time.

General support for BJ's criticism of friends. Some support for the view 
that friendship is a feature asked for so often that it is inevitably 
provided and people trusted to use it wisely.

Annotations on modules: strictly, only possible if modules have a source 
representation. Since the current spec assumes they do, they must be 
annotatable. Use cases for module-level annotations would be welcome.


* Next meeting

Wednesday 25 February. 10am US West, 1pm US East, 7pm France.

- Alex to report on issue tracking.
- Peter to continue explanation of Nested Modules.
- Discuss BJ's points about what features properly belong in the 
language v. a module system.
- Discuss face-to-face meeting at EclipseCon in March.


Alex