Which class is best to call .getResource on?

I'm creating a Java Helper Library with helpful static methods. I find myself needing to call ...getResource(...) or ...getResourceAsStream(...) in several instances and I'm wondering what's the best practice for this. It seems to be working fine when I say: Helper.class.getResource(...), but I'm wondering whether that will bite me in the future.

I have a few alternatives I'm thinking of. Below is an example of when I need to use this and the alternatives I have thought of:

Alternative 1 (what I would prefer for the sake of users):

/**
* Takes the given resource and returns that as a string.
*
* @param location of the file
* @return the file as a string
* @throws IOException
*/
public static String resourceToString(String location) throws IOException {
  InputStream is = IOHelper.class.getResourceAsStream(location);
  InputStreamReader r = new InputStreamReader(is);
  return readerToString(r);
}

Alternative 2:

/**
* Takes the given resource (based on the given class) and returns that as a string.
*
* @param location of the file
* @param c class to get the resource from
* @return the file as a string
* @throws IOException
*/
public static String resourceToString(String location, Class c) throws IOException {
  InputStream is = c.getResourceAsStream(location);
  InputStreamReader r = new InputStreamReader(is);
  return readerToString(r);
}

Alternative 3 (should I just have the user give me the resource?):

/**
* Takes the given InputStream and returns that as a string.
*
* @param is the InputStream of the File to read
* @return the file as a string
* @throws IOException
*/
public static String resourceToString(InputStream is) throws IOException {
  InputStreamReader r = new InputStreamReader(is);
  return readerToString(r);
}

I would prefer the second one. The others will bite if the library runs inside an OSGi container.

Furthermore, I would

• pass UTF-8 character encoding to the constructor of the InputStreamReader. Otherwise it will use the system encoding which vary from system to system. (Or let the user to set it with a third method parameter.)

• use longer variable names. is, r, c are not too easy to read. I would call them resourceStream, clazz and resourceReader. It does not force readers to decode them.

• reverse the order of String location, Class c parameters. It would be in the same order as the first line use them (c.getResourceAsStream(location)). I don't know if there is a rule of thumb for this, but it looks more natural to me. (Any pointers are welcome.)

• remove the * @throws IOException javadoc line. It is meaningless in this form.

StackExchange Code Review Q#11290, answer score: 3