module-info platform dependencies

[Jonathan Gibbons]

On May 15, 2009, at 8:44 AM, Mark Reinhold wrote:

>> 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

So can you give me a method that maps a target number into an equivalent
version query, or do I hard-code  ("jdk@>=" + targetValue) into the  
compiler?

"jdk" seems like the wrong name to use eventually.  If you're writing  
it into the
module-class file, we don't want to constrain apps to run on a large  
platform.
But, it'll do for now.

-- Jon