CODEWITHSUNDEEP
javareadfile
Cacheing
Cacheing

Reputation: 3481

java read file path

In the original project, I have a JAVA file that reads a txt file, I put the txt file under the root directory of this project, and everything is fine.

FileInputStream in = new FileInputStream("properties.txt");

Now, I export this project as a jar, and in the new project, I use this jar as an external library. Here comes the question: where should I put the txt file in this new project when I use this external library file?

Upvotes: 0

Views: 2393

Answers (5)

Adrian
Adrian

Reputation: 2388

Put the file into the "working directory" of your application, means the directory the application is started from.

You should have some convention like "Configuration files have to reside within the working directory or working directory/config" and offer a way to overwrite this, for example using a system property, than you can do something like this:

getClass().getClassLoader().getResourceAsStream(System.getProperty("configuration.file.path","properties.txt"))

Upvotes: 0

miku
miku

Reputation: 188164

If you ship this file along with the project and it does not require changes, you can add it to your jar and load it from there via ClassLoader getResourceAsStream:

this.getClass().getResourceAsStream("properties.txt");

(technically it not a file any more, when it enters Java class realm, but a resource)

Upvotes: 1

user1249380
user1249380

Reputation:

Java offers many mechanisms for setting the classpath, including via the command line, via an environment variable, and through setting it in the MANIFEST.MF of an executable Java jar file.

These are all a pain in the neck to manage. It's good to know the technique, and understand the basics. But it's really a bad idea to actually use them.

What you should do is this.

First, put all of your Java libraries in a single place on your system. C:\java\libraries, or whatever. Someplace that you remember, someplace accessible by all of your projects.

Next, name all of your libraries using their version numbers. If you using log4j v1.4.1, then put the jar in a log4j-1.4.1 directory in your library area. This gives you "free" library versioning.

Finally, learn Ant. For simple projects, Ant is simple. Use the Ant build.xml file to compile, test, and run your application.

Why? Several reasons.

Because once it's set up, adding a new library to your project is trivial, you add a line to your build.xml. Ant lets you more easily handle simple abstractions (like where all of your libraries are located).

The build.xml is self contained. If you use, say, an environment variable for the classpath, then the classpath for one project may be different from that of another. That means reseting the environment variable. Continue this and you'll end up swearing at some "new problem" where it "worked before" when it's because you had your classpath set wrong. Set it once in the build.xml, and forget it.

Ant is portable. It runs the same on Windows, on Linux, on Mac, on AS/400, it runs everywhere that Java runs, unlike shells scripts or BAT files.

It's lightweight. Simple ant scripts are simple. They don't bring a lot of baggage with them, you can always make them scary complicated. It's much simpler than Maven for just builds.

Most IDEs support Ant directly. If you decided to go back to an IDE, most can simply use your ant build file with minimal configuration.

This is how you solve your classpath problem with notepad++. Setting the classpath works, but it doesn't go far enough, it's a pain to administer and manage. Learning the basics of Ant will take you much farther with minimal work.

Upvotes: 0

radai
radai

Reputation: 24202

inside the jar and access it using something like

getClass().getClassLoader().getResourceAsStream("properties.txt")

Upvotes: 1

Kartik
Kartik

Reputation: 2609

The file should be at the root of your classpath.

Upvotes: 0

Related Questions