«

If there is one, that is.

What I mean, is that if I have an ini file (or any file), where do I put it so that I can open it from a package which is not the
base package such as in

package mcu.p1.p2

Properties p = new Properties ();
try
{
p.load ( new FileInputStream ( "myfile.ini" ) );

Does this try to open the file in the directory 'mcu' or 'p2' or wherever ?

Ian Semmel wrote:
> package mcu.p1.p2
>
> p.load ( new FileInputStream ( "myfile.ini" ) );
>
> Does this try to open the file in the directory 'mcu' or 'p2' or wherever ?

From the Javadocs for java.io.File:
By default the classes in the java.io package always resolve relative
pathnames against the current user directory. This directory is named by
the system property user.dir, and is typically the directory in which
the Java virtual machine was invoked.

And please, don't put your question as the subject and then continue on
in the body as if it were the first line. It makes posts hard to read.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Ian Semmel wrote:
> If there is one, that is.
>
> What I mean, is that if I have an ini file (or any file), where do I put
> it so that I can open it from a package which is not the base package
> such as in
>
> package mcu.p1.p2
>
> Properties p = new Properties ();
> try
> {
> p.load ( new FileInputStream ( "myfile.ini" ) );
>
> Does this try to open the file in the directory 'mcu' or 'p2' or wherever ?

I don't think so. getResource() and getResourceAsStream() will look
first in mcu.p1.p2 as a subdirectory, and look inside the .jar file too
in the same place if the code is being executed in a jar file. I think
that's what you want.

File* is just a file on disc. It depends where the OS set the default
directory before it executed the java (or java -jar) command to run your
program. In the case of Applets, there might not even be a file system
attached where you can get at it.

Ian Semmel wrote:
> Properties p = new Properties ();
> try
> {
> p.load ( new FileInputStream ( "myfile.ini" ) );
>
> Does this try to open the file in the directory 'mcu' or 'p2' or wherever ?

Java does what all other language/platform combinations do - if
you open a file without specifying a directory, then it opens
the file in current directory.

Usually that is not very good.

Better options include:
- open the file in the directory where the application is
(not always the same as current directory !)
- open the file in the users home directory which
is available via System.getProperty("user.home")
- if it is readonly then open the file as a ressource
and store it inside the jar file

Arne

On Aug 16, 9:26*am, Arne Vajhøj <a...@vajhoej.dk> wrote:
...
> Java does what all other language/platform combinations do - if
> you open a file without specifying a directory, then it opens
> the file in current directory.
>
> Usually that is not very good.
>
> Better options include:
> - open the file in the directory where the application is ...

If the app. is deployed via webstart, this will not work.

I have spent the last few months seeing posts of folks
whose JWS projects had bombed due to Sun tightening down
the developer access to know where code was locally stored
(even for fully trusted apps.).

> - open the file in the users home directory which
> * *is available via System.getProperty("user.home")
> - if it is readonly then open the file as a ressource
> * *and store it inside the jar file

Your second and third strategies are what I tend to
point them towards.

For the 2nd, I prompt the developer to use a sub-dir
for the sake of avoiding resource collisions. Further
described here..
<http://sdnshare.sun.com/view.jsp?id=2305>

I noted as I prepared that example, that there were
a number of bug reports related to user.home, but
they seemed to be triggered by unusual circumstances
that did not immediately affect my apps.

--
Andrew Thompson
http://pscode.org/

Andrew Thompson wrote:
> On Aug 16, 9:26 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> Better options include:
>> - open the file in the directory where the application is ...
>
> If the app. is deployed via webstart, this will not work.
>
> I have spent the last few months seeing posts of folks
> whose JWS projects had bombed due to Sun tightening down
> the developer access to know where code was locally stored
> (even for fully trusted apps.).

I must admit that I was not thinking Applet or JWS at all.

Arne

Thanks for the replies.

user.dir was what I was looking for.

I have now embarked upon learning about Preferences which has opened up new 'vistas' for me.

On Aug 18, 4:04*am, Ian Semmel <isemmelNOJ...@NOJUNKrocketcomp.com.au>
wrote:
> Thanks for the replies.
>
> user.dir was what I was looking for.

*Really*?! I'd have thought the replies covered
why that was unreliable. What is the user.dir if
the user start the app. from a shortcut they dragged
to the desktop? I doubt user.dir will point to the
application directory then.

> I have now embarked upon learning about Preferences ..

.. damn-it! That was the one I forgot to mention
(on a different thread).

--
Andrew Thompson
http://pscode.org/