1

I am doing a project in java and in that i need to add and modify my text file at runtime,which is grouped in the jar.

I am using class.getResourceAsStream(filename) this method we can read that file from class path.

i want to write into the same textfile.

What is the possible solution for this. If i can't update the text file in jar what other solution is there? Appreciate any help.

user unknown
  • 35,537
  • 11
  • 75
  • 121
syousuf
  • 11
  • 1
  • 3
  • 4
  • It's not possible to write into the running jar. Maybe if you explain what is in the text file and what you're trying to accomplish, we can help. – Jim Garrison Mar 14 '11 at 02:33
  • Hi Jim,I am reading some information from text file to load my data structure.Now i update some information in my data structure and want to write it back to my file at runtime.Text file had some information about airline booking. e.g Passenger Name, Ref#, CheckedIn Flag.Once a passenger checksIn i update the flag to true and write it back to file. – syousuf Mar 14 '11 at 02:39
  • @Jim: If you can't update your jar while running, it must be a problem of your platform. I can. So I guess you're running some kind of Windows? On the other hand is Java intended as platform independent, which would be a good reason then, not to write to your jar. And since programs are often installed whithout the user being able to modify the program, it isn't wise in the first place to write to the jar at all. – user unknown Mar 14 '11 at 02:57

5 Answers5

3

The easiest solution here is to not put the file in the jar. It sounds like you are putting files in your jar so that your user only needs to worry about one file that contains everything related to that program. This is an artificial constraint and just add headaches.

There is a simple solution that still allows you to distribute just the jar file. At start up, attempt to read the file from the file system. If you don't find it, use default values that are encoded in you program. Then when changes are made, you can write it to the file system.

unholysampler
  • 17,141
  • 7
  • 47
  • 64
2

In general, you can't update a file that you located using getResourceAsStream. It might be a file in a JAR/ZIP file ... and writing it would entail rewriting the entire JAR file. It might be a remote file served up by a Url classloader.

For your sanity (and good practice), you should not attempt to update files that you access via the classpath. If you need to, read the file out of the JAR file (or whatever), copy it into the regular file system, and then update the copy.


I'm not saying that it is impossible to do this in all cases. Indeed, in most normal cases you can do it with some effort. However, this is not supported, and there are no standard APIs for doing this.

Furthermore, attempts to update resources are liable to cause anomalies in the classloader. For example, I'd expect resources in JAR files to not update (from the perspective of the application) until the application restarted. But resources in exploded JAR files probably would update ... though new resources might not show up.

Finally, there are cases where updating a resource is impossible:

  • When the user doesn't have write access to the application's installation directory. This is typical for a properly administered UNIX / Linux machine.

  • When the JAR file is fetched from a remote server, you are likely not to be able to write the updates back.

  • When you are using an arbitrary custom classloader, you've got no way of knowing where the actual bytes of an updated resource should be stored, and no way of storing them.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I'm sorry, but I don't see such statements in the docs ("you can't update a file that you located using getResourceAsStream") - might it be, that this is just valid for some Windows platforms? – user unknown Mar 14 '11 at 03:10
  • Well, I tested a similar claim from Jim in the comments, and I could write to a running jar. Not from within that program, and I didn't find out about it through 'getRessourceAsStream' but opening it meanwhile with another program. It's a bit too much work to write a program, just to prove you wrong - if possible. But since jar-Files are special Zip-Files, I don't see a reason why I couldn't open that File as ZipOutputStream, i.E. To execute the program, the file hast to be read into memory - but the file on disk can be modified with Linux meanwhile, without the running program taking notice. – user unknown Mar 14 '11 at 04:16
1

If i can't update the text file in jar what other solution is there?

Store the information in any of:

  1. Cookies
  2. The server
  3. Deploy the applet using 1.6.0_10+, launch it using JWS and use the PersistenceService to store the information. Here is my demo. of the PersistenceService.

Also, if your users will agree to a trusted applet (which seems overkill for this), you might write the information to a sub-directory of user.home.

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
1

All JAR rewriting techniques in Java look similar. Open the Jar file, read all of it's contents, and write a new Jar file containing the unmodified contents (and the modifications you whished to make). Such techniques are not advisable for a Jar file on the class path, much less a Jar file you're running from.

If you decide you must do it this way, Java World has a few articles:

Modifying Archives, Part 1

Modifying Archives, Part 2

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
1

A good solution that avoids the need to put your items into a Jar file is to read (if present) a properties file out of a hidden subdirectory in the user's home directory. The logic looks a bit like this:

if (the hidden directory named after my application doesn't exist) {
  makeTheHiddenDirectory();
  writeTheDefaultPropertiesFile();
}
Properties appProps = new Properties();
appProps.load(new FileInputStream(fileInHiddenDir));
...
... After the appProps have changed ...
...
appProps.store(new FileOutputStream(fileInHiddenDir), "Do not modify this file");

Look to java.util.Properties, and keep in mind that they have two different load and store formats (key = value based and XML based). Pick the one that suits you best.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138