Module-system requirements

[Wayne Beaton]

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. 
If this is strictly enforced, then we're going to break a lot of code. 
How strong of a requirement is this?

>  *
>
>     /Upgradeable modules/— If a Java SE module exports anendorsed
>     standard or standalone technology
>     <http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html>then,
>     given a particular implementation of the platform, it must be
>     possible to use abinary-compatible
>     <http://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html>version
>     of that module from a later release of that implementation.
>
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).

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).
>
>   * /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.

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

Wayne


On 11/02/15 01:38 PM, mark.reinhold at oracle.com wrote:
> I've posted a first draft of a requirements document, here:
>
>    http://openjdk.java.net/projects/jigsaw/spec/reqs/01
>
> This is distilled from the draft Goals & Requirements document for the
> overall modularization effort [1], omitting items that are beyond the
> scope of the module system itself and rewording others as necessary.
>
> As noted in the introduction, the intent of this document is to serve
> as a set of guideposts for this EG.  The specification we produce will,
> ultimately, satisfy all of these requirements.  After we finalize this
> document it will certainly be possible to revise it, but the bar for
> doing so will be relatively high.
>
> This is the first draft, and I'm sure you'll all have many comments and
> suggestions.  I'd like to finalize the requirements by the end of this
> month (February 2015), so fire away!
>
> - Mark
>
>
> [1]: http://openjdk.java.net/projects/jigsaw/goals-reqs

-- 
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon 2015 <http://www.eclipsecon.org/na2015>