Feature request:
    all that remains of the getenv() function is the method that returns an error message:
   /** Obsolete. 
     * Gets an environment variable. An environment variable is a
     * system dependent external variable that has a string value.
     * @param name the name of the environment variable
     * @return 	the value of the variable, or null if the variable is
     *		not defined.
     * 
     */
    public static String getenv(String name) {
	throw new Error("getenv no longer supported, use properties and -D instead: " + name);
    }

The need for this particular call is very important while I continue to work with
an existing cross platform application that creates environment variables during
the runtime. There is no 'easy' way to get these values. Most of the deprecation
documentation is misleading (it states that getenv() is replaced with getProperty()).

Please return the funtionality where ever it is...
(Review ID: 38108)
======================================================================

Write code to get the current OS, Guess the Current OS command to display the environment into a dataStream, then parse out all the values.
example (work in progress):
/**
 $Workfile:   OSEnvironment.java  $    $Revision:   1.0  $   $Modtime:   Sep 01 1998 13:31:46  $

 $Log:   U:/archives/VCS/VMT/COMM/src/OSEnvironment.java.v  $
 // 
 //    Rev 1.0   Sep 01 1998 13:31:22   opr5581
 // Initial version of new class to replace System.getenv() call.
 // This revision works specifically for the AIX environment with the "printenv" commnad located at /usr/bin.
 // 

  Since getenv has been removed... 
  we need to get our own values from the OS for all existing Environment Variables.
 
*/

import java.lang.*;
import java.io.*;
import java.util.*;
   
public class OSEnvironment {
  static String[][] envData;
  static int envDataSize = 0;
  String wholeEnv = "";

  OSEnvironment(){

/** TODO: The following command is set for the AIX environment.
          In order to make this portable, an OS check and alternate 
          command will need to be added.
*/
    // need to know what type off system we are on an know the 'set' path/command
    String command = "/usr/bin/printenv";

    //Get our environment into a single string:
    try {
         Process p  = Runtime.getRuntime().exec(command);
         DataInputStream commandResult = new DataInputStream(new BufferedInputStream(p.getInputStream()));
         String line = null;
         try {
              while ((line = commandResult.readLine()) != null)
                  wholeEnv = wholeEnv +"," + line;
              if (p.exitValue() != 0) {
                    wholeEnv="Error=Cannot complete OSEnvironment.class: " + command + ":" + p.exitValue();
              } 
        } catch (Exception e) {
        }
   } catch (Exception e) {
        wholeEnv = "Error Cannot Use OSEnvironment.class: " + command + ":" + e;
   }
   envData=parseEnv();    
  }
  String[][] parseEnv(){
       StringTokenizer envTokenizer = new StringTokenizer(wholeEnv,",",false);
       envDataSize=envTokenizer.countTokens();
       String singlePair;
       String[][] parsedEnv = new String [envDataSize][2];
       for (int i=0;i<envDataSize;i++) {
          if (envTokenizer.hasMoreTokens()) {
             singlePair=envTokenizer.nextToken();
             parsedEnv[i][0]=singlePair.substring(0,singlePair.indexOf("="));
             parsedEnv[i][1]=singlePair.substring(singlePair.indexOf("=")+1);
          }
       }
       return parsedEnv;
   }
   String getEnvValue(String envName,String defaultValue){
       String valueFound = defaultValue;
       for (int i=0;i<envDataSize;i++){
          if (envData[i][0].equals(envName)) {
             valueFound=envData[i][1];
          }
       }
       return valueFound;
   }

}
======================================================================

Many operating systems support the notion of a process environment that maps
identifiers to string values, but no two systems define the contents of this
environment in the same way.  Even amongst Unixes there are significant
differences; some define USER as the user's login name, while some define
LOGNAME to have this value, and some (e.g., Linux) define both.

So while we could easily reinstate the getenv() method to provide access to the
process environment, any code that invokes this method would inherently be
dependent upon the operating system(s) upon which it is written and tested.
One of the primary goals of the Java platform is to provide a set of APIs that
work in essentially the same way across a wide variety of operating systems, so
that developers can write portable programs.  Providing access to information
that is inherently OS-specific is not consistent with this goal.

--   xxxxx@xxxxx   2001/7/25


Due to overwhelming demand we are going to reconsider this position for
the 1.5 release.

--   xxxxx@xxxxx   2002/4/30

We definitely need a simple way to get access to environment variables
(to our knowledge, only the Mac does not have such variables, and it would be
perfeclty sensible to simply return null in this case)

How about servlet environment? No way to get the envrionment
variables from command line input.
Please give me a suggestion.

There's more in the world than 'just java'. If a JAVA program cannot
collaborate in a senseful and simple way with other programs that depend on
environment variables and access and/or manipulate them JAVA renders in some
sense useless.

I agree that we definately need a way to retrieve environment variables (such
as HTTP_USER_AGENT) through java. Java is a means to an end, not an end in
itself. If it can't perform then people will user other languages that can.

I do agree with the previous speakers. 
It should be possible to call getenv() and if the
OS doesn't support it could return null or throw
an exception. But don't remove it only because not
all OSs support it.

This is a quality of implementation issue to me. 
Java has system properties and -D. Why not have
a switch that automatically includes the 
environment in the system properties, as if the
user inserted them all with -D? I know a number
of people who have written wrapper scripts that
do this.

Definitely need the getenv method.

I like johnl's suggestion of making the environment variables accessible as
system properties, along with the consensus "return null if
unsupported".
I'm on a Mac and I don't think getenv should've been deprecated on Mac's behalf
-- Mac may get environment variables as part of the Unix-y MacOS X anyways.
[memo to minggui: for servlets, you can add initArgs to your
servlets.properties file and read them in with
ServletContext.getInitParameter(String)]
                          

I also vote for a simple way to read the environment, even if machine specific.
Isn't it simple to get the OS environment when it exists, 
and read a file that simulates it when it does not exist (i remember having
done this kind of stuff for the IBM VM).

Automatically mapping all environment variables into the
system properties list would be fine for virtually all purposes
(possibly mapping FOOBAR as java.environment.FOOBAR)
and anywhere that doesn't have any environment variables
can simply skip that step - you have to handle the case that
the envvar is missing anyway...)
This would simplify my java calling code quite a lot.  Probably
make it more robust too!  :^)

It seems to me that if the 'C' language has a Standard for getting
environment variables (stdlib.h) getenv() that java could build in and
 utilize that functionality as in the following'C' code'  snippet.
JNIEXPORT jstring JNICALL Java_DLLTest_getEnv
  (JNIEnv * env, jobject obj, jstring name){
	const char *str = (*env)->GetStringUTFChars(env, name, 0);
	char *ret = getenv(str);
	(*env)->ReleaseStringUTFChars(env, name, str);
	return (*env)->NewStringUTF(env, ret);
}

yep, reinstate getenv.  there's no reason to remove it for macos, any more than
there would be a reason to remove standard input/output/error streams just for
mac.

YES!
Reinstate it and have it return null if there is no environment.  I develop on
HP-UX,
AIX, NT, SUN, 95, 98, DEC, and god old DOS.  All of these have environments. 
Why
should we be forced to write platform specific native code when the JVM can fix
99.98% of the problem for us.  You have getRoots() which dosn't always make
sense,
why not getEnv?  It's unreasonable to ask thousands of developers to do what
you 
could centralize.
-G

And since this breaks old code should this not be a bug instead of a feature
request?

GetEnv is depreciated...   but removing it like it was breaks 1.0.2 code that
used it...
It should be supported on platforms that it could be , at least in the interest
of
running 1.0 code

Java programs will be second class citizens in Unix until they can access
$HOME.

I totally agree with having getenv() return null if the system does not support
environment variables.

No.
There's no need to support getenv(), I think the -D solution is better. Write
startup scripts that read from the environment, that way you are explicitly
saying you need X and Y vars.
The guy that said java can't read $HOME is wrong, yes you can there is a
property for that (also one for username, etc).

getenv() is unsupported because there are platforms
that don't have "environment variables".  The only 
one that springs to mind is the Mac.
The suggested workaround is to use "-D" and startup
scripts.
Some platforms don't support command-line arguments 
or scripts.  The only one that springs to mind is
the Mac.
So the suggested workaround for the lack of
getenv() only works on platforms that would
support getenv() in the first place.  Does this 
strike anyone else as odd?
Regarding the platform-specific sample code listed:
it's much easier to simply pass the commandResult
stream to System.getProperties().load(strm) (although
multi-line properties will bite you if you do).

I think the reason getenv() is deprecated is that there is now
System.getProperties(). The properties given by Sun look similar to X-Windows
application properties and Windows .ini file application properties. It's not a
bad idea.
But nevertheless the environment variables are an important part of the system
properties, and so if getenv() is to be deprecated, then at least
System.getProperties() must be able to return environment variables since these
are an integral part of the system properties when they exist! At the very
least read in the variables and prefix them with "env.".
Yes, the particular variables and their uses are platform-dependent, but so
what?

Perl, C, and C++ all support access to environment variables.  That particular
feature
makes them no less portable.  One could even argue that it increases their
portability.

Not providing access to environment variables makes Java a less desirable
choice for 
portable application development.  I have a Perl script that really should be a
Java
program, but it depends on environment variables.  So it will remain a perl
script.  So
my application remains only 99.8% Java.

The suggestion that each application write a platform-specific hook to obtain
environment
variables violates the spirit of Java.

Since most platforms provide environment variables, the correct thing to do is
to define 
an adaptation for those platforms that do not.  For example, on such a platform,
 return
the contents of a property file named 'environment.properties' in some
pre-defined 
location.

Even though the mechanism for obtainining the values of environment variables
may need
to be platform-dependent, the need to obtain them is not.  Put it back.

We definitely need access to environment varaibles in servlets.
How else should i verify a client SSL-certificat ???

I agree that we do need this. I am now having to waste time creating a workaround. It seems perfectly 
sensible to me just to return "null" if the platform does not support the concept.

The fact that something like environement variables does not exist on some operating system is not a valuable
reason to get rid of them.
Many feature are not on DOS. Shall we get rid of every thing which dont work with DOS, I don't think so
We can get rid of DOS for instance.

It would make a lot of sense for Java to pretend that any
environment variables that you request just haven't ever
been set when calling getEnv()'s replacement under systems
that don't support an environment.

I hate environment variables, but I don't control the 
world. I vote for getenv being undeprecated. At least 
remove the thrown exception and have it return null. Boy, 
that was a pretty harsh way of deprecating it.

JSP pages don't accept -D parameters and because of that I 
have to hard code the parameters I want. Is there a way to 
either allow java to read system vars or allow new entries 
to be added to the Properties?
<BR>
Thanks
Alex Santos
asantos@emediait.com

Would it be possible to replace this functionality by providing an LDAP service to it ?
e.g. in Win2K I believe the registry is now available as an LDAP service - and the registry is pretty much a 
hierarchical environment/property store. Such services could be simulated on systems where there is no 
explicit registry. This would seem to be a more generic solution to the rather outdated environment variable 
usage.

No question, getenv() should be reinstated.  The argument 
that environment variables are not supported on all OSes 
(and therefore getenv was removed) doesn't really follow.  
That's the same argument which was being used for not 
implementing mouse-wheel support in Java.

I like the solution of piping the environment vars to -D in 
the command line and using getProperties() to retrieve 
them.  Nice and neat.  If environment variables are not 
supported return null. 

The suggested evaluation is great!  PLEASE DO THIS:

That said, I don't think it is right to just throw an 
exception here.  The documentation says the method is 
deprecated, not removed from the language.  Shouldn't we 
implement it as best we can?   Why not just say that by 
convention the environment is empty when the host platform 
doesn't spport one?  That is, reinstate 'getenv', but have 
it simply return null if there is no environment.

Command line argument are not supported on the mac. (There is not even a command line on the mac.)  
Does Sun depreciated void main(String[] args).  No, they build a patch for that so mac user can type the 
parameters in a little windows or save them in a file.

Environment variable are not supported on all platform, but they are not specific to just one, just as 
command line parameter.  I think they should be available, on the platform that support them, not a 
depreciate, but as a normal method.  With a warning that it will not work anywhere and that programmers 
that want their programs to run on all platform should also provide alternative way to do what is done with 
the environment variable.

It's like the third button of the mouse, who may use it, but who also provide alternative way to do the same 
thing for the one that don't use it.

One thing you can't do with -D as a replacement for getenv()
is to get environment variables that have been 
added/deleted/changed since the start of the program.

I remember having this problem back before servlets
when trying to get environment variables for CGI.
I think there are other similar environments (IBM's MQ) 
that (at least back when I worked with them.) also 
passed critical information via process-private 
environment variables.  

Not having a way to get these dynamically changing 
variables effectively removes functionality from the 
Java Platform.

I aggree with Avery,
My Authentication Daemon sets an Environmental Variable to 
identify a valid user, since java can't access this I am 
now in the ridiculous position of having a cgi script 
posting the value of the variable to java...

Please, please, please return getenv()!!!

I vote against it :)
People will start to use getenv("HOME") to get home
directory (as one person above have written). HOME is set
only on unix-like systems. Way better to use user.home - it
is guaranteed to be most sensible value on all systems (HOME
for unix ones, USERPROFILE for winnt, some dir inside
windows for win95 etc). Same goes for temp - I can see
people checking first for TMP, then for TEMP... Also people
would start to parametrize their apps through env variables
(like MYAPP_DEFAULT_SIZE_OF_CACHE) - instead of using
crossplatform way for setting it (for thing clients, macos etc)
For the servlets - all needed parameters should be passed by
servlet server. There is a method for retrieving such info.
For legacy applications passing data to subprocess through
env variables... you can always create a native wrapper
(piece of bash script, or very simple C program with exec).
And what if parent programs wants to communicate through
shared memory or kernel message ? This means it is not
designed to be used with java. Same goes for passing data
through env variables (but here workaround is easier).

I vote against it :)
People will start to use getenv("HOME") to get home
directory (as one person above have written). HOME is set
only on unix-like systems. Way better to use user.home - it
is guaranteed to be most sensible value on all systems (HOME
for unix ones, USERPROFILE for winnt, some dir inside
windows for win95 etc). Same goes for temp - I can see
people checking first for TMP, then for TEMP... Also people
would start to parametrize their apps through env variables
(like MYAPP_DEFAULT_SIZE_OF_CACHE) - instead of using
crossplatform way for setting it (for thing clients, macos etc)
For the servlets - all needed parameters should be passed by
servlet server. There is a method for retrieving such info.
For legacy applications passing data to subprocess through
env variables... you can always create a native wrapper
(piece of bash script, or very simple C program with exec).
And what if parent programs wants to communicate through
shared memory or kernel message ? This means it is not
designed to be used with java. Same goes for passing data
through env variables (but here workaround is easier).

Since MacOSX is really FreeBSD with a pretty face, the notion of an environment is now a cross-platform 
feature. The argument that it is platform specific no longer holds. :-)

I never agreed with the argument that environment variables
are not cross-platform, so they shouldn't be supported in
Java. According to that reasoning, Java shouldn't support
files because embedded systems don't have files!

As others have pointed out, Java programmers do need some
way of accessing environmental variables. Sure, some
programmers will use the feature inappropriately, but as
soon as they try to run the code on a platform that doesn't
support environmental variables, they'll learn not to rely
on them.

Environment variables are a common concept that is supported
by most platforms, so Java should support them, too. It
perfectly fine for getenv() to return null on those
platforms to which they don't apply at all, but the complete
lack of this feature unnecessarily precludes Java from being
used in many areas.

And, come on, the workaround to write platform specific
wrappers (e.g. shell scripts) that invoke Java programs with
environment variables turned into properties or command line
options really defeats Java's WORA promise. If I can't
create a solution with just Java alone, I might be better
off choosing a different language in the first place (such
as Perl which also runs on UNIX, Windows, Macintosh, OS/2,
BeOS, AS/400 and many more including some small platforms
like Psion/EPOC).

Right! Need the genenv()-functionallity, and would like to have it return a propertylist with
all and every details from the native environment. Can do this using native methods but
this isn't JAVA and isn't all good.

Yes, some platforms don't have an environment.  So, why not
simply treat the environment on those platforms as empty? 
Should Java not support audio because some platforms don't
have audio?  Or graphics because some platforms don't have
graphics?  Either returning a runtime error or having a
minimal stub-implementation seems like a better choice than
to whittle down the APIs to meet a lowest common
denominator.

Good Grief!  What's the problem?  As you say above, on platforms that don't implement environments, 
return an empty environment, otherwise java should be able to do this.  We are trying to be cross platform 
here.  The semantics of System.getProperty() is perfect for this.  Instead of dealing with some 
statically defined stuff, the getProperty methods should be fetching the environment values.
I don't think java should be trying for least common denominator here.  It certainly doesn't do that
in the GUI category, why do this in the file system category?

I agree that the environment should be returned as Properties (rather than getenv() directly)
where it makes sense. Code already must deal with the possibility that the desired variable
or property is not set, so returning null or simply not setting any additional properties is a
reasonable thing to do on a platform that has no concept of environment.
Contrary to what many here state, the Mac has both command line arguments and an
environment in MPW and, as already stated, will also have both in OS X

I think getenv(String Name) must be still supported.
Its deprecation can be correct, as a non portable function, 
but actually thi function is deleted, since it thows an 
Exception !!!.
Definitly I think that throwing an exception is a bug!!.
Code compatibility is lost.
Anyway, I wish to write Java applications, but how can I 
write an installayin procedure if I have to ask all the OS 
details to the user?

You can try this in unix platform atleast:

public Properties executenv(String command)throws Exception{
	Properties p=new Properties();
	Process pro = Runtime.getRuntime().exec("env");
	InputStream in = pro.getInputStream();
	p.load(in);
	return p;
}
Then we can get environment variable by using getProperty()
method of Properties.

Its quite easy: SUN stole getenv(); and now it is time to bring it back. As others have pointed out, there is
NO sensible reason  for this annoyance. 

btw: to the person who had the glorious idea of taking away this feature: I HATE YOU. 

I speak again about getenv().
Please do not suggest a workaround which introduces still 
ore problems.
Since also runtime.execute() is badly implemented and ist 
functionality to execute system commands ( like set ) 
cannot be guaranted.
I have tried this workaround but  my software crashes 
(deadlocks) with Win9x.
To he honest, I think that removing getenv() has been a 
stupid decision, and I thiknt it is even more stupid not to 
recognize this error and return this function.
Definitly the only right thing you can do is to introduce 
it aging, or ave system envurenment variables mapped 
someway ( automatically or on user request ) to system 
properties.

Please provide an update on the request for re-instating 
getenv(). 

Working around not having getenv() is wasting a lot of 
money. 

There are two sensible ways of handling the system
environment: by getenv() or by getProperty().  Either is OK
and you could even implement one, the former maybe, in terms
of the other so long as there is a little bit of effort put
in to pass everything through in the bootstrap code. 
(Setting environment variables, well, that's something else
entirely.)

What is the problem of letting the VM automatically import
the
environment into properties, e.g. with a common prefix like
env to have
env.HOME
env.PATH
env.TMPDIR
env.LESS
env.PROXY
env.YouNameYourFavoriteEnvironementVariable

yes same problem 'm facing.If getenv() is not supported by 
some OS it should throw some exception so that end user may 
know the real problem in his code.
Sun has to fix  this bug in comming merlin version of JDK

Its worth noting the ant build tool (jakarta.apache.org) 
does extract the environment in their Execute.java class, 
but they have to jump through hoops for every platform 
supported. Their code makes a good workaround till sun pull 
their fingers out and 'support getenv() wherever there is 
an env to get'

Just another agreement here...

Either getenv() should come back or the environment should be mapped by name through the system properties using a prefix like 'java.env.'.

It seems that the only major reason stated for removing getenv is the lack of support on the classic MacOS, 
which does not support environment variables. But MacOSX, which is based on BSD, does support 
environment variables, so I think the main argument for removing getenv just vanished. 

One reason Java is popular is that you have a large library 
of system functions, so programmers don't have to write 
machine-specific stuff and multiple languages.  That means 
higher productivity.  Why start throwing that away.

Well, I guess that Sun is unwilling to do what is needed to 
make Java a useable language. Because of this and other 
issues, many developers will use other languages, because 
they support the programmer, rather than dismiss the 
programmers needs for some philosophical dream of "cross-
platform". It is pretty obvious that the folks at Sun are 
more interested in cross-platform moral purity than in 
actually getting programs that run. It's too bad. Decisions 
like will delegate Java to ghetto status.

This is a stupid decision, who made the call?  Lets just open another bug about getenv support.
If sun closes it, then open another, and another , until they figure out we are serious and need
this supported.  The eval even has a proper solution, return the OS's env or return null if it does
not have an env.  How hard is this?

Bug Closed: "Will not fix.  "getenv" is simply not
cross-platform."

What a shame, and what a blatant ignorance of all the good
points made on this page!

Sun, I am very disappointed.

SUN's arguments have absolutely no basis. We have to look 
no further than to the fact that their own 
java.lang.Runtime API provides an exec() that allows 
passing the environment. Now how can it be that passing a 
new environment is cross-platform but accessing it is not. 
Is there anyone in SUN that can talk with a gram of self 
consistency about this issue? Really, really sad.

Not so many things are really "cross-platform". File 
systems, gui, input/output are certainly not. 

Read-only access to environment variables is cross-
platform: Environment variable is a string value that can 
be found by a string key. Nothing non-portable.

The following might have confused an evaluator: On some of 
existing systems,  environment variables can be set by 
application owner or higher level system administrator. On 
other systems, they cannot be set. 

On some systems (VMS), not every environment variable can 
be read by any running in the environment application.

Nothing of above makes getenv() not cross-platform.

All C getenv() implementations known to me de-facto follow 
this simple business rule:  

getenv() returns the value if environment variable value is 
set and allowed to be read; otherwise it returns NULL.

Java implementation can follow this simple rule 
notwithstanding whether or not a particular system supports 
environment variables and whether or not a particular 
system allows JVM an access to environment variables.

I beleive this issue had better be re-evaluated before 
numerious and mutually incompatible 3rd-party APIs 
substituting this simple call appear on the market.

Will not fix is not an acceptable answer.  Graphics aren't cross-platform; they aren't present
on OS/390, HP MPE/iX, AS/400.  Curses functionality is more cross-platform than graphics.

So many applications have hacks in them to get the environment variables in VERY non-
cross-platform ways that this is just pitiful.  There are multiple non-cross-platform items
in the JDK much more egregious than environment variables.  This is a very bad mistake
for Sun to make.  There are entire classes of applications including installers, utilities,
scripting and mini-languages and legacy application conversions  which need this and which have 
hacks currently.  In moving from native code to Java, how can I maintain backwards 
compatibility with my native code which allows the user to set environment variables; 
this isn't an option, this is a requirement.  (Passing in as environment variables does 
_not_ work when the set is unknown at program start, controlled by the user.)
The previous evaluator was correct in that it is _not_ right to throw an exception here;
it is deprecated, not disfunctional.  Recommend against it all you like, but we're talking
applications here, not applets, and this functionality should be present.

Very disappointing and discouraging. Closing this issue is 
a lazy idealogic decision rather than a practical one.

I also agree with the last comment.
Bettr I think You are completely crazy.
You have not DEPRECATED getenv, you have deleted it.
I suggest the one who decided to do tis and has set this 
answer will be discharged by Sun.
Or does sun prefere we use a different language for our 
applications ?

The property suggestion seems a reasonable and pragmatic approach - enough platforms have environment 
variables to make this enhancement worthwhile - at least it would be standard. Instead everyone is going to come 
up with a variety of (undoubtedly slightly different) solutions. Perhaps we should just define our own standard?

I have to echo a previous post - Sun, I'm disappointed!

-- Mark

Far out, Sun! Granted that what "getenv" will do isn't cross-platform in a strict sense, but following the 
same arguments neither is fileaccess (path-separators are definitly not cross-platform). You could as well 
ask us to do it all using JNI or whatever. The answer "Will not fix" isn't good enough - give us REASONS, 
dammit!

The worst part about their "Will not fix." answer, is that
this request was about making getenv() functional, not
non-deprecated.  Deprecating it should be enough for "not
cross-platform" functionality.  

Personally, I think someone just didn't care, and that this
is another [unreportable] failure in Sun's bug process.

I'm not impressed.  IMHO Sun's support of their user base 
has gone downhill drastically in the last year or so.

This is indeed an unacceptable solution.  As at least one previous commentator has mentioned, the JDK includes quite a few platform-dependent extensions.  The getenv() functionality is (1) simple and (2) highly useful, and implementing it in the JDK shouldn't be difficult.  I don't understand your unwillingness on this.

Can't believe it !
First of all 2.5 years for reaction, in IT area it is quite 
slow.
And more over the final decision is a developer insult.
You are providing the basement of our development, you 
should simplify the life of thousands of developers and not 
complexify it.
Bad day for Java.

CGI programs:
Our customers have to make batch files or script files or numerous other entities with
the same parameters every single time they want to do a CGI program.  These
environment variables are the same everywhere our customers run.  If getenv("cgi")
returns null, then we're in an invalid CGI environment and should return anyway.
Our customers are migrating legacy applications gradually, so CGI is an acceptable
interim deployment for us.

Installers:
Our installer creates Windows shortcuts _without_ using JNI, writing the
shortcut format natively.  Where does it write it?  It uses environment variables
passed in as system properties to determine the location.  This is only meaningful
in Windows, so when the getenv("name") returns a null on other platforms, this
is fine.

Variable code:
We support Cobol for Java, so we have to support the X/Open environment variable
construct.  Basically, our customer's code can prompt 'Which environment variable
should I read', and then display it back.  We can't know the system property to
pass, and neither can our customers in all cases.  We have to support a call
to getenv from our user's code.  This is not true only for us, but all other languages
working with the JVM, as all other reasonable languages can interact with the
system to the extent of being able to read the environment variables.

A hack was included before using Runtime.getRuntime().exec(), but frankly
the exec() method is buggy and doesn't work well at all cross-platform, and
knowing or guessing the environment variable printing mechanism is more
non-crossplatform than anything.  And waiting for the response when it
doesn't come using exec will hang the process.  This hack for environment
variables is worse than useless.

So what are we left with, JNI.  The most inherently non-cross-platform
solution.  And when our customer wants to deploy on a new platform, they
have to compile the C code themselves.  They're not C programmers, they
don't know how to do that, and we don't know the other system, so it causes us 
headaches to no end.

We do deploy on OS/390, AS/400 and HP MPE/iX, text-only systems so we
have a real perspective on the fact that this cross-platform argument is
incorrect.  We support ten different systems and the environment variable
functionality is useful across all of them.  And we have to use hacks for
all of them.  We know things aren't the same everywhere, but honestly,
doing a:

String path=getenv("PATH"); if(path==null) path=getenv("HPPATH");

is a thousand times better than the hacks and JNI.  The hacks and
JNI have to deal with the multiple names PLUS the extra work; at least
this would allow us to maintain a single source.

I know you've done a separate evaluation after the closure to speak to
some of this (inadvertantly wiping out the earlier evaluation saying that
just throwing an exception is the wrong behavior).  But I _strongly_
urge you to reconsider this.  If we have three separate instances where
we need this behavior, and so many people have responded in frustration
to this closure, then this should be reconsidered yet again.

getenv() is contrary to Java's goals of Write-Once-Run-
Anywhere and should be deprecated.  However, to take an 
existing method that used to work and change it's contract 
is a practice cannot be applauded.  getenv() used to work - 
now it throws an exception.  Methods that are deprecated 
should still be required to fulfill their contract.  This 
was a binary incompatibility that was intentionally 
introduced – this goes way beyond the side-effect 
incompatibilities we accept as part of a new release to an 
improving product.

Please return the getenv functionality.

It's interesting to note, that Runtime.exec() provides a way of setting environment variables - but yet the 
Java APIs don't provide a way of reading them.  Isn't this being a bit hypocritical?

I guess someone closed this late on a Friday when they 
hadn't met their Closed Bugs quota. Why don't you just 
deprecate AWT and SWING while you're at it as not all 
computers have graphics cards/monitors - hence you're not 
being true to Java!!!!!!
Another thing, I think you should split your recently 
closed bugs section into two: 
1. closed (we actually did somthing - used very rarely I 
know but here just for completeness)
2. closed (we couldn't be bothered and came up with a lame 
excuse)

Roll on C# - I can't believe I just said that - but with 
this sorry state of affairs.....

The evaluation (2001/7/25) is nonsensical. By this logic, I can only 
assume that JNI will also be removed, along with AWT, 
Runtime.exec, and possibly others. Yeah, baby! Let's turn Java 
into a completely portable, utterly useless language.

I agree with the opinion that the deprecation message is
misleading, but I think that every java application needs a
shellscript to run properly from command-line, so you can
always pass the environments with a few parameters.

Sometimes there is no other way than accessing the OS's 
environment variables. For example to get the path to KDE's 
directory tree you must use the variable KDEDIR since there 
is no other way to retrieve this value under Java. 
Furthermore the name of this variable remains the same 
under all Unix OS's unlike you mentioned in your evaluation 
statement!

So please reinstate getenv()!

Couldn't you add an "isGetEnvSupported()" method that returns true if the OS supports environment variables, and the code would know if it could use getEnv() (or just have getEnv() throw an exception if the current OS doesn't support it)? It really stinks to say all Java apps are to be totally dependent on a shell sript, or batch file, or shortcut, etc to get environment information. What good is some added portability (from totally removing getEnv() ) if the only way to launch and run your app is going to be totally platform dependent?

Also, the API docs are to be considered broken, as they 
state getenv() will "return the value of the variable, or 
null if the variable is not defined."  It does not state 
this method is a synonym for "throw new Error()" now. So, 
this really is a bug given that the API docs are consistent 
with the specification.

An insteresting thing is how I got to this page, from the 
page of top 25 closed bugs which states in big letters:

     Your bug votes make a difference! 

Maybe not...

getEnv() should be available. Writing your own OS specific 
code infact makes for less portable programs. If this code 
of getting environment variables is put inside the JVM then 
developers have a standard way of accessing the environment 
variables.

I disagree with 'Evaluation'. there are 1000s of examples 
where getEnv can be used in non os specific way.

You can get around this by doing the following:

Create your environment variable e.g. 

ENV_COLOUR=0x0000FF (hex for blue)

When you start the java application do the following:

java -DJAVA_COLOUR=%ENV_COLOUR% etc....

Then in the application: 

String s = System.getProperty("JAVA_COLOUR");

s will equal "0x0000FF"...

Sun's evaluation is arrogant.  I swear that Microsoft has 
broken into their bug database.  Their reasoning is 
specious, and this is one of the highest requests on bug 
parade.  Shame on Sun.  Java is still mediocre at best, and 
this bug underscore the root cause.

Re-open this bug! This decision is a load of horse shit.

This feature should be supported. The work-around is
not reasonable and is kludgy. The needs of this feature
are clear from the large number of posts. The C language's
getenv() method just needs to be wrapped in Java as it was.
Given that it is a common feature now with UNIX, Windows, 
and Mac, there is no reason not to support it (yes I read
the Evaluation!).

When language designers start rejecting incredibly useful 
features because they are not "pure", or "portable", you 
know the language is on the downhill slide.  This is 
exactly what killed C++.  What's even harder to stomach is 
that the "Evalution" here is so clearly wrong.  Please, 
Sun, have this re-evaluted by a real programmer.  Give us 
something useful, or we'll be forced to find a language 
that is.

By the way, I can't even vote for this because it is 
closed! So much for democracy....

It is not because cars allow you to drive too fast that 
they are unsafe and nobody is allowed to use them. Some low-
level processes really need them. Please have this re-
evaluated.

No way - down with getenv()!  Things like environment 
variables are old hacks and should never be used in new 
development.  When dealing with legacy systems which only 
use environment variables you will have more problems 
elsewhere to decry this as the only roadblock.  Most of you 
have missed Sun's original comment - environment variable 
mechanisms may exist on almost every platform out there 
(who cares about DOS - Sun doesn't support Java on DOS), 
but the specifics change so much that they can't all be 
handled uniformly.  Most people I talk to that require 
env's for some purpose simply haven't pursued other 
possibilities.

Since this BUG is closed and won't be fixed with 198 votes,
I guess the only way to vote to have this re-opened and
FIXED is through the comments.  Please fix.

This evaluation pisses me off.  Java is a superior 
language, but with this kind of attitude, Sun risks 
alienating the user community.

Its like road accidents are increased so driver car is 
banned!!! If hackers r using environment variables, do 
something to stop them. or give some sort of authentication 
or something like that.

Now how to access system environment variables. If only MAC 
does not support then return "null" or throw an 
exception "PropertyNotSupportedExcpetion" in that case 
instead of removing the functionality. Changing code as per 
the OS is never a wise move.

Its like road accidents are increased so driver car is 
driving banned!!! If hackers r using environment variables, 
do something to stop them. or give some sort of 
authentication or something like that.

I'm provoked into responding to this by the recent JDC Tech
Tips article on how to use kludges to work around Sun's
ridiculous attitude that getenv is bad.  System.getenv is a
much more convenient way of handling environment variables
than any of the proposed workarounds.  The workarounds all
involve more code and make the system more fragile.

In my work I could use Java to interface with native
binaries running on Unix.  The native code makes extensive
use of environment variables.  I don't care that there are
systems that don't have environment variables because our
programs don't run on those systems, and never will.  I've
done some work on interfacing Java with the native system,
but without System.getenv I'm not keen to deploy it:  it's
simply too fragile to be practical.  Support costs are an
issue.

If this bug was still open it would certainly get a vote
from me.

Oh, and the documentation of System.getenv has been
incorrect since JDK 1.1.  It says that it 'gets an
environment variable', when it does no such thing.

Yep, this sucks alright.

I too was provoked by that ridiculous article to revisit 
this bug. We're obviously up against a bunch of 
induhviduals with little capability for rational thought. 
Ask cross-platform C++ programemrs how to deal with this. 
I've never noticed it as a problem.

The two hundred votes for this should perhaps 
cause "xxxxx@xxxxx 2001/7/25", who hasn't the guts to 
publically admit responsibility for this fiasco, to 
reconsider

Yep, this sucks alright.

OK, so we're going to fix platform specific issues like
Windows NT Service compliance, and use of the mouse wheel,
but we can't take 5 minutes and make String
System.getenv(String) call char* getenv(char*)?  I really
don't care about GUI issues and mouse issues, etc.  I'm a
middleware developer.  Every OS and language I've used has
had an API to access the environment.

I got so irritated that System.getenv no longer works that
I've written a rant about it.  And I've implemented a
replacement using JNI for a few platforms:

http://www.tigress.co.uk/rmy/java/getenv/index.html

Stupid stupid stupid
but hey... there are a lot of other stupid things about 
Java.  The biggest is it's using "offsets" as the basis for 
everything.   I.e. the 1st entry is referenced by zero, the 
second by 1, etc.  This was taken absurdity in the 
calendar's months starting with 0 for January, 1 for 
February being one among many.  

Unfortunately alot of the decisions have been made 
by "system/abstract programmer type guys" and not by real 
life application programmers.

If SUN doesn't wake up Java will only be used by System 
programmers and application programmers will switch to 
microsoft's C#... Hey... and I'm a java fan and don't 
really like C#.

What happened?  The state of this bug briefly reverted to
'in progress', then back to 'closed, will not be fixed'.  In
doing so it lost most of its votes:  where previously there
were 198 there are now only 7.  Bah.

Anyway, my rant and implementations of getenv() for Linux,
Solaris, AIX and Windows are still available:

   http://www.tigress.co.uk/rmy/java/getenv/index.html

What gives, I spent 3 votes on this and it's still just 8.

I am very irritated.  Please RE-OPEN this bug.  It had 198 
votes.  Now it has 8.  The evaluation is WRONG as well.  If 
I create my own environment variable, it's going to be 
there, and it's name's not going to be different on 
different OS's.  Stop treating us like children, and return 
the functionality of getenv.

1 Absolute purists
2 Absolute pragmatists
3 The best mixture of the former two

Group 1 and group 2 are a disaster for a company.
Group 3 would include getenv.

Please put it back! I want to know where Sybase or Oracle 
home directories are.  On all platform Oracle and Sybase 
run on they set env variables that point to their home 
dirs.  The fact that I can't read them easily is very 
frustrating   

I don't see why people couldn't use system property for 
getting non-portable values (such as the user ID), while 
use getenv() for getting other environment variables. E.g., 
I want an easy way to specify the installation directory of 
my Java program. The environment is an easy way to do so, 
and it is my problem then to make this work accross all 
platforms that I want to support. The workaround with 
starting a process that reads the environment does the 
trick, but it causes problems because my program doesn't 
have the privileges for exec(). Further, my program works 
as a service under Windows, so the OS itself prohibits 
starting an external process. According to my oppinion, 
this simple API should be returned to Java.

This is an bad decision.  Anyone with practical experience 
programming applications as a profession will agree with 
me.  Environment variables are present in most business 
operating systems today, and environment variables are 
always different between platforms.  Developers do not 
expect to see exactly the same variable names to access 
values as Sun's argument suggests we do.  Developers only 
expect quick and easy *access*.  What those variables names 
actually are and their possible absence is the developer's 
concern.

This sis ridiculous, big piece of hipocracy of Sun. JDK/JRE
itself and many IDEs requires $JAVA_HOME (and of course
$CLASSPATH is now optional) to be set.

If Sun want me to use getProperty(), JVM ought to import all
environmental variables in the form of env.* or something.

Purism will kill Java!

This is hysterrical, not to mention a pretty significant hassle.

"One of the primary goals of the Java platform is to provide a 
set of APIs that work in essentially the same way across a 
wide variety of operating systems, so that developers can 
write portable programs.  Providing access to information that 
is inherently OS-specific is not consistent with this goal."

Why have JNI then? Doesn't using JNI assume that the Java 
will be using code and functions that are "native" to a specific 
OS???

Well... It seems, sun has done the right job by depricating 
this functionality. For once, if I ask users of my application to 
create an environment variable and set its value to 
something, first of all not all OS users can do that. If I want a 
truly OS independent app, then this has to go. No!??!. The 
other option would be to write your settings in a property file. 
Read the file in your application and you know the rest of the 
story.

Now adding salt to injury: Why not take away the exec() 
function as this too is equally dangerous method? Do I see 
double standards by Sun here?

This is indeed one of the stupidest bugs that Sun has
introduced in their insane quest to make java unusable.

I'm sure Sun must be sick of us clamoring for the return of 
getenv. Well, that's tough. Count me in the clamor.

"Even amongst Unixes there are significant differences;
some define USER as the user's login name, while some
define LOGNAME to have this value, and some (e.g.,
Linux) define both."

So what? I don't care about LOGNAME. I want to get 
ORACLE_HOME. It's the same thing on every system that 
supports Oracle. Or I want to get CATALINA_HOME. It's the 
same on every system with the latest Tomcat software. Or I 
want to get MY_APPLICATION_HOME, MY_APPLICATION_THIS 
and MY_APPLICATION_THAT. It's the same on every platform 
where I put my application.

The application I'm working on uses over a dozen different 
environment variables. The "-D" option is just too bulky for 
everyday use, particularly during design and testing. "getenv" 
is simple, elegant, and used virtually everywhere.

"So while we could easily reinstate the getenv() method
to provide access to the process environment, any code
that invokes this method would inherently be dependent
upon the operating system(s) upon which it is written and
tested."

Everyone is using the kludgey workaround anyway, where you 
run an external command to load up a properties object. It's 
even more OS-dependent than "getenv" might be, with 
programmer design, code and test time added. Plus what one 
programmer writes on one system, might not work on another, 
which requires additional design, code and test time. I 
thought I had a good kludge going, and I published it, and it 
turns out it doesn't work on Win2K. What's up with that? 
Having "getenv" would have solved the whole issue.

Sun should re-instate getenv. Their reasons for taking it away 
border on elitist arrogance, a kind of attitude that can kill 
Java. You guys have been gurus for too long. Come back 
down here with us grunts in the trenches for a while, where 
your boss keeps asking you, "When you gonna finish?" and the 
job market is tight. We don't want Theoretically Pure Java 
Code, we want quick reliable shortcuts that Get The Job Done.

Is it really such a hassle to use -Dx=y on the invokation? 
Surely, that just helps make code more maintainable - in two 
year's time when we come to change the syntax of an 
environment variables, at least we can clearly see who's using 
it (without having to grep through all of the source code for 
every java applications - which may be long-lost).

Encouraging access to environment variables seems 
remarkably like allowing un-prototyped function definitions - I 
thought that went out in the '70s (except for in scripting 
languages) - and for good reason. It's a maintenance 
nightmare.

Sun should be ashamed of themselves, I agree, for ignoring 
200+ votes on this issue, without any kind of explanation.
The suggested workaround (of implementing getenv manually) 
is ludicrous, and the decision to break backwards compatibility 
is shocking (why not use the normal procedure for 
deprecation??)

But I agree with the decision to deprecate getenv. Short term 
pain, long term gain.

Please bring getenv back.

I whole-heartedly agree with all the people above who think 
getenv() should be brought back as soon as possible. Since 
this bug is closed by Sun, let's all vote for the RFE at 
http://developer.java.sun.com/developer/bugParade/bugs/464
2629.html

We understand you cross platform issue, but sometimes java isn't the only piece in the puzzle. Do you really want that mark on your report card "Doesn't play nice with others..." Kinda sounds like Microsoft *egads*.

Since my vote for 4642629 was closed as duplicate for a
totally unrelated bug on UUID generation, I'll take this
opportunity to vent some more:  If java is intended to be a
general purpose programming language it needs to be able to
interface in suitable ways with the OS.  To claim that
getenv is bad because it isn't supported everywhere is
disengenuous - Files, sound, graphics, keyboards, mice,
floats... the list goes on and on.  Nearly all OSes have
some mechanism of allowing general-purpose preference
setting: Java should provide access whenever such a facility
is available.  The only alternatives to a standard API is to
go outside of Java, either using JNI (not portable) or by
wrapping the java program in a script (also not portable). 
Bottom line - the removal of getenv because of portability
reasons merely forces even less portable and maintainable
solutions.
Personally, I would prefer dropping getenv altogether and
merging the functionality into Properties or (better yet)
the Preferences API.
http://developer.java.sun.com/developer/bugParade/bugs/4642629.html

What I really need is String[] getEnv() which returns the entire 
environment. I work on a Java program (Eclipse) which supports launching 
local applications. Our users want to be able to configure additional 
environment variables from within our program. However, when you pass 
an env into Runtime.exec(...), it completely replaces the environment 
instead of just adding the new variables. Because we can't read the current 
environment, there's no way for us to add the user's variables (making a 
"complete" env for Runtime.exec(...)) without removing all other variables.

However, you can imagine a similar case for getEnv(String). We should be 
able to write platform-independent Java programs that allow the user to 
manipulate environment variables on their system (this requires accessing 
the current value). Without getEnv(...) , anyone who wants to support this 
has to write platform-dependent code.

I tried something simple like the following on my PC:

        	Process p = Runtime.getRuntime().
            exec("c:\\windows\\system32\\cmd.exe /C set");
        	InputStream is = p.getInputStream();
        	Properties props = new Properties();
        	props.load(is);
       	props.list(System.out);

Small problem: all the backslashes in the path variables are 
interpreted as character escapes and dissappear! 

Bring getenv() back!

Would be interesting to know how the compiler (which is
written in Java) reads the CLASSPATH environment
variable....  My guess is, w/o looking at the code, that the
OS specific wrapper (javac) does a getenv and passes that as
a parameter to the program?

Many, many people on this thread miss the point. It is not 
that property doesnt work and the -Dx=y isn't viable on the 
command line. 

Its that there ISN'T a command line in most server side code. 
You code is started by the container (EJB, Phoenix, JBOSS to 
name a few of the big solutions). You dont have a command 
line. You dont have a main(). You code is instatiated on 
demand of a client. 

But if you need to know an environment variable you are 
stuffed. The starting program will have a command line, but 
your code is not in control of that. It will have environment 
variables as well, and getenv() would have sorted the problem 
out. 

Please just re-instate this before we all decide to learn C#  
instead. 

Even when the command line is accessible.... I may not 
*want* my parameters to be visible thru a "ps -ef" 
command.  In such a case, my preferred way is to use 
environment variables.

pls reinstate getenv()

Please bring getenv() back. Programmers can handle the
responsibility of making sure their code works across
multiple operating systems, if indeed it needs to.

getenv() simply is a requirement. When you execute a 
program through Runtime.exec and specify your own 
environment variables for that program, it overwrites 
the 'native' environment, and some program refuse to work. 
So, to fix that you eihter need to get all environments 
variables before launching the executable, or you have to 
launch it without being able to set some environment 
variables yourself.
getenv() should not replace getProperty() but exist aside. -D 
is no good, as these values are fixed at startup, and 
environments are by definition dynamic, or else what's the 
bloody use of them.
So, at the moment, as many users I presume, I had to work 
around it, which makes my code less platform independent 
than when using getenv().
Conclusion: Sun totaly missed the point by deprecating getenv
() to make Java more platform dependent. 

IMHO getent() was remoted NOT because of its 
missing in some platform but its arbitrary nature 
across platforms. Environment variables are evil even 
in non-Java development practices. Those of you who 
cry for this function (getenv) are the ones that always 
want a quick and dirty way out of your problems in 
hand with no regards toward the long-term quality of 
the software that you are writing. There are so many 
ways to achieve the same function and to make Java 
colaborate with the non-Java world without resorting to 
environment variables, with use of Java properties (as 
sun has suggested) being the most straightforward 
one. It would be sad if Java were to be degraded to 
meet the needs of programmers who actually don't 
know how to solve their programming problems....

I agree with "brianhu".  Using Java properties is a 
much better solution.  However, rather than to try to 
guess the OS and determine what its environment 
command is, maybe, at most, the OS environment 
command could be included as one of the Java 
properties, to eliminate the guess work and allow 
access to the OS environment as the workaround 
shows if the implementer really wants to use the 
environment rather than Java properties.  This property 
could be null for an OS that has no outside 
environment (a pure bootable Java OS, for example).

wcrosman wrote:

It seems to me that if the 'C' language has a Standard 
for getting environment variables (stdlib.h) getenv() that 
java could build in and utilize that functionality as in the 
following'C' code'  snippet.

JNIEXPORT jstring JNICALL
Java_DLLTest_getEnv (JNIEnv * env, jobject obj, 
jstring name) {
   const char *str =
      (*env)->GetStringUTFChars(env, name, 0);
   char *ret = getenv(str);
   (*env)->ReleaseStringUTFChars(env, name, str);
   return (*env)->NewStringUTF(env, ret);
}

This code does not work properly: the environment 
variables are normally coded according to in the 
current OS locale (which may include variable 
codepages). So the environment may contain arbitrary 
sequences of byte values, which may not be 
appropriate to send back to Java with NewStringUTF() 
which assumes a modified UTF-8 encoding scheme.

On Windows, the proper way to avoid the transcoding 
nightmare would be to use _getenv() to get the 
environment directly coded in UTF-16, and to use 
(*jni_env)->NewString() rather than (*jni_env)-
>NewStringUTF() to return these UTF-16 strings to 
Java. It's the C library implementing _wgetenv() that 
makes the necessary conversion from the OS-
version&locale specific encoding to UTF-16 (as coded 
with C type "wchar_t".)
Be careful with JNI's UTF interface. It causes lots of 
problems within internationalized systems (including 
in the JNI implementation of some native methods of 
core Java classes, as provided by the JVM integration 
native library).

yes please reinstate getenv!

Thank you for reconsidering this position.

For java to be a general purpose programming language it needs to be able to interface in suitable ways with the OS.

Now if I only had a way to check the free disk space (RFE: 4057701).

Please add me to the overwhelming demand.

Thank you

brianhu ,

Why won't you suggest then to remove all plataform specific problems. Than we can turn Java into an echo utility, printing text to the screen. Oh wait, some systems does not support that...

Interesting, they removed getEnv() but  let Preferences in. 

Evaluation states: One of the primary goals of the Java platform is to provide a set of APIs .... so
that developers can write portable programs.

getenv actually helps achieve this goal. See the simple use case, where Windows filesystem has drive designation, but Linux/Unix doesn't. If getenv is still there, I can use it to hide the difference and write the portable code below:

String configFile = System.getenv("APP_ROOT")+ "/config/xyz.cfg";

In Windows I define APP_ROOT, for instance, as "d:/apps/home" and in Linux as "/var/apps/home" and make the code totally portable. So having getenv should be a asset instead of a liability to the stated goal.

-KC

!!!
And now how can I get the environment variable in JDK 1.4 ?

100% of all the apps I have ever worked on were run on Unix, Windows, and/or Mac OS X, all of which have environment variables available.  I suspect that this is true not only for my applications, but for the overwhelming majority of apps out there.  Why not give us the freedom to choose whether or not we want this.  The portability issue regarding environment variables is worthless in most cases, and the benefit of access to the environment is great.

- Keith R. Bennett

We're up to Java 1.6, and I looks like getPID is still not there.

By the way, System.getPID() should return a String instead of an int, in order to support the widest number of platforms (including those that give processes actual names instead of numbers).