Normally I would expect reflection to be used to access the class from the other
spec that you would use, if it were there. Are there cases where that's not
sufficient?
Jim Knutson wrote on 12/12/12 11:22:
>
> We have a number of specs that are now defining requirements along the lines
> of "when running in an environment that supports XYZ specification, you must
> do blah blah blah." However, there is no common way to determine if an
> environment actually supports XYZ.
>
> In a modular runtime, we could get notified when a specific service was
> registered in a service registry. Maybe someday we will get there, but in the
> meantime, is there some common pattern we can use to declare that XYZ is
> available in the environment? Possibilities that come to mind are well known
> JNDI name strings or system properties. A more sophisticated pattern would be
> to bind an SPI to the JNDI name that provided state (i.e. the service is
> initializing or ready to receive requests). Anyway, I think it would be nice
> if we could come up with a more portable way to deal with these "optional"
> behaviors defined in the specs.
>
> Thanks,
> Jim Knutson
> WebSphere Java EE Architect
>