Static Variables -- How Persistant are They?

[Hal Vaughan]

In the app I'm working on, there is a need, from all classes, to get
configuration information. Much of that info is stored in single line
files (which may be put in the Preferences structure in java.util.prefs
later). I've experimented with different ways to access these modes. Part
of the problem is that I have to be sure the "home" mode is set so the
Config class can always read the config directory (and the files in it)
from within the Home directory. Since a user can install the program in
different directories, that means the one piece of info the Config class
needs is the location of the home directory.

One way I originally set this up is for the first class run to figure out
the home directory, then use that and create a Config class object. I've
also experimented with the first class that is run calling main like this:

Config.main("path/to/home-dir");

While this doesn't create a config object, Config.main() would set a static
variable in the Config class to the home directory. The advantage here is
that if I keep all the other Config methods static, I don't have to make
sure I've ALWAYS passed a config object to each and every class that uses
any config info.

So once I've called Config.main() from the initially run class, if I access
all the other static Config methods, my understanding is that I can count
on the path for the Home directory to be set (since it's set the first time
the class is called). Is this correct? Is it correct even if I have the
initially run class call another class that calls another (and so on...)
until I finally get to a class that uses a method in Config?

In other words, if I use my Config class ONCE in an app, can I be sure that
ANY other class that later calls the static methods in my Config class can
count on the static variable of the Home directory to be set?

(This also helps with startup -- since the app logs everything AND sends
copies of the logs back to the server via e-mail, it makes error reporting
in case of setup and init failure a lot easier if I don't have to count on
using a Config object and can use static methods instead.)

Thanks!

Hal

[Brad BARCLAY]

Hal Vaughan wrote:

In other words, if I use my Config class ONCE in an app, can I be sure that
ANY other class that later calls the static methods in my Config class can
count on the static variable of the Home directory to be set?

Why even worry about all of this, when there is a simple solution?

Setup your Config class so that it has a static method for retreiving
the value of the home directory. Use a private static field to store
it, initializing the field to null. When the static method is called,
if the field is null, query the information from its persistent source
and store it into the field. If the field is not null, return it.
Ensure that all of your other methods that require this information only
get it by calling your method. This way, the first time it's called, it
will read the value and store it in memory. Subsequent calls will
return the pre-stored value.

Here's the method we use in the jSyncManager project to do just this.
We use a property to store the home directory (typically user.home, but
we also support "jsyncman.home" to be compatible with an older version
that provided this property), and our data directory has a fixed name
(".jsyncmanager") off this home. The code is smart enough to know that
if the directory doesn't actually exist, we'll create it (useful if this
is the first time you've run it).

The code looks like this:

//
--------------------------------------------------------------------------

private static String homeDirectory = null;

/** Retrieves the jSyncManager Home directory.
* This method returns the user.home directory. However, the user may
override this using
* the jsyncman.home property.
* @return the jSyncManager Home directory.
*/

public static String getHomeDirectory() {
if (homeDirectory != null) return homeDirectory;

StringBuffer sb=new StringBuffer();
String jsmhome=System.getProperty("jsyncman.home");
if (jsmhome==null) {
// user.home should always exist, so we won't bother to check.
jsmhome=System.getProperty("user.home");
} /* endif */

sb.append(jsmhome);

if (!jsmhome.endsWith(File.separator)) sb.append(File.separator);
sb.append(".jsyncmanager");

homeDirectory=sb.toString();
File homeDir=new File(homeDirectory);
if (!homeDir.exists()) homeDir.mkdirs();

return homeDirectory;
} // end-method

//
================================================== ========================

All of our code that requires the home directory for storing any
information retreives it directly from this method, and only from this
method.

HTH!

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org

[Hal Vaughan]

Brad BARCLAY wrote:

Hal Vaughan wrote:

In other words, if I use my Config class ONCE in an app, can I be sure
that
ANY other class that later calls the static methods in my Config class
can count on the static variable of the Home directory to be set?
Why even worry about all of this, when there is a simple solution?

Setup your Config class so that it has a static method for retreiving
the value of the home directory. Use a private static field to store
it, initializing the field to null. When the static method is called,
if the field is null, query the information from its persistent source
and store it into the field. If the field is not null, return it.
Ensure that all of your other methods that require this information only
get it by calling your method. This way, the first time it's called, it
will read the value and store it in memory. Subsequent calls will
return the pre-stored value.

I tried something like this and was experimenting with Preferences (in
java.util.preferences), but I found a bug (feature/problem?) in Linux -- I
could not set persistant data in Preferences in Linux because when Java
installed itself, it didn't set the permissions so any user could write to
the /etc/.java/ files necessary to change fields.

I hadn't realized I could change or add system properties, so this is a BIG
help for me. I'll certainly be using this feature on other programs as
well.
Here's the method we use in the jSyncManager project to do just this.
We use a property to store the home directory (typically user.home, but
we also support "jsyncman.home" to be compatible with an older version
that provided this property), and our data directory has a fixed name
(".jsyncmanager") off this home. The code is smart enough to know that
if the directory doesn't actually exist, we'll create it (useful if this
is the first time you've run it).

Thanks! After looking this over, I also realized that there might be one
catch here (I'd have to check to be sure), just as with Preferences -- in
*nix systems, there might be a write permission problem with storing to the
System preferences (has anyone encountered a similar problem?). I
realized, though, while looking through your code, that I can fix that by
requiring the program be installed by root (or Administrator on Windows) so
the program's home directory can be set.

Hal
The code looks like this:

//
--------------------------------------------------------------------------

private static String homeDirectory = null;

/** Retrieves the jSyncManager Home directory.
* This method returns the user.home directory. However, the user may
override this using
* the jsyncman.home property.
* @return the jSyncManager Home directory.
*/

public static String getHomeDirectory() {
if (homeDirectory != null) return homeDirectory;

StringBuffer sb=new StringBuffer();
String jsmhome=System.getProperty("jsyncman.home");
if (jsmhome==null) {
// user.home should always exist, so we won't bother to check.
jsmhome=System.getProperty("user.home");
} /* endif */

sb.append(jsmhome);

if (!jsmhome.endsWith(File.separator)) sb.append(File.separator);
sb.append(".jsyncmanager");

homeDirectory=sb.toString();
File homeDir=new File(homeDirectory);
if (!homeDir.exists()) homeDir.mkdirs();

return homeDirectory;
} // end-method

//
================================================== ========================

All of our code that requires the home directory for storing any
information retreives it directly from this method, and only from this
method.

HTH!

Brad BARCLAY

[Hal Vaughan]

Brad BARCLAY wrote:

Hal Vaughan wrote:

In other words, if I use my Config class ONCE in an app, can I be sure
that
ANY other class that later calls the static methods in my Config class
can count on the static variable of the Home directory to be set?

Why even worry about all of this, when there is a simple solution?

Setup your Config class so that it has a static method for retreiving
the value of the home directory. Use a private static field to store
it, initializing the field to null. When the static method is called,
if the field is null, query the information from its persistent source
and store it into the field. If the field is not null, return it.
Ensure that all of your other methods that require this information only
get it by calling your method. This way, the first time it's called, it
will read the value and store it in memory. Subsequent calls will
return the pre-stored value.

Okay -- I've tried this and if I set the property and get it in the same
program, it's there. If I set it, then run a program to read it, it isn't
there -- in other words it is not persistant. Is there something special I
have to do to create a new property and make it persistant?

Which leads to something similar. I had problems creating persistant fields
in the Preferences class until I changed read/write permissions in some
directories in my /usr/java directory (I'm using Linux and Java 1.4.1). Is
there some kind of bug in the setup program that does not set permissions
so Java programs can create persistant Preferences fields? (It did fine
when I ran it as root.) I ran my program to set a property as root, and it
made no difference.

Hal

[Brad BARCLAY]

Hal Vaughan wrote:

Thanks! After looking this over, I also realized that there might be one
catch here (I'd have to check to be sure), just as with Preferences -- in
*nix systems, there might be a write permission problem with storing to the
System preferences (has anyone encountered a similar problem?). I
realized, though, while looking through your code, that I can fix that by
requiring the program be installed by root (or Administrator on Windows) so
the program's home directory can be set.

Hi Hal:

"user.home" is automatically set by the JVM, of course, but you can
override it on the command line by using the "-D" parameter.

The way we handle persistent properties is by storing them into the
user's ".jsyncmanager" directory. If the user needs to override
user.home, they can do so from the command line (which, of course, can
be scripted. In Unix, you might do something ilke this:

#!/bin/sh
JAVA_HOME_DIR=/home/somedir/someotherdir
java -Duser.home=$JAVA_HOME_DIR <rest of command>

).

HTH!

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org

[Brad BARCLAY]

Hal Vaughan wrote:

Okay -- I've tried this and if I set the property and get it in the same
program, it's there. If I set it, then run a program to read it, it isn't
there -- in other words it is not persistant. Is there something special I
have to do to create a new property and make it persistant?

Which leads to something similar. I had problems creating persistant fields
in the Preferences class until I changed read/write permissions in some
directories in my /usr/java directory (I'm using Linux and Java 1.4.1). Is
there some kind of bug in the setup program that does not set permissions
so Java programs can create persistant Preferences fields? (It did fine
when I ran it as root.) I ran my program to set a property as root, and it
made no difference.

Properties are not automatically persistant -- you have to write the
properties to disk before exiting if you want to save them. Otherwise,
properties only live for the lifetime of the JVM they're created in.

HTH!

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org


[Phil...]

My experience is the same as Brad. In fact, since I don't want
the user to have to write into the properties file (who knows what
they will do eh) I have a separate program that does it. Ditto
with preferences.

Phil...

Properties are not automatically persistant -- you have to write the
properties to disk before exiting if you want to save them. Otherwise,
properties only live for the lifetime of the JVM they're created in.

HTH!

Brad BARCLAY

[Hal Vaughan]

Chris wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hal Vaughan wrote:

I tried something like this and was experimenting with Preferences
(in java.util.preferences), but I found a bug (feature/problem?) in
Linux -- I could not set persistant data in Preferences in Linux
because when Java installed itself, it didn't set the permissions so
any user could write to the /etc/.java/ files necessary to change
fields.
Hi,
That's probably a feature, not a bug. Think about it: system
properties are shared by all users, so you don't really want any one
user just going in and blatantly changing them for everyone. If you
run your JVM as root, you can set the properties. Otherwise, they can
only be read, and user-level properties can be read and written by
the individual user. Just my opinion on the subject.

That makes sense for system properties, but I would think the preferences
would be different. There is no system info stored in the
java.util.preferences class -- system info being OS related or other info.
My understanding is that this is a place where an app can store any info it
wants to keep persistant. The examples Sun gives in their tutorials is
storing window locations and sizes so they remain constant from use to use.

Unfortunately, in Linux, this info is stored in /etc/.java, and when Java is
installed, (I installed it as root), it didn't change the write permissions
so any user can write to that directory. While this means it can't be
fouled up, it also means that apps on Windows can store things like window
positions here, and Linux apps can't.

My big frustration with this is that I want my app to find itself easily. I
want the user to be able to install it where they want, but when someone
clicks on an icon (in Windows, Linux, Mac, whatever), I want the app to be
able to find its config files. I've found several ways to do that:
- Use a batch file to start the program and include an argument for my prog
that is the path to its home directory (the batch file is altered during
install)
- Use java.util.preferences, but require the program be installed by
root/Administrator so the path to home is recorded at install time and can
be used later by any user.
- Require the program ALWAYS be installed in one place (which can cause
problems because it can require large amounts of disk space while running)
- Allow the user to install anywhere, but requiring a file to be stored in a
"known" location (like C:\Program Files\MyProg\locations.conf or
/usr/local/MyProg/locations.conf) so my prog can always find that file and
check it for location info.

Hal
- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/gdEbwxczzJRavJYRAjcCAJ9nN8Dii9pv0+w+a0q49j8sc/msmgCgqi0H
JvkIa8pVV5KCJLdj++fIuGg=
=NdQx
-----END PGP SIGNATURE-----

[Phil...]

Try this on Linux
Install the system, find out where the preferences file is located.
Lets say it is the file "/abc/def.preferences".
Replace file "/abc/def.preferences" by a LINK
or SYMBOLIC LINK or whatever equivalent
to a new location and file that everyone can use.
(please try before you say it won't work)
HTH, Phil...
"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:7lWgb.66686$%h1.46194@sccrnsc02...

Chris wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hal Vaughan wrote:

I tried something like this and was experimenting with Preferences
(in java.util.preferences), but I found a bug (feature/problem?) in
Linux -- I could not set persistant data in Preferences in Linux
because when Java installed itself, it didn't set the permissions so
any user could write to the /etc/.java/ files necessary to change
fields.
Hi,
That's probably a feature, not a bug. Think about it: system
properties are shared by all users, so you don't really want any one
user just going in and blatantly changing them for everyone. If you
run your JVM as root, you can set the properties. Otherwise, they can
only be read, and user-level properties can be read and written by
the individual user. Just my opinion on the subject.

That makes sense for system properties, but I would think the preferences
would be different. There is no system info stored in the
java.util.preferences class -- system info being OS related or other info.
My understanding is that this is a place where an app can store any info

it wants to keep persistant. The examples Sun gives in their tutorials is
storing window locations and sizes so they remain constant from use to use.
Unfortunately, in Linux, this info is stored in /etc/.java, and when Java is installed, (I installed it as root), it didn't change the write permissions so any user can write to that directory. While this means it can't be
fouled up, it also means that apps on Windows can store things like window
positions here, and Linux apps can't.

My big frustration with this is that I want my app to find itself easily. I want the user to be able to install it where they want, but when someone
clicks on an icon (in Windows, Linux, Mac, whatever), I want the app to be
able to find its config files. I've found several ways to do that:
- Use a batch file to start the program and include an argument for my prog that is the path to its home directory (the batch file is altered during
install)
- Use java.util.preferences, but require the program be installed by
root/Administrator so the path to home is recorded at install time and can
be used later by any user.
- Require the program ALWAYS be installed in one place (which can cause
problems because it can require large amounts of disk space while running)
- Allow the user to install anywhere, but requiring a file to be stored in a "known" location (like C:\Program Files\MyProg\locations.conf or
/usr/local/MyProg/locations.conf) so my prog can always find that file and
check it for location info.

Hal

- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/gdEbwxczzJRavJYRAjcCAJ9nN8Dii9pv0+w+a0q49j8sc/msmgCgqi0H
JvkIa8pVV5KCJLdj++fIuGg=
=NdQx
-----END PGP SIGNATURE-----

[Hal Vaughan]

Phil... wrote:

Try this on Linux
Install the system, find out where the preferences file is located.
Lets say it is the file "/abc/def.preferences".
Replace file "/abc/def.preferences" by a LINK
or SYMBOLIC LINK or whatever equivalent
to a new location and file that everyone can use.
(please try before you say it won't work)
HTH, Phil...
It'll be a while before I have time to try that (and back it up -- just in
case), but that's a good idea. It's one that is obvious enough that I
completely missed it. (I tend to do that -- if it's obscure, I'm likely to
find it, but if it's out in the open, I'll never see it!)

Thanks,

Hal

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:7lWgb.66686$%h1.46194@sccrnsc02...

Chris wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hal Vaughan wrote:
>
>
>> I tried something like this and was experimenting with Preferences
>> (in java.util.preferences), but I found a bug (feature/problem?) in
>> Linux -- I could not set persistant data in Preferences in Linux
>> because when Java installed itself, it didn't set the permissions so
>> any user could write to the /etc/.java/ files necessary to change
>> fields.
>
> Hi,
> That's probably a feature, not a bug. Think about it: system
> properties are shared by all users, so you don't really want any one
> user just going in and blatantly changing them for everyone. If you
> run your JVM as root, you can set the properties. Otherwise, they can
> only be read, and user-level properties can be read and written by
> the individual user. Just my opinion on the subject.

That makes sense for system properties, but I would think the preferences
would be different. There is no system info stored in the
java.util.preferences class -- system info being OS related or other
info. My understanding is that this is a place where an app can store any
info

it

wants to keep persistant. The examples Sun gives in their tutorials is
storing window locations and sizes so they remain constant from use to

use.

Unfortunately, in Linux, this info is stored in /etc/.java, and when Java

is

installed, (I installed it as root), it didn't change the write

permissions

so any user can write to that directory. While this means it can't be
fouled up, it also means that apps on Windows can store things like
window positions here, and Linux apps can't.

My big frustration with this is that I want my app to find itself easily.

I

want the user to be able to install it where they want, but when someone
clicks on an icon (in Windows, Linux, Mac, whatever), I want the app to
be
able to find its config files. I've found several ways to do that:
- Use a batch file to start the program and include an argument for my

prog

that is the path to its home directory (the batch file is altered during
install)
- Use java.util.preferences, but require the program be installed by
root/Administrator so the path to home is recorded at install time and
can be used later by any user.
- Require the program ALWAYS be installed in one place (which can cause
problems because it can require large amounts of disk space while
running) - Allow the user to install anywhere, but requiring a file to be
stored in

a

"known" location (like C:\Program Files\MyProg\locations.conf or
/usr/local/MyProg/locations.conf) so my prog can always find that file
and check it for location info.

Hal

> - --
> Chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/gdEbwxczzJRavJYRAjcCAJ9nN8Dii9pv0+w+a0q49j8sc/msmgCgqi0H
> JvkIa8pVV5KCJLdj++fIuGg=
> =NdQx
> -----END PGP SIGNATURE-----