We Keep Coding

How to save data in a Java program

Is there a way to make a collection of class files/objects and then have them used in an interactive main file? So let's say I want to make a program to store information interactively where different classes are designed to hold different information. Then I would have an interactive main file where I made instances of these classes which would collectively hold the information I want stored. And then any changes or anything I do in this interactive main file is then saved.
I understand that this might be a very odd inquiry and maybe some other program might be useful for this. If so, feel free to point me in the right direction.

Here are two solutions that are good for the purpose you mentioned in your comment.
The first one is called Serialization. This let's you save your java object to your hard drive, and retrieve it later.
The second, (and in this case, more preferable option in my opinion), is using a Database.
A database is a compliment to your program, that stores data. You can then use "Queries" to access this data, and update it. Almost every database software is compatible with java.
I would look into MySQL
The reason I think a database would be better for your purpose is that they are already highly optimized, and are designed to have multiple people accessing and writing to them at once. If you wanted just want one person to use this program at a time however, serialization might be easier to implement.

Absolutely! Your main class would use the standard input (perhaps Scanner input = new Scanner(System.in);) and output (System.out.println()). To interact with your other classes, most simply, just put them in the same folder (if you are interested take a look at Java packages). If you have a Dog class in the same folder as your main class, you can freely create Dog objects in your main class. I hope this helps!
As a side note, because you mentioned storing information with different classes, you might be interested in the Java Collections Framework.

Java- Quitting the programme midway and resuming where you left off?

I am doing a java project and have several methods. Would like to know if its possible to quit the programme after the 3rd method for example and then when resuming the programme it continues from there? Any information regarding this would be helpful
THank you

Not without some kind of external persistence mechanism, no.
Once the process is done, it's done.

Why do you want to do this? There may be a better solution.
Otherwise, it would be along the lines of saving data in some particular format (JSON, YAML, etc..) and then have a parser that could determine where the last program left off. It's somewhat vague, so it also depends on what you're attempting to "save".
Potentially could do something hacky if you ran the program with a wrapper.
Edit:
You could serialize your classes, which in turn would allow you to be able to save the fields of any objects you have, however everything you have would need to implement Serializable and be saved to a file.
So after a little bit of googling, I found that there is also the XStream library, which serializes objects to XML without needing to implement an interface. In that sense, you could serialize objects themselves, but wouldn't be able to, say, continue from the middle of a method. (Having a string you can parse to start in different locations could be one option).

Continue with Object serialization or use database?

I have written a math game in Java, and have distributed some copies to a few beta-testers. The problem is that the version I have given them is saving the GameData via object serialization, which I found out is mainly for sending Objects, or in this case, ArrayLists of GameData, over a network. It is NOT persistance; that is what a relational database is for. Knowing this, I would like to know if it would be better to create a database on the beta-tester's machine (and rewrite the game), or continue with the Object serialization version of the game, and then retrieve the Objects when they are ready to send the data?
My guess would be to just move their data to a database that is created on their computer, and then give them the database version of the game. That way, the data can be persisted and be much easier to manipulate. What turns me away from that idea is the question of how am I going to write their database into mine (in the future)?

Although relatively rare, there are still lots of applications that use serialization for storage and retrieval of objects. It's not wrong to do this, just slightly unusual. If it's working for you, stick with it because DB's are a heavyweight solution. What you found out, about serialization, is only an opinion and an ill-formed one at that.

In terms of using an embedded database, two options to consider are SQLite and HyperSQL. However, serialization is also an option, and in my opinion it should be your default option if you've already implemented it. Some considerations:
With serialization you've generally got to retrieve the entire object, which is slow if you've got an object with several dozen fields and you only want to read one of them. If you're making queries like these, then use a database. I suspect that you're just reading in all of your serialized objects at startup and serializing them back out to disk at shutdown, in which case there's no reason to use a database instead of serialization.
Java's default serialization mechanism is fairly slow. You may want to consider another serialization mechanism, such as Kryo or Jackson, but only if you're not happy with your program's serialization performance.

It is difficult to advise on the best choice of technology without knowing what you are persisting and why.
If the state is simply a snapshot of your game state (i.e. a save file) or a "best scores" table, then you don't need a database. Serializing using JSON, XML or ... Java Object serialization is sufficient.
If the state needs to be read or updated incrementally or shared with other applications ... or users on other machines ... then a database is more appropriate.
Serialization mechanisms are problematic if the requirements include incremental changes, etcetera. You end up building a database-like layer over the top of the serialization.
As to whether you should stick with Java serialization ... or switch to JSON or XML or something like that:
Object serialization is simple, but it can be fragile if you change the classes that you are serializing. This fragility can be mitigated, but it is messy and you lose the simplicity. (You need to write custom readObject and writeObject methods that know how to read "old versions" of the serialized objects.)
JSON and XML are a bit more complicated, but still relatively simple if you use an object binding mechanism.
It is worth noting that changes to the persisted object classes (or the database schemas) are potentially problematic no matter what you do. There is no easy universal solution to this problem.
UPDATE
Given the additional information that you provided in your first comment (below), it seems like you don't need a database in the game itself. All you need is something that can read and analyse the session state save files that your beta testers provide for you. Indeed, it doesn't even seem like the actual app needs to be able read the files. (But that's unclear, because you've not said what the real purpose of these files is ... or at least, not what the entire purpose is.)
It is also worth noting that you are probably saving the wrong information if your aim is to tune the sets of questions. What you really need to do is record the length of time and whether the user got the right or wrong answer and the time ... for each individual question. And you probably need to know what the actual answer given was ... so that you can spot cases where the user's answer was actually right and you "marked" it as wrong ... or vice versa.
"What turns me away from that idea is the question of how am I going to write their database into mine (in the future)?"
Exactly. If you hadn't prematurely "analysed" the data, you wouldn't have this problem.
But ignoring that, it seems like that a simple state saving mechanism is sufficient to meet your (still hypothetical / inferred) requirement of keeping a personal score board for the end user. Your "tuning" stuff would be better implemented using a custom log file. I cannot see any value in incorporating a database as part of the app itself.

I presume you are doing java serialisation, If so there is nothing wrong with it. Just be aware of its limitations - Different versions of java might not be able to retrieve the file.
Also If you change the Class, previous saved data can not be retrieved.
If you decide to change you could look at Xml, JSon, Protocol Buffers, Thrift, Avro etc as well as a DB.
Note:
Xml is builtin in to java
Java Db (Derby) is also in Java
Other serialisation schema's require a seperate library.

Java: Serialization performance for deep copy?

I need to deep-copy Java objects for one of my projects; and I was wondering if it's okay to use Serialization for this.
The objects are fairly small (< 1kb each), total #objects per copy would be < 500, and the copy routine will be invoked a few times a day. In this case, will it be okay to use Serialization for this in production, or is that still a really bad idea given the performance of Serialization?
If it's still a bad idea, I can think of using copy constructor/static copy method per such class to improve performance. Are there any other ways for it?

Maybe. Performance will not be an issue - dependencies will be.
The usual problem with serialization is that an innocent reference to some core class in your application can give you a copy of 90% of all the life instances because they suddenly become reachable. So you must be really careful with transient and the references which you use.
Worse, if you need serialization for deep copy and real state saving, you might end up with incompatible goals:
Deep copy needs to be fast
Deep copy can handle open resources (database connections)
State saving needs to handle API evolution (the state is stored on disk, it could be restored with a new version of the code).
State saving can benefit from using a readable form (so a human could fix mistakes)
Therefore, it's often better to use copy constructors than using a "clever hack" even though it might safe you some/a lot of time right now.

cool debugging of object

I just had an idea that I wonder whether is possible in java. Let's say when doing debugging using eclipse or netbeans, you could record an object and save it. Then when going through the second round of debugging, save the object again. Now you could compare the first object recorded with the second object for all properties and find out any differences. Is this possible?

You can do this in plain Java code (assuming your objects are Serializable), but I don't think any debuggers have this feature built-in.
It would simply be a case of serialising the first object during the debugging run (which if you had a static method to do so, you could generally call from the debugger) and saving it somewhere. Then, during the second run, call another method to reconstitute the object from it's serialised form - and then compare the objects (either with their equals() methods, or some more bespoke comparison method).
In practice though I find that whenever I want to do this I just scribble down the relevant properties on a piece of paper and compare them manually. Rarely am I looking at thousands and thousands of properties that might change between a run; if you think about the symptoms you're seeing and the behaviour of your object, you can normally have a very good idea of what might be changing before you even fire up the debugger, and then use the latter to confirm your hypothesis and backtrack to see where the value "went wrong".

Give your object a useful toString() method and then use unit tests to compare the result with what you expect.
But I agree: The wire protocol for remote debugging can serialize any object, so it should be possible to write a program that does this automatically.
OTOH, objects which aren't meant to be serialized can be dangerous. If you accidentally use this on a classloader, you'll get all objects and classes and everything back as one big lump. So you need a way to stop the serialization to make sure it can't run havoc in a deep object tree.
On top of that, I'd like a feature to save the current state of the app and be able to go back in time.

I don't think any debugger can save object to compare them later. What you can do though is to create a watch variable on the variable, but wrap it with the ToStringBuilder() of the apache commons and dump it in the console, like so:
System.out.println(ToStringBuilder.reflectionToString(object));
Each time the breakpoint is reached, the content of the object will be shown in the console. You can even see the private data.
Therefore, you do not need to modify the toString() method of the object directly (this is useful for library object for example). You can then compare the output of your two passes.