8182482: Module System spec updates

[Hamlin Li]

Hi Alan,

Thank you for explanation, it's much clear for me.


Besides of it, I have some minor comments about the doc:


In section "Timing of provider discovery", it says as below:

Each invocation of the|iterator|method returns an|Iterator|that first 
yields all of the elements cached from previous iteration, in 
**instantiation order**, and then lazily locates and instantiates any 
remaining providers, adding each one to the cache in turn.

But in API doc for iterator(), it says:

Caching: The iterator returned by this method first yields all of the 
elements of the provider cache, in **the order that they were loaded**.


In API doc for findFirst(), it says:

Load the first available service provider of this loader's service.

By comparing to API doc of iterator() and stream(), should above line be 
"Load *and *instantiate** the first available service provider of this 
loader's service."


Thank you

-Hamlin


On 2017/6/21 15:51, Alan Bateman wrote:
> On 21/06/2017 07:10, Hamlin Li wrote:
>> :
>>
>> It's possible to have 2 public static no-args method "provider" in a 
>> service provider *class file*, JVM spec allows it,
> Right, you can't do this in the Java Language but the JVMS allows it. 
> The most obvious usage of this "feature" is covariant return types 
> where the java compiler will generate a bridge method with the less 
> specific return type from the superclass. In the Core Reflection APIs 
> then getMethods and getMethod need to deal with this so that the user 
> of API only sees the overriding method.
>
>
>>
>> And I still have questions:
>> Why need to have this restriction in java API doc? 
> For completeness only as it's one of the reasons why SCE is thrown. 
> Note that it's also not "new" in this update, instead the wording for 
> many of the error cases has been refreshed.
>
>
>
>> Will there be corresponding update in JVM spec? When will this 
>> restriction be verified, at linking time?
> No impact.
>
> -Alan