For Class.getResourceAsStream(String name), 

• if the name parameter doesn't start with a "/", then it's a relative path to the class's package.
• If the name parameter starts with a "/", then it's an absolute path.

For ClassLoader.getResourceAsStream(String name), 

• the name parameter is always an absolute path.
• and it can never start with a "/",if it does, the resource is never found.

If the file cannot be found, both methods return null and no exception is thrown.

The following program illustrates the difference.

Project structure

ResourceAsStream.java

public class ResourceAsStream {

    /**

     * @param args

     */

    public static void main(String[] args) {

        String path1 = "a.properties";

        String path2 = "/a.properties";

        String path3 = "test/a.properties";

        String path4 = "/test/a.properties";

        System.out.println("Class.getResourceAsStream()");

        InputStream is = ResourceAsStream.class.getResourceAsStream(path1);

        System.out.println(path1 + " " + (is != null));

        is = ResourceAsStream.class.getResourceAsStream(path2);

        System.out.println(path2 + " " + (is != null));

        is = ResourceAsStream.class.getResourceAsStream(path3);

        System.out.println(path3 + " " + (is != null));

        is = ResourceAsStream.class.getResourceAsStream(path4);

        System.out.println(path4 + " " + (is != null));

        System.out.println();

        System.out.println("ClassLoader.getResourceAsStream()");

        is = ResourceAsStream.class.getClassLoader().getResourceAsStream(path1);

        System.out.println(path1 + " " + (is != null));

        is = ResourceAsStream.class.getClassLoader().getResourceAsStream(path2);

        System.out.println(path2 + " " + (is != null));

        is = ResourceAsStream.class.getClassLoader().getResourceAsStream(path3);

        System.out.println(path3 + " " + (is != null));

        is = ResourceAsStream.class.getClassLoader().getResourceAsStream(path4);

        System.out.println(path4 + " " + (is != null));

    }

}

Result:

Class.getResourceAsStream()

a.properties true

/a.properties false

test/a.properties false

/test/a.properties true

ClassLoader.getResourceAsStream()

a.properties false

/a.properties false

test/a.properties true

/test/a.properties false

JDK explanation about this two method

Class.java

public InputStream getResourceAsStream(String name)

Parameters:

name - name of the desired resource

Returns:

A InputStream object or null if no resource with this name is found

Throws:

NullPointerException - If name is null

ClassLoader.java

public InputStream getResourceAsStream(String name)
Returns an input stream for reading the specified resource.
The search order is described in the documentation for getResource(String).
Parameters:
    name - The resource name
Returns:
    An input stream for reading the resource, or null if the resource could not be found
Since:
    1.1

public URL getResource(String name)
Finds the resource with the given name. A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code.
The name of a resource is a '/'-separated path name that identifies the resource. --here it means absolute path

This method will first search the parent class loader for the resource; if the parent is null the path of the class loader built-in to the virtual machine is searched. That failing, this method will invokefindResource(String) to find the resource.

Parameters:
name - The resource name
    Returns:
A URL object for reading the resource, or null if the resource could not be found or the invoker doesn't have adequate privileges to get the resource.
    Since:
1.1

below from http://www.javaworld.com/article/2077404/core-java/got-resources-.html

Because Class.getResource() eventually delegates toClassLoader.getResource(), the two methods are indeed very similar.

However, the first method is often preferable. It provides a nice extra feature: it looks up package-local resources.

As an example, this code snippet getClass().getResource("settings.properties"); executed from a class some.pkg.MyClass

looks for a resource deployed a ssome/pkg/settings.properties.You might wonder why this is better then the equivalent

getClass().getClassLoader().getResource("some/pkg/settings.properties");

The reason is the possibility for future refactoring. Should you decide to rename pkgto betterpkgname and move all classes and resources into the new

package, the first code snippet requires no further code changes. The second code snippet embeds the old package name in a string literal—something that

is easy to forget and can become a runtime error later. Another advantage of Class.getResource() is that it does not require thegetClassLoader runtime

security permission, which the other approach requires.

I should mention a few extra details. Is it better to acquire the relevant Class object using the getClass() instance method or using MyClass.class?

The answer depends on whether you plan to have classes in other packages extend MyClass.

Since get Class() always returns the most derived class, it might return a class in a package different from some.pkg, possibly coded after MyClass is

conceived. If this is a possibility, you should safeguard against potential lookup errors by using the class literal syntax form, MyClass.class. As an added

benefit, it also works from static methods.