I have a Java program which has a number options it allows the user to change, mostly via JComboBox. The only problem is that every time the user closes the program the settings reset, because they are not actually stored anywhere. Is there a standard way to give Java programs persistent state between runs? I could write the settings to a temporary file, but it seems like there should be a more elegant solution.
The Java Preference API is the way to go.
You can find an overview here.
If you keep your entire application Javabean-safe, and extend the standard JFrame classes such and such, you should be able to serialise the entire object graph to file and reload it.
See Restore previously serialized JFrame-object, how? for more details.
Related
I have a system in Java where different classes stores different information. There is a main class where the user will input the information of these classes and make them interact with each other. After the user is done, he will exit the system. The Next time the user recompile the project, all the previously entered data should be there. The user can use that same data or add more information.
So Simply, How to pause/save the system on close and resume it when I execute it again?
PS. I can't use Database in this. It must be something else.
The Next time the user recompile the project
Users dont recompile projects. They just run your app.
You keep saying 'not DB', so, then, the answer is trivially: impossible.
A database, by definition, persists some data, hence the name: It's a base of data. If that's off the table, you're out of luck and what you want is not possible.
Perhaps you are careless in your wording there as well and all you mean is perhaps:
I do not want to bother with forcing the user to install a database
Okay, then, don't. Use an in-process database, such as h2. The user doesn't know an SQL-based database system is involved, all they see is a file appear. No extra processes are launched.
I hate SQL
Okay, then, don't. There are tools out there that turn an entire object structure into a bag o bytes which you can then save to a file, for example Jackson which can turn one object (which can contain all the relevant user data if you want) into JSON data, which you can then save to a file, and restore later. Of course, if someone trips over a powercable halfway through writing it, the file is corrupted. There are ways to fix that (save to .tmp, then move it into place, as that's usually atomic), but you're sort of committed to re-inventing the wheel here, due to your insistence you don't want databases.
I just want to save the entire system state
You can't. Not how java works.
Can't I do it with zero dependencies?
There's java's built in serialization system, which sucks, has a list of caveats as long as my leg on how to use it, and is more or less disliked by the maintainers of the java platform itself. This is not the way to go. It also still won't 'save the entire system state', it just saves one object, and does a much worse job at this than e.g. jackson.
I want to execute few task based open targeted file's OPEN event.
For example, I am watching Sample.docx & whenever user will go for OPEN it, few subsequent task will be performed based upon it's OPEN action.
I have searched on internet & find out few solution but that are based upon file's MODIFICATION & DELETION operation. none of them shows based upon OPEN action which is actually I am looking for.
Any hint/suggestion would help me.
Thanks.
That is an operating-system specific functionality and is not something Java comes with out of the box. If you are on Windows you would use a FileSystemWatcher which exists in .NET, but if you need it in Java you would have to create native bindings if there isn't a library that already exists. Chances are this does not exist as not many people would have a valid use-case to do this and I don't think security people would be happy to see this either.
You could I suppose, in a specific thread, regularly poll currently running processes to see if the file name is contained within a process title.
As for .docx files for example, WORD would have this as its process title:
Sample.docx - Microsoft Word
You would need to utilize a JNA method named getAllWindowNames() to acquire a list of Window Names. This method works quite well. When Sample.docx is detected within the acquired list then start whatever file or files you like.
Keep in mind however, your Java application would need to always be running in the background and because of file association (as mentioned to you in a previous post) this technique would run the files you have associated with Sample.docx regardless of how the file was run (from a double-click in Windows Explorer, a shortcut on Desktop, opened from MS WORD itself, etc).
I have actually created a small demo application that does exactly what you are trying to accomplish however it is too large to post here. There is no tutorial that I know of for this sort of thing, it's just a matter of doing it....that is if the concept appeals to you.
Yes!...most people would not want this sort of thing dancing around on their System(s).
I'll preface this with two notes: 1) I know very little about Java. 2) What I am about to ask for is almost certainly a horrible hack.
I have an application I did not write, and I have no control over the code. It runs on (among other things) a Linux machine. It stores its preferences (presumably using the Preferences API, about which I know nothing) in a structure under $HOME/.java/.userPrefs/...
My problem is that I want to run more than one instance of this code, with different preferences in each instance. Is it possible to tell the Java interpreter to use an alternate location to store preferences, either using a command-line argument or an environment variable?
Edit: I'll add the additional stipulation that each of the instances needs to run under the same user, with access to the same (non-preferences) files.
It's Simple. It seems be to be individual's user directory. Try running/execute the same program under different user accounts.
If you dont have access to the code to check how it really is working and it is saving the preference in a user folder I think your best bet is to run it as different users.
That being said, you can always decompile the code and try to find out if there are any options to pass a preference directory.
You could potentially create different chroot's for every instance that you would like to run.
The answer appears to be "it can't be done."
We were designing an android app for a competition. I was trying to improvise on the features by trying to have a temporary cache on the app. I was going to use HashMap for this purpose. However, I was wondering if there is any special way of creating dynamic hashMap. If yes, please let me know as I am a java noob.(Google did not help much) As of now, i am using the normal declaration for hashMap.(I'm sure that's not right though).
JVM takes care of memory once an application as been terminated. Memory will automatically be free'd up after you exit the program.
Now, if you want to dump the hash map to a file, that's a different story, since HashMap implements Serializable, you can dump the object bytes to a file before the app exits, and load it back in when it starts back up.
Decent write up on Serialization:
http://java.sun.com/developer/technicalArticles/Programming/serialization/
I am working on a Java Desktop program which upon its installation will designate a default database directory and working directory. Where should I save such information so that the next time the user open the program, the program knows where to look for database and working directory?
Things that come to mind:
store everything in the registry (well, did that in MATLAB version and if there is another way, definitely will not go there).
set up another database attached in the jar file to store everything
Is this a so called persistence problem? What are Java Persistence or Java Data Object? Do they have the way to make it working?
any other suggestions?
Take a look at the Java Preferences API. It is a standard Java SE mechanism for storing preferences that does so in a platform specific, but application neutral way. Uses the Registry on Windows, Preferences files on OS X, and I believe ~/.files on Unix.
The Preferences class was created to store things like... preferences in an OS-neutral fashion.
You could also just specify a directory location manually, through a launcher script, or create a default directory in the user's home, and keep both configuration and DB files there.
Your persistent memory is your hard drive, of course, so you need to store data there if you want it to persist from execution to execution. Really, anything goes. You could store the configuration in an XML file -- makes it user-readable outside of the application, which is really nice for debugging, and Java comes with libraries for XML parsing and generation. It would be OS-independent, unlike a registry solution, which is Windows specific. And you could use the XML approach to share information between apps, if that matters. Something to consider.
Update: Preferences are cool! Never saw that one before.