Environment variable

Discussion in 'Java' started by Stefan Poehn, Nov 16, 2004.

  1. Stefan Poehn

    Stefan Poehn Guest

    Hi

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

    Thanks
    Stefan
     
    Stefan Poehn, Nov 16, 2004
    #1
    1. Advertising

  2. Stefan Poehn

    Thomas S. Guest

    Stefan Poehn wrote:
    > 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
     
    Thomas S., Nov 16, 2004
    #2
    1. Advertising

  3. Stefan Poehn

    Stefan Poehn Guest

    "Thomas S." <> schrieb im Newsbeitrag
    news:...
    > Stefan Poehn wrote:
    >> is it possible to get an enviroment variable, e.g. $PATH, in a java
    >> application in windows?

    >
    > 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
     
    Stefan Poehn, Nov 16, 2004
    #3
  4. Stefan Poehn wrote:
    > 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
     
    Thomas Weidenfeller, Nov 16, 2004
    #4
  5. Stefan Poehn

    Stefan Poehn Guest

    "Thomas Weidenfeller" <> schrieb im Newsbeitrag
    news:cndd7t$9o1$...
    >
    > 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?

    > /Thomas
     
    Stefan Poehn, Nov 17, 2004
    #5
  6. Stefan Poehn wrote:
    >>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,


    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.
     
    Michael Borgwardt, Nov 17, 2004
    #6
  7. Stefan Poehn wrote:
    > 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
     
    Thomas Weidenfeller, Nov 17, 2004
    #7
  8. Stefan Poehn

    Stefan Poehn Guest

    "Thomas Weidenfeller" <> schrieb im Newsbeitrag
    news:cnfvg0$jnm$...
    > [...]
    > 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).

    > 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, Nov 17, 2004
    #8
  9. On Wed, 17 Nov 2004 18:28:06 +0100, Stefan Poehn wrote:

    > 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

    --
    Andrew Thompson
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.PhySci.org/ Open-source software suite
    http://www.1point1C.org/ Science & Technology
    http://www.LensEscapes.com/ Images that escape the mundane
     
    Andrew Thompson, Nov 17, 2004
    #9
  10. Stefan Poehn wrote:
    > 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
     
    Thomas Weidenfeller, Nov 18, 2004
    #10
  11. Stefan Poehn

    Glynne Guest

    "Michael Borgwardt" <> wrote in message
    news:...
    > Stefan Poehn wrote:
    > >>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,

    >
    > 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.



    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
     
    Glynne, Nov 21, 2004
    #11
  12. Glynne wrote:
    >>>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.

    >
    >
    >
    > 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.
     
    Michael Borgwardt, Nov 21, 2004
    #12
  13. Stefan Poehn

    Glynne Guest

    "Michael Borgwardt" <> wrote in message
    news:...
    > Glynne wrote:
    > >>>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.

    > >
    > >
    > >
    > > 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.
    >
    >


    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.
     
    Glynne, Nov 21, 2004
    #13
  14. Michael Borgwardt wrote:
    > 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
     
    Thomas Weidenfeller, Nov 22, 2004
    #14
  15. Glynne wrote:
    > 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.
     
    Michael Borgwardt, Nov 22, 2004
    #15
  16. Stefan Poehn

    Stefan Poehn Guest

    "Michael Borgwardt" <> schrieb im Newsbeitrag
    news:...
    > 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
     
    Stefan Poehn, Nov 22, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom
    Replies:
    0
    Views:
    452
  2. Manuel Arroba
    Replies:
    5
    Views:
    431
    John Saunders
    Jun 8, 2004
  3. Replies:
    5
    Views:
    676
  4. mfglinux
    Replies:
    11
    Views:
    726
    Roberto Bonvallet
    Sep 12, 2007
  5. David Filmer
    Replies:
    19
    Views:
    257
    Kevin Collins
    May 21, 2004
Loading...

Share This Page