The following paragraphs in the specification are somewhat confusing and can lead to different interpretations:
An implementation MAY provide alternate mechanisms for locating resource classes and providers (e.g. runtime class scanning) but use of Application is the only portable means of configuration.
It is RECOMMENDED that implementations support the Servlet 3 framework pluggability mechanism to enable portability between containers and to avail themselves of container-supplied class scanning facilities. When using the pluggability mechanism the following conditions MUST be met:
If no Application subclass is present, JAX-RS implementations are REQUIRED to dynamically add a servlet and set its name to javax.ws.rs.core.Application and to automatically discover all root resource classes and providers which MUST be packaged with the application.
When an Application subclass is present in the archive, if both Application.getClasses and Application.getSingletons return an empty collection then all root resource classes and providers packaged in the web application MUST be included and the JAX-RS implementation is REQUIRED to discover them automatically by scanning a .war file as described above.
The annotation @Provider is used by a JAX-RS runtime to automatically discover provider classes via mechanisms such as class scanning. A JAX-RS implementation that supports automatic discovery of classes MUST process only those classes that are annotated with @Provider.
The intent was to make class scanning a requirement only when running on top of servlet (and using the pluggability mechanism). However, the text above can be interpreted as implying that class scanning is required in other cases.