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
