Perfect place to store config or properties file of a java project ?

[David Jason]

Using eclipse, I made a simple java class that connects to a database and does a few queries. The class picks up database login information from a properties file.
I might want to make a jar out of this eclipse project. Never tried making a jar before, so i don't know if the properties file will be enclosed inside the
jar or kept outside it. I want this properties file to stay outside the jar and my jar file should be able to locate this file on its own.

I can also try another method - my jar should look for the properties file in folder in which it is kept.
But, would this method be system dependent ? You know the "/" vs "\" of linux and windows respectively.

How do I make this happen ?

[Amit Ghorpade]

JARs do maintain the structure, so having the properties file in the JAR gives you easiest way to access it using relative path.
You can have the path relative even if the file is outside the JAR but then it wont be as simple as option one.

David Jason wrote:I can also try another method - my jar should look for the properties file in folder in which it is kept.

If you mean a absolute path here, then you are likely to run into problems as absolute path for Windows start with drive and *nix/*ix systems start with /.

[Winston Gutkowski]

David Jason wrote:But, would this method be system dependent ? You know the "/" vs "\" of linux and windows respectively.

I'm pretty sure that paths in Java can use '/', regardless of what OS it's running on.

However, as Amit said, accessing an external properties file is trickier. If it really must be an external link, then it might be best to make it a URL or URI, since then the program will (or should) be able to run even if it's on a remote system.

Winston

[David Jason]

Winston Gutkowski wrote:

David Jason wrote:But, would this method be system dependent ? You know the "/" vs "\" of linux and windows respectively.

I'm pretty sure that paths in Java can use '/', regardless of what OS it's running on.

However, as Amit said, accessing an external properties file is trickier. If it really must be an external link, then it might be best to make it a URL or URI, since then the program will (or should) be able to run even if it's on a remote system.

Winston

I am not familiar with the URL or URI approach. How does one do it ? Keep their properties file in some folder and then give the code a URL/URI to access that folder ?
If thats the case, then the url might contain "localhost" for locally kept file ?

[Paul Clapham]

David Jason wrote:I want this properties file to stay outside the jar and my jar file should be able to locate this file on its own.

Why? It's much more convenient to put the properties file inside the jar. First of all that means you only have one file to distribute, rather than two. Secondly it means you don't have to figure out a way for the code to find where you installed the properties file.

[David Jason]

Paul Clapham wrote:

David Jason wrote:I want this properties file to stay outside the jar and my jar file should be able to locate this file on its own.

Why? It's much more convenient to put the properties file inside the jar. First of all that means you only have one file to distribute, rather than two. Secondly it means you don't have to figure out a way for the code to find where you installed the properties file.

What if someone wants to edit that properties file ? Lets say that the if the username and password for some account login changed. What happens after that ?
Do we then use something like winrar to un-compress the jar , edit the properties file and re-compress and rename to jar ?

[Paul Clapham]

David Jason wrote:What if someone wants to edit that properties file ? Lets say that the if the username and password for some account login changed. What happens after that ?

Good question. Presumably it's the user of the application who wants to do that, and the application provides a way to do it.

In that case the application should write out the modified version of the properties file into the user's directory. (There's a system property which tells the application what the user's directory is.) And that means that to find the properties file, the application should first look in the user's directory, and then if it doesn't find the properties file there, it should look in the jar.

Now I'm describing an organized design here. I may not be quite in sync with the way you want to run things, but then this is the Beginning Java forum so it's reasonable to expect that you may have chosen a less-than-optimal design.

It's also possible that you have to make occasional changes, perhaps like the password change which you described, but the changes are to be made by you and not by the user. In that case just generate a new version of the jar file, complete with the changed properties, and send it out to the user.

Notice that I'm making a distinction between you and the user, and between what you can and should do and what the user can and should do. You should take this distinction into consideration when you design your application.

[David Jason]

Paul Clapham wrote:

David Jason wrote:What if someone wants to edit that properties file ? Lets say that the if the username and password for some account login changed. What happens after that ?

Good question. Presumably it's the user of the application who wants to do that, and the application provides a way to do it.

It's also possible that you have to make occasional changes, perhaps like the password change which you described, but the changes are to be made by you and not by the user. In that case just generate a new version of the jar file, complete with the changed properties, and send it out to the user.

What if the username and password are for the database owned by the user ? Then, I should have no knowledge of those details, right ? The user should be able to put those in a file from which my jar will pick them up and use them to access the database.
We assume that my code does not steal/misuse the login credentials in any way once it picks them up from the file.

[Paul Clapham]

Which is why I said:

Paul Clapham wrote:In that case the application should write out the modified version of the properties file into the user's directory. (There's a system property which tells the application what the user's directory is.) And that means that to find the properties file, the application should first look in the user's directory, and then if it doesn't find the properties file there, it should look in the jar.

[David Jason]

Paul Clapham wrote:Which is why I said:

Paul Clapham wrote:In that case the application should write out the modified version of the properties file into the user's directory. (There's a system property which tells the application what the user's directory is.) And that means that to find the properties file, the application should first look in the user's directory, and then if it doesn't find the properties file there, it should look in the jar.

I am not sure what you mean by "user's directory". I searched google for "java locate user directory".
Is this it - String userHome = System.getProperty("user.home"); ? Taken from here

[Mike Simmons]

Yes. That's the user's home directory. Try it on your system and see what it gives you.

[Paul Clapham]

David Jason wrote:I am not sure what you mean by "user's directory". I searched google for "java locate user directory".
Is this it - String userHome = System.getProperty("user.home"); ? Taken from here

Yeah, that looks like it. I don't bother to remember specific system properties like that, when I need to know them I just run my little one-liner program which displays all of the system properties and their values.

[Mike Simmons]

It's also documented. There are often other properties present in a given system, but these are the standard properties you can always expect.

[Amit Ghorpade]

David Jason wrote:

We assume that my code does not steal/misuse the login credentials in any way once it picks them up from the file.

That is a bold assumption, if its in a file,with less or no encryption, someone is going to figure it out.
And I really don't understand why the login credentials go to a file from a database, compromising security and storage.