Submitted On 17-MAY-2002
s_ananth
This is a really nice must have feature. I don't think this
is very difficult to implement inside java. Consider
applications that donot use the JNI but needs environment
variables. Just for reading if we start using the JNI, the
applications will sleep in the beginning. Please consider
this RFE
Submitted On 13-MAR-2003
walterstroebel
(name and email suppressed, I'm getting enough SPAM already)
Obviously getenv is a completely portable system feature
with equivalences in every language and OS (I'm aware of the
MACOS issue but I'm convinced there is something else that
fullfills the same function).
The environment as passed to the JAVA VM should therefore be
accessible in the language. I personally do not care if this
is through System.getProperty("env.var") or System.getEnv
("var").
Setenv is a harder proposition and quite often useless as a
program's environment is merely a copy of the parent's. The
only sensible approach is the current one: pass a child's
environment along with Runtime.exec().
Btw: Supporting the environment in exec() but not in System
means one cannot exec() JAVA applications in a system
compliant manner...
Submitted On 10-APR-2003
mabdellateef
In large projects we rely on locating files relative to a root
point, if this is hardcoded or set as an absolute path, the
application won't be portable. We need the getEnv, setEnv
back as we do benefit from using them a lot.
I can simply see Java relying on CLASSPATH variable for
launching an application, why do I have to work otherwise in
my own projects.
Thanks for considering access to these methods back.
Submitted On 28-APR-2003
stevel56
This is such an obvious feature to have its ridiculous. Why
can't this just be re-implemented?
Submitted On 29-APR-2003
mthome
getenv-like functionality is clearly completely portable -
most OSes have features which directly support the most
common interpretation. Those OSes which do not, generally
lack such a feature completely. Previous arguments against
support of getenv have focused on the lack of standard of
*content*, rather than the lack of standard API - this is,
IMO, not java's problem. Attacking it anyway has slowed
acceptance of java as a language due to it's lack of
integration with nearly universal OS features and has forced
developers to work around it by using hacks (wrapper
scripts? ugh! calling exec!?!? Ack!) that are FAR less
portable and unmaintainable than undeprecated getenv could
ever be.
That said, I would actually prefer integrating getenv
functionality into one of the other facilities - e.g.
System.getProperty("myprop") or perhaps the Preferences API.
Submitted On 17-JUN-2003
andrew.webb@med.ge.com
I support having System.getenv()
do what its documentation says it does:
Gets an environment variable.
Returns the value of the variable, or null if the variable is not
defined.
Yes, programmers should be advised that there is a Java
standard way to get some system properties via
System.getProperty(), but no, they should not be prevented
from getting infomation from the system in a very established
way.
I don't want to resort to some OS dependent method to work
around the removal of these function.
This is one of the very few areas in which I have to say that
the C/C++ library support is better than Java.
If you deny this request for enhancement, then at least make
the documentation match the reality, and describe the
function accurately.
Submitted On 04-JUL-2003
jabusia
The state above is wrong! It should rather be "Closed,
duplicate of 4199068"! All interested in bringing "getenv" back,
please move your votes to 4199068!
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
