[jsr294-modularity-eg] 294 EG conf call, 2009-02-18
Alex.Buckley at Sun.COM
Thu Feb 19 18:48:30 EST 2009
// EG members, feel free to add/edit points I haven't noted correctly.
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
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.
More information about the jsr294-modularity-eg