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."
Related
I am writing a Java application, in which I need to be able to change input languages (say, from English to Japanese) on user request. Normally, a user would just go into the Windows/Linux system settings and change it there. However, for this particular application, the user will not have access to these menus.
I've done quite a bit of research on SO and elsewhere. The solutions I've found indicate using the InputContext.selectInputMethod([locale]) method. This works on Windows (using the IMEs in the Windows registry), but I can't seem to get it to work on Linux (it always returns false, even when selecting a locale for which I have the appropriate language packs installed).
Ideally, I'd like to have a completely platform independent implementation, but I at least need it to work on Linux. So what am I missing? Do I need to install input methods as an extension? Are there built in IMEs I can use? It seems like this wouldn't be too difficult to implement, but I've found surprisingly little concrete information.
Thanks in advance for the feedback!
Is there a way to change working dir for JVM when running Java Webstart?
When i use system.setProperties("user.dir", newDir) it sets it(system.getProperties() shows it does) but ignores it.
Is this a limitation in Java Webstart to always use the working dir where i started the jnlp file?
I am using all permissions in the jnlp file.
Please help!
EDIT: Whatever i do now, my webstart always uses user.dir to save files. Frustrating!
I've had this question in the past myself, but I've always found that, in the end, I didn't need it. Why do I say this?
Because your java web start app is not like an executable run from Program Files. It doesn't even exist on your computer like most programs (it is broken up into a bunch of different files and reassembled by the JVM). Therefore, you cannot say that the program has its own directory to do what it needs.
But it doesn't need to. Here's why:
Java has the Preferences API to help when you need to store data. The under-workings of the Preferences API is as mysterious as JWS, thus they are really a perfect fit. Either way, if you need to write things to a file, you should check this API to see if it can meet your needs.
If you need to write files for the user, then prompting them and allowing them to choose the location obviously means you won't use your current working directory to read/write files.
If you need to serialize objects, you should just create a program directory using the user.home resource as #AndrewThompson suggested. This will be "your" directory and is as good (in fact, better) than a directory in Program Files (if you're running on Windows, as an example).
In conclusion, in all cases (that I've come across), there's no need to change your current working directory. If you need your own folder, create one in user.home (because you won't run into file permissions issues there).
..all my settings file i use is created in the user.dir.
There is the mistake. Put them in a sub-directory of user.home & the problem is solved.
In the hypothesis you really really need to divert user.dir property for Java WebStart execution, here is the only option I have found: set this system environment variable (so system wide):
_JAVA_OPTIONS="-Duser.dir=C:\Temp"
But care about it, this option is read and applied to any JVM executions.
Why was it required in my context ? Because Java WebStart ClassLoader was looking for any single resource (class, properties...) in user profile before getting it from jar files in cache. As the user profile has been moved to a network storage, application start up became terribly slow. I am still investigating Java sources to understand (and avoid) this behavior. So my applications work perfectly without setting user.dir but that was the only work-around for the performance issue we got at the moment.
The recommended way to pass runtime parameters or user specific setting is through the jnlp argument
<application-desc main-class=".....">
<argument>user.home</argument>
..............
I wrote a program in Java that makes it easy to setup and switch between different versions of Minecraft. The program is pretty much done, but I'm faced with a problem that I can't seen to find the solution for. I have a button in the program that allows you to launch Minecraft by means of the Runtime object. This works well on my computer because I know where I have my .app or .exe file (depending on OS). I don't however know where that file is located on anyone else's computer. I have thought of a few ways of getting around this, but none seem to be feasible.
One idea was to just prompt the user to locate the file through a file chooser and then cache that file. This would work, but isn't very elegant, especially for users that aren't very computer literate.
I also thought about bundling the .app and .exe file with my application but that brought up even more problems. For one, I don't know if it's exactly legal for me to be distributing that file with my application. Also, it would change the way I would have to distribute my application to include some sort of installer that sets up everything.
Does anyone have any better ideas on how to handle this problem?
You have at least three choices that I can think
You can use a configuration system to store the location(s) of the program and prompt the user/supply a config API to set the value. This is good and rather simple to do
You can search commonly well know locations for the location and if it's not found, prompt the user (and hopefully store the result). This is okay, but it relies on a number of factors, including the OS and the program actually being loaded in a "common" location and being named in a "common" manner.
Search the hard drive. This is poor as it's time consuming and the application might not actually exist on the drive you are search...Searching all available locations could lead you onto network drives which will just be slower...And prompt the user if it's not found
Seen as almost all the solutions fail to "prompt the user" I would probably use a combination of 1 & 2. Allow the user to specify the location, if they don't, search some common known locations and if you still can't find it, prompt the user (and hopefully save the value for reuse).
IMHO
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.
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.