NX: DB File Location in suncertify.properties

[Bharat Ruparel]

Hello All,
This may or may not be a problem, but I want to run it by the group and see what you think.
I have created dialog-boxes that let the user choose parameters to be stored in suncertify.properties file. In the "alone" mode and the "server" modes, the user should be able to specify the database file location, in my case for URLyBird 1.3.1, the database file name is db-1x1.db. I have a "Locate" button next to the file location JTextField that allows user to activate JFileChooser dialog-box and navigate to the directory which stores the db-1x1.db file, choose it, and transfer it to the JTextField. This works fine. The location of the file is stored in suncertify.properties file as follows:
aloneFileLocation=C\:\\SCJDProj\\db-1x1.db
serverFileLocation=C\:\\SCJDProj\\db-1x1.db
Now I am no Unix Guru, but I know that this is specific to Windows platform (I am developing in a Windows 2000 machine).
My question is: is it OK? Things seem to work fine on my Windows machine. How would this work on a Unix machine? I don't have access to a Unix machine where I can conveniently test my program. I use the following snippet of code to transfer the chosen file's path to the JTextField box:

        if (source == locateButton)    {
            JFileChooser fileChooser = new JFileChooser();
            fileChooser.setCurrentDirectory(new File("."));
            fileChooser.setSelectedFile(new File("db1-x1.db"));
            int returnVal = fileChooser.showOpenDialog(ConnectDialog.this);
            if (returnVal == JFileChooser.APPROVE_OPTION) {
                File file = fileChooser.getSelectedFile();
                fileLocation.setText(file.getPath());
            }
        }

Anything else that I need to be aware of regarding the portability of code between Windows/Unix platform related to UI for suncertify.properties file, please point out.
Regards and thanks.
Bharat

[Mark Spritzler]

If you look at the Java API documentation for JFileChooser class, and more importantly File class. In the File class it basically states that getPath returns the path in the format of the operating system that it is run on. More importatntly regarding the drive letter on Windows and the lack thereof in UNIX.
The directory seperator is the \\ which can be used in UNIX or Windows and it works..
Please read the documentation on the File class, some more for exact verbage.
Mark

[Bharat Ruparel]

Hello Mark,
Thanks for your response. I did look-up the File API especially related to the stuff that you point out above. Having read through that and Sun's tutorial on JFileChooser, I think that I have system-independent code. My lack of access to a Unix system however led me to ask this question on the forum. I think I am OK. If not, can you give me a hint on what to focus on? The thing that comes to my mind is absolute path versus relative paths. Problem is: getPath always returns the absolute path, ditto for getAbsolutePath and getCannonicalPath functions?
Regards.
Bharat

[Arun Kumar]

Hi Bharat,
i am using
File file = fc.getSelectedFile();
selectedFile = file.getAbsolutePath();
I develop on a Linux machine. I tested this out on my win98 machine (I know it is blooday old, i seldom use that machine) it worked great. No changes required. According to the API getAbsolutePath is platform independent.
Cheers
Arun

[Bharat Ruparel]

Hello Arun,
Thanks for your response. Are you saying that I should be using:
file.getAbsolutePath()
instead of
file.getPath()
in my code above to make it work across Windows and Linux (Unix) platforms?
From reading the API documentation, it seems to me that getPath() is also platform independent. I have no reservations about changing my code, I just would like to know why? Would you do me a favor and see if getPath() also works on both your Linux and Windows 98 machines?
Regards.
Bharat

[Arun Kumar]

Hi Bharat,
ok it all depends on what you have in your File object.
getPath() just converts the path of the file object to a String. So if the file object holds a 'relative path' getPath() returns a string representation of the 'relative path'. If it holds an 'absolute path' getPath() returns a String representation of the 'absolute path'.
If the file object holds an 'absolute path' then getAbsolutePath and getPath returns the same string. no difference and ofcourse platform independent or should i say platform dependent, with forward or backward slashes and drive letters depending on the system you are on.
There is a difference between getPath and getAbsoultePath only when the file object is holding a 'relative path'. getPath() doesnt do anything other than give a String representation of the file objects' path. But getAbsolutePath will try to resolve your 'relative path' to an 'absolute path'
The absolute path is normally your System.getProperty("user.dir"); It will append that in front of your relative path and that is what getAbsolutePath will give you. Normally the use.dir will return the current working directory from where you invoked your JVM.
So the way i have implemented
File file = filechooser.getSelectedFile();
file object gets an absolute path here. So getPath and getAbsolutePath both will return the same string in my case.
the getSelectedFile call on the filechooser always seems to return absolute paths to the file object. So getPath and getAbsolutePath doesnt make any difference.
Hope i make sense
Arun
[ October 09, 2003: Message edited by: Arun Kumar ]
[ October 09, 2003: Message edited by: Arun Kumar ]

[Arun Kumar]

Hello bharat,
After i posted my reply, i went through your first post again and then it made sense to me what you are talking about
Ok from my post above you should have understood what getPath or getAbsolutePath does. right?
In case of suncertify.properties file, the string (or should i say the propertys' value) which gets stored as the default location of the database file, will always be platform dependent regardless of wether you use getPath or getAbsolutePath from the JFileChooser.
in windows it will get stored as -> eg - C:\\dir\\dir\filename
and in unix it will be always be stored as -> eg - /usr/local/scjd/db/filename.
Ofcourse when you move the properties file generated on a windows machine over to a unix machine, the JVM will throw an error when resolving the filepath. Other standard strings will not be a problem.
So when the user for the first time runs the 'runme.jar' there should be no properties file. When the program starts your appl should look for the suncertify.properties file in the current working directory (according to the instructions given to me, the properties file should be in the current working dir), if FileNotFoundException, ask the user to use your GUI interface to create a fresh new properties file, which will have the string whose format will be dependent on the platform he is working on.
In my case i dont have properties file, which stores file paths or file names. I use the property file only for the files' magic cookie. The file has to be choosen by JFileChooser every time.
Was this what you were asking about in your first post? Or am i way of the mark
Cheers
Arun
[ October 09, 2003: Message edited by: Arun Kumar ]
[ October 09, 2003: Message edited by: Arun Kumar ]

[Bharat Ruparel]

Hello Arun,
Thanks for your time and effort. I really appreciate it. You are almost up to speed on my environment and the logic that I have. You wrote:

So when the user for the first time runs the 'runme.jar' there should be no properties file. When the program starts your appl should look for the suncertify.properties file in the current working directory (according to the instructions given to me, the properties file should be in the current working dir), if FileNotFoundException, ask the user to use your GUI interface to create a fresh new properties file, which will have the string whose format will be dependent on the platform he is working on.

I make sure that I have a suncertify.properties file in the current directory since that is what the instructions mandate. As you noticed, I store the FileLocation information in the properties file. I have checks in my program which "try" to open the db1-x1.db file based on the fileLocation information stored. I have the following code to accomplish it in my "validateFile" method:

String dataFileName = configParams.getProperty("dataFileName","db-1x1.db");
File f = new File(fileLocation);
if (f.exists()){
    if (!f.getName.equals(dataFileName)) {
        ....
    else {
        msgStr = "This file doesn't exist, please try again."
        ...
    }
}

You get the idea. So, as you point out, if the system cannot locate the file because of the system dependent file-path information stored in the suncertify.properties file, the user is prompted to locate the file again. This time, either the user can type in the file path information in the correct system dependent way or use the JFileChooser to get it which will be automatically adjusted based on the platform. Is this right?
Regards.
Bharat

[Arun Kumar]

Seems ok to me...
I am using properties file only to store the magic cookie. In my program i have a default cookie vlaue = 'xxx' hardcoded. This particular cookie will open the default db file given with the assignment. If they want to open other db files with someother magic cookie value, then they can do so using the GUI which will create a new properties file with a new cookie value.
So if my program finds a property file, it ignores the cookie value hardcoded in the program and makes use of the cookie value from the property file.
So my program will run without a property file as long as they are opening the default db file. I dont have the hassel of packaging any kind of properties file and making a mistake of packaging it in the wrong place.
But in your case you cannot have default db file paths. Your idea will work fine ... but does your program need some sort of a default property file (though the data in it may be wrong) to run? Or it will startup fine with out a property file, but it will warn through some error messages that the user has to create a new property file using the GUI?
Arun

[Bharat Ruparel]

Hello Arun,
You wrote:

Or it will startup fine with out a property file, but it will warn through some error messages that the user has to create a new property file using the GUI?

That is how it works currently.
Regards.
Bharat

[Arun Kumar]

Hello bharat,
i might have misguided you ...
I checkd it out, that in unix the \\ works fine also. For example when i open the inputstream to load the property file,

FileInputStream in = new FileInputStream("\\root\\java\\project\\j2se\\code\\suncertify.properties");  

This worked fine with \\ or / .
Notice the path it is \\ but without the drive letter. So if you have a properties file stored in a windows machine, the \\ will not cause any problmes in the unix machine. But i dont know about the drive letter. And anyway there is no guarantee the directory structure in the windows machine is going to be the same as the unix machine.
So your way of checking if the file exists should be fine..
SOrry about that ..
Arun

[Bharat Ruparel]

Arun,
Thanks. Good luck with your submission. I am getting there soon.
Regards.
Bharat