Environment variable

[Stefan Poehn]

Hi

is it possible to get an enviroment variable, e.g. $PATH, in a java
application in windows?

Thanks
Stefan

 

[Thomas S.]

is it possible to get an enviroment variable, e.g. $PATH, in a java
application in windows?

java.lang.System.getProperty() should do it.

Thomas

 

[Stefan Poehn]

java.lang.System.getProperty() should do it.

No. You can retrieve the environment _for the jvm_, not for the system, like
$PATH. System.getProperty("$PATH");
System.getProperty("%PATH%");System.getProperty("PATH"); all return null.

 

[Thomas Weidenfeller]

No. You can retrieve the environment _for the jvm_, not for the system, like
$PATH. System.getProperty("$PATH");
System.getProperty("%PATH%");System.getProperty("PATH"); all return null.

System.getenv()

Was AFAIR deprecated in some Java versions, but has been "un-deprecated"
for some time.

/Thomas

 

[Stefan Poehn]

System.getenv()

Was AFAIR deprecated in some Java versions, but has been "un-deprecated"
for some time.

Thanks. It works. Is there a replacement for this method that is not
deprecated, or is it "forbidden" to use environment vars in java?

 

[Michael Borgwardt]

Thanks. It works. Is there a replacement for this method that is not
deprecated,
No.

or is it "forbidden" to use environment vars in java?

It is stringly discouraged, since it's not portable. Some systems don't
have environment variables at all (such as pre-X MacOS), and they don't
behave the same on all systems that do.

 

[Thomas Weidenfeller]

Thanks. It works. Is there a replacement for this method that is not
deprecated,

The method should never have been deprecated, and Sun corrected this at
some point in time. At least, it is not deprecated in 1.5.

or is it "forbidden" to use environment vars in java?

No, why should it? Some people have the argument that environment
variables don't exist on all platforms, so such a method is not a good
idea. However, this was not a really good reason to deprecate the method.

It is possible to provide an entirely conforming implementation on
systems which don't have environment variables. The method is supposed
to return null if a variable does not exist (which can happen on
platforms with environment variables, too). So a compliant
implementation on systems without any environment variable would be to
always return null - which then correctly indicates that the variable
does not exist.

Alternatively, VM implementers could provide means to set "environment
variables" for a particular VM, e.g. by making the System.Properties (or
some other set of properties) available via the getenv() call, too. This
would be compliant, because the API spec does not provide a clear
definition of what an "environment variable" is supposed to be. Quote

"An environment variable is a system-dependent external variable that
has a string value."

There are other - Java independent - reasons why using environment
variables are often not a good idea. Controlling application behavior or
configuration via environment variables is a no-no, because this is
usually not what a user expects. Users usually don't want their
applications to behave differently just because the environment has
changed. Instead, application behavior is expected to be deterministic,
only depending on the input explicitly provided to the application.

Of course, there are exceptions, e.g. Unix users expect that the default
printer name is picked up from the PRINTER environment variable, or the
default editor form the EDITOR or VISUAL variable.

But in general, application configuration should be done via command
line options or some configuration file, not via some "hidden"
environment variables.

/Thomas

 

[Stefan Poehn]

[...]
There are other - Java independent - reasons why using environment
variables are often not a good idea. Controlling application behavior or
configuration via environment variables is a no-no, because this is
usually not what a user expects. Users usually don't want their
applications to behave differently just because the environment has
changed. Instead, application behavior is expected to be deterministic,
only depending on the input explicitly provided to the application.

Of course, there are exceptions, e.g. Unix users expect that the default
printer name is picked up from the PRINTER environment variable, or the
default editor form the EDITOR or VISUAL variable.

I can explain in simple words why we want to have an environment variable:
every developer has another folder structure on his harddisk. If you need
the absolute path to the project, you have to store this path outside your
program. This can be done with environment vars or registry entries, and I
really do not want to use the registry. (We are working on Windows only and
do not need to support other platforms).

 

[Andrew Thompson]

I can explain in simple words why we want to have an environment variable:
every developer has another folder structure on his harddisk. If you need
the absolute path to the project, you have to store this path outside your
program. This can be done with environment vars or registry entries, ..

...or <http://www.physci.org/codes/javafaq.jsp#path>.

HTH

 

[Thomas Weidenfeller]

I can explain in simple words why we want to have an environment variable:
every developer has another folder structure on his harddisk. If you need
the absolute path to the project, you have to store this path outside your
program. This can be done with environment vars or registry entries, and I
really do not want to use the registry. (We are working on Windows only and
do not need to support other platforms).

As I wrote, using environment variables for such cases is bad.

/Thomas

 

[Glynne]

It is stringly discouraged, since it's not portable. Some systems don't
have environment variables at all (such as pre-X MacOS), and they don't
behave the same on all systems that do.

By the same logic, some systems don't have a GUI, so why don't we deprecate
Swing and the AWT?

Considering that the behavior of the JVM itself can be altered by the
presence
of the CLASSPATH environment variable, I find "purist" arguments against the
use
of environment variables somewhat laughable.

Or perhaps the rationalization is that the JVM is a "real" application, so
it needs
to be able to access environment variables, while a Java app is something
less?

~Glynne

 

[Michael Borgwardt]

By the same logic, some systems don't have a GUI, so why don't we deprecate
Swing and the AWT?

Because they cannot be emulated by something more portable. There's nothing
you can do with environment variables that can't be done with system properties,
with less potential for incompatibilities or other problems.

Considering that the behavior of the JVM itself can be altered by the
presence of the CLASSPATH environment variable,

Which causes problems all the time and is deprecated. The very fact that
every single Java introduction book needed to contain a chapter on "how to
set up your CLASSPATH" (which is the reason why the damn thing isn't gone
and forgotten) proves that it was a bad idea.

 

[Glynne]

Because they cannot be emulated by something more portable. There's nothing
you can do with environment variables that can't be done with system properties,
with less potential for incompatibilities or other problems.

Yes, but if I NEED to interrogate the environment variables, I should not
find the language standing in my way.
If 90% of Java programmers don't need env vars, that's great, but don't deny
the other 10% of us access to them.
Otherwise we'll have to keep C/C++ around to write our "real" apps.

The fact that this functionality was originally present, then it was
deprecated, then it was un-deprecated....
and the fact that it's occassionally debated in the newsgroups would seem to
indicate that it is a useful
feature, at least for a subset of Java programmers.

 

[Thomas Weidenfeller]

Because they cannot be emulated by something more portable. There's nothing
you can do with environment variables that can't be done with system
properties,
with less potential for incompatibilities or other problems.

They can be emulated up to the level that the API documentation of
getenv() is satisfied. That documentation allows to return null for
non-existing environment variables. So, if a System has no such
variables at all, it could simply always return null.

Finally, even Sun recognized this, and getenv() is no longer deprecated
in 1.5.

Which causes problems all the time and is deprecated. The very fact that
every single Java introduction book needed to contain a chapter on "how to
set up your CLASSPATH" (which is the reason why the damn thing isn't gone
and forgotten) proves that it was a bad idea.

Which is not so much a problem with the environment variable, but with
understanding the mapping from package names to directories, class
(file) naming, and class search mechanism (in directories and in jars).
You can observe exactly the same confusion when you see people messing
with the classpath on the command line. Somehow, the concept of a search
path seems totally alien to beginners. The fact, that most books then
make a mess out of explaining the classpath adds to the confusion.

/Thomas

 

[Michael Borgwardt]

Yes, but if I NEED to interrogate the environment variables, I should not
find the language standing in my way.
If 90% of Java programmers don't need env vars, that's great, but don't deny
the other 10% of us access to them.

I agree with this mostly, but OTOH it encourages stupid practices like
putting program configuration into environment variables.

 

[Stefan Poehn]

Glynne wrote:

I agree with this mostly, but OTOH it encourages stupid practices like
putting program configuration into environment variables.

Can you give me a better place for path infos used by Java programs,
batches, xsl scripts, build scripts and C++ programs? A "Windows only"
solution is sufficient for my purpose.

Thanks
Stefan