Jim Knutson wrote on 12/12/12 12:14:
> Bill Shannon <bill.shannon_at_oracle.com> wrote on 12/12/2012 01:48:16 PM:
>> 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?
>
> Reflection isn't reliable for indicating the configuration
> of a service, just the presence of a class. To keep this
> simple, there could be a case where EE full profile is
> available on disk, but only the web profile or some other
> subset is configured to run. Using reflection might load a
> specific class, but it doesn't mean that the server runtime
> has been appropriately configured to provide that service.
If those classes are available (can be loaded), they have to
meet all the corresponding Java compatibility requirements.
If you don't want to provide (e.g.) EJB functionality in your
Web Profile product, the EJB classes must not be accessible
to the application.
I won't be surprised if there are some cases where class
accessibility is not sufficient to tell you what to do. We
don't have a general solution to that problem. Hopefully it's
a relatively rare problem so that's ok. That's why I'm
interested in examples where class accessibility is not sufficient.
If there turn out to be a lot of such cases, we may need to create
a general solution.
Perhaps the great white hope, er, Java module system will provide
a more general solution by allowing to you to query for the presence
of a specific module.