Module-system requirements

[mark.reinhold at oracle.com]

2015/2/13 6:30 -0800, wayne at eclipse.org:
> Hi Mark. Thanks for this. I have a couple of questions/thoughts:
> 
>> /Greater platform integrity/, to ensure that code that is internal to 
>> a platform implementation is not accessible from outside the 
>> implementation;
> 
> In principle, I agree 100% with this. I imagine, however, that it won't 
> take too long to find (many) examples where internal code is accessed. 

Oh my, no -- it doesn't take long at all!

> If this is strictly enforced, then we're going to break a lot of code. 
> How strong of a requirement is this?

As I wrote in my reply to Tim, this is an important topic but it's more
within the realm of the Java SE 9 EG than this EG.  The important thing
here is that we design a module system that can be used to achieve
strong platform integrity but can also, when necessary and appropriate,
be used to violate that integrity so as to keep legacy code working.

> ...
> 
>> /Upgradeable modules/— If a Java SE module exports an endorsed
>> standard or standalone technology  ...
> 
> I think that "Upgradeable modules" may be at odds with the next 
> statement. Or maybe not. Taken together, an upgrade of a module 
> necessitates the removal of the original (if both are in place, then 
> some sort of resolution to pick one over the other is required).

I think of this more in terms of shadowing than removal.  If, e.g., a
run-time image already has a particular upgradeable module baked in, and
a newer version is provided when the image is invoked, then the run-time
resolver will only consider the newer version.  So while both versions
of the module are present, in some sense, only the upgraded version is
actually used.

> Also, taken in combination, it suggests that the binary-compatibility 
> must be guaranteed by the deployer (i.e the framework has no mechanism 
> to check).

Hmm.  We could validate binary compatibility mechanically, but I don't
know if that would wind up being too restrictive in practice.  What if
the maintainer of an upgradeable module had a good reason (e.g., to fix
a security bug) to violate binary compatibility?

>> * /Version selection/— The process of configuring a set of modules
>> need not consider more than one version of any particular module.
> 
> I get that Ivy, Maven, and Gradle all do dependency resolution and I 
> totally get the desire to avoid duplicating behaviour, but my experience 
> with Eclipse/OSGi is such that runtime dependency resolution is 
> different from build-time dependency resolution.

Remember that there's still a notion of run-time resolution, it's just
that it's (intentionally) very simple.  It can give a result that's
different from build-time resolution, but it's not going to do anything
fancy like run a SAT solver or try to apply clever dependency-management
heuristics.

> Of course, it's probably the case that what we have here is exactly what 
> ~99% of the Java community requires.

Yes, that's the aim.  IDEs, app servers, and other sophisticated types of
applications will always require something more, so let's make sure that
the dynamic-configuration requirements make that possible while keeping
it easy for simpler applications to leverage the module system.

- Mark