DRAFT: Project Jigsaw: The Big Picture (part 1)

[mark.reinhold at oracle.com]

2011/12/20 20:17 -0800, david.lloyd at redhat.com:
> The terms 'library' and 'module path' could use a definition in that section.

Those terms are given brief inline definitions when introduced.  They'll
be explained more fully later on, in sections still being written.

> It should maybe be somewhat more clear that the installation of modules into a
> module repository (library?) requires special tooling, and that modules are not
> editable in-place; these are both things which will break most developers'
> assumptions going in.

These points will be made in a forthcoming section.

> The role of Jigsaw's versioning scheme at the different phases could be
> clarified somewhat.  It could be made more clear that Jigsaw imposes a single
> version scheme and thus a single module repository format (that's how it
> appears at least).
> 
> It is worth clarifying that in the Jigsaw model, nothing is exported by
> default.  There seems to be no provision for filtering the set of packages,
> classes, and/or resources which are imported from a dependency.
> 
> The disposition of META-INF and resource (non-package) directories is not
> clear, especially in terms of export and import behavior.

I'll make a note to clarify these points.

Re. single library format: Yes, there's only one.

Re. filtering: You're right, there is at present no way to do that.
We haven't yet seen any use cases for it.

Re. META-INF and resources: Our current thinking is that these are not
subject to import or export; they're just part of a module's private
data.  If a module needs to export resources then it can do so via the
ResourceBundle facility, which will be enhanced to export resources in
terms of services (though the details of that remain to be worked out).

> Negative dependencies would add a great deal of complexity; I would advise
> against it (think of Windows NT ACLs and their mixed allow/deny rule sets;
> experts knew the best practices but most people just screwed them up).

I agree they'd add complexity, and I'd prefer to avoid them unless there
are strong use cases in their favor.

> One key guiding principle seems to be missing: keep it simple...

Well, we've tried to keep it as simple as possible given our goals and
constraints.  Suggestions for ways to make it simpler are welcome.

Bear in mind that most developers will never need to think about permits
clauses, local dependences, or views.  I'll see if I can reorganize the
next draft to separate the fundamental features from those that are for
more advanced scenarios.

- Mark