Why do you use FileInputStream during development? Why not just use getResourceAsStream from the very start? So long as you place your files in an appropriate place in your classpath, you shouldn t have any problems. It can still be a file in the local filesystem rather than in a jar file.

It s helpful to develop with the final deployment environment in mind.

EDIT: If you want something in the root directory of your classpath, you should either use:

InputStream x = getClass().getResourceAsStream("/file.txt");

or

InputStream x = getClass().getClassLoader().getResourceAsStream("file.txt");

Basically Class.getResourceAsStream will resolve relative resources to the package containing the class; ClassLoader.getResourceAsStream resolves everything relative to the "root" package.

You could read your data always as a ressource. You only have to add the path where the data lies to your classpath.

If your data stays in WEB-INF/somewhere/mydata.txt inside your jar file, you will access it with:

getClass().getResourceAsStream( "/WEB-INF/somewhere/mydata.txt" )

Now, if you create a development directory /devel/WEB-INF/somewhere/mydata.txt and put /devel to your classpath, your code will work in development and production.

EDIT after explanation in question:

In your case this.getClass().getResourceAsStream( "mydata.txt" ) the resource is taken from the same position where the classfile of this is taken from. If you want to keep this, then you have to create a directory /devel/<path of package>/mydata.txt and again add /devel to your classpath.

How about setting a system property in your dev environment, via the -D switch? e.g. java -D:mypropertyname=mypropertyvalue

You could set the property in ant scripts in your dev environment, other environments don t get the property: e.g.

public static boolean isDevEnvironment(){ return System.getProperty("mypropertyname")!=null;}

You might find a better way to hack it from one of the existing System Properties

If a file is considered part of your deployed application (as opposed to be part of the installation specific files) and can be located through the classpath then consider simply always using getResourceAsStream since it works regardless of the actual deployment scheme as long as it is in the classpath.

You might also find the information available from the JVM relevant (if allowed by the security manager):

 // Get the location of this class
    Class cls = this.getClass();
    ProtectionDomain pDomain = cls.getProtectionDomain();
    CodeSource cSource = pDomain.getCodeSource();
    URL loc = cSource.getLocation();  // file:/c:/almanac14/examples/

http://www.exampledepot.com/egs/java.lang/ClassOrigin.html?l=rel

There shouldn t be any difference between development vs deployment, IHMO.

Classloader.getResource or getResourceAsStream works well, you can read resources and even write them.You can write your own Protocol handles and access everything as an URL/URI, which allows you to read and write resources and also allows proper identification of who actually provide the resource.

The only problem is if an URLStreamHandlerFactory is already registered(in a J2EE application the container could install a factory and you don t have any way to go over and install your own) and you cannot use your handlers "anywhere".

Knowing that, it is preferred to implement your own "resources". At that time when I need it I couldn t find something like that so I had to implement my own ResourceManager. For me it looks more intuitive to access a resource like

Resource layout = ResourceManager.resolve("view://layout/main.jsp") 

instead of

URL layout = Classloader.getResource("some_package/view/layout/main.jsp")