Start with a JAR file that contains a JAX-WS SPI text file in /META-INF, and then the class to which it points. Put it into the classpath. Set the contextClassLoader for the current thread to null.
Call the Service class from the JAX-WS API in JDK 1.6, and start stepping through it. In the absence of a context class loader, this code will call static methods of Class to find things.
It will successfully find the SPI file. But it won't find the .class that it names.
If you really want to try this for yourself, grab Apache CXF 2.2.10, put it on classpath, and null out the context class loader.
This wasn't an exercise in pointless masochism: it turns out that when Open Office invokes a Java Extension ('UNO'), it leaves the context class loader null. It took some significant proctology archeology to figure this out. Which left me wondering, is there a JDK bug that explains the inconsistent results, or some specified behavior that I don't understand?
There have been various bugs raised for this sort of thing; e.g. scan the results of this query. The general Sun response is that these are features not bugs, and will not be fixed; e.g. https://bugs.java.com/bugdatabase/view_bug?bug_id=4155645.
The bottom line is that getContextClassLoader can return null.