module-info platform dependencies

[Mark Reinhold]

> Date: Thu, 14 May 2009 22:13:49 -0700
> From: jonathan.gibbons at sun.com

> On May 14, 2009, at 9:20 PM, Mark Reinhold wrote:
>> The basic idea is that the compiler can ask Jigsaw whether a
>> particular dependence is upon a known, available platform or profile
>> module, and it can also ask what the default is.  If a module-info
>> file declares at least one dependence upon a platform module then the
>> compiler does nothing.  If it does not declare such a dependence then
>> the compiler inserts a dependence upon the default.
>> 
> It's not clear to me why the compiler should be doing this and/or its
> not clear to me what the right policy is here.
> 
> It's not clear the compiler should be doing this because so much else
> is being deferred to the module system, why is this piece of analysis
> coming back into the compiler?  I'm not saying it shouldn't; I'm just
> saying I don't yet understand why.

It's a fairly trivial analysis on the compiler's part, and it is in this
case deferring to the module system, to identify platform modules and to
specify the default.

> One reason it may be more of a compiler function is future interaction
> with the compiler's -source and -target flags.  Although rarely used
> correctly, -target should normally be used in conjunction with
> -Xbootclasspath.  In the JDK 8 timeframe, when it may make sense to
> compile for JDK 7 or JDK8, the -target switch might interact with
> and/or influence the default of the platform dependence.

Exactly.  When you compile a module-info file with JDK 8 using -target 7
then the platform dependence would default to, say, jdk@>=7.

This reminds me of a related issue which we've discussed but not yet
settled: For dependences upon platform modules, at least, and possibly
in all cases, javac should probably be asking the module system for the
oldest available module satisfying the dependence's version constraint,
rather than the newest.

> If the compiler were to add a default, would you expect it to get
> compiled into the class file?

Into the module-info class file?  Yes.  Into other class files?  No.

> It also seems to me that a case can be made for the module system to
> analyze the need for a default for a group of modules, in that if the
> set of leaf modules do not unambiguously specify a default, then the
> module system should specify one for the group. But there should not be
> a need for anyone (such as the compiler) to insert additional
> dependences into all modules that don't specify a platform when those
> modules will have an indirect dependence by virtue of the transitive
> closure of their own (explicit) dependencies.

A module that does not declare a direct dependence upon a platform module
will only have an indirect dependence upon a platform module if there is
a transitive path of public dependences from that module to a platform
module.  I don't expect that to be the case, i.e., I expect people will
generally write

    module foo @ 1 {
        requires jdk @ >=7;
    }

rather than

    module foo @ 1 {
        requires public jdk @ >=7;
    }

when declaring a specific platform dependence.

>                                                That sort of group wide
> analysis belongs in the module resolver/system, not in the compiler.

I'm not asking that the compiler do any sort of group-wide analysis, and
I completely agree that such analyses are best done by the module system.

If the compiler inserts default platform dependences as I've suggested,
by doing a simple local analysis of each module, then the group-wide
analysis you describe above will be performed by the current resolution
algorithm, without change.

- Mark