Best way to store data between program runs in java?

Question

I was wondering if there was any way other placing the information that is genereated by the program between runs of the program? I already know that you can use a text file and store the information that way but I was wondering is there a better way? Also is there any way to do it so as to keep the information secure? from the end user being able to access it?

Answer 1

Cryptography on files, or local database with password.

Answer 2

You can use Properties for storing information. If you want to make it secure, run it through some sort of encryption stream.

Answer 3

You could use db4o to store the data. It's an object database and supports encryption.

Answer 4

I was wondering if there was any way other placing the information that is genereated by the program between runs of the program?

Simply use an ObjectOutputStream to serialize it into a file and an ObjectInputStream to get it back.

Also is there any way to do it so as to keep the information secure? from the end user being able to access it?

If the code runs on the end user's system then no, there is no way to prevent them from getting the data - it's not even worth your time trying to encode it somehow, since it's easy to attach a debugger and inspect the program's state while it's running. As a binary format, Java serialization will prevent non-technical users from deciphering it, and that's pretty much the best you can hope for.

Answer 5

I've never used it myself, but I think that's what the JDK's java.util.prefs.Preferences was originally designed for.

Answer 6

The best thing to use when beginning Java is to use an ObjectOutputStream or a text file. Once you have more experience then you can use databases.

Answer 7

You might be interested in Quick'n'dirty persistence for Java.

Answer 8

How about serialization?

It can't be read by the user and it's relatively easy.

Answer 9

As others have said, there are a myriad of ways to serialize data. You can use something lightweight like SQLite or just plain serialization. Just realize that any attempts you make to encrypt the data can be defeated, especially in the case of Java code since it can be easily reversed.

However, if the bulk of your users are not technical enough to understand the complexities of reverse engineering a Java program to figure out how to decrypt your data, you should be able to get away with some basic encryption methods like what was mentioned in another answer and be good. Just realize that anytime anything resides on a machine you don't control, there is no way to keep the most persistent users from figuring out how to crack it.

I personally would suggest using sqlite and using some simple encryption on the data you put in the fields so if someone is smart enough to be able to connect to the local DB file, they still have to reverse your crypto algorithm in some manner. 99.9% of regular users won't bother with this level of investigation.

Answer 10

Some people suggested to use serialization. Beware that there are a number of disadvantages to serialization.

• The versioning problem. If you change something in the classes that are serialized, then serialized files written with the old version of your program can't be read easily anymore.
• You don't know the exact file format. It will be really hard if you want to write a different program later, possibly in a different programming language, that needs to read the file.

Serialization is not well-suited for long-term storage.

I would suggest using a small, embedded database instead. (An embedded database is a database that runs in the same process as your program). Note that Sun's Java includes Java DB, which is a version of Apache Derby. There's also HSQLDB, which is another small and pure Java database that can be used as an embedded database.

Answer 11

XML as a serialization technique is more resilient to future changes in your program that will adjust the storage than binary formats such as Object Serialisation. However that would make it very readable and changeable by most users.

A very simple compression/decompression would stop almost all users from getting at the actual contents of the data. The use of GZipInputStream/GZipOutputStream around your current writing stream will do the job. The more elaborate your defence against prying you get the more it will impact the users of your software.