Name: jk109818			Date: 02/25/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :
all other operating systems too.


A DESCRIPTION OF THE PROBLEM :

This is a request to reconsider the evaluation for Bug ID: 4199068
and to also consider a setenv method.

I would like the getEnv to be brought back with a new
setEnv.  For example on windows you would have to
setEnv(USERNAME, value)
on Unix
setEnv(USER, value)


Bug 4199068 was closed as will not fix, but due to the number of votes
placed on this rfe, and the number of comments that have been placed
on this bug, please reevaluate.

Here are reasons to reconsider:

There are a number of ways to make a program non-portable in java if I really wanted to already.  In 1.4 I could access a specific part of the windows registry making my program non-portable.  I believe it is the developers issue to make sure his program is portable.  There are some programs developers want to write without the intention of being portable(ie. we plan on using the windows registry to have an applet launch a windows application).  You are taking away from choice that
developers should be given.
thankyou in advance for your reconsideration, and I hope Sun can think about this a little more before deciding to keep it out.

one more thing, people are making their programs non-portable now because they are accessing environment variables by executing the respective commands using exec instead.  Instead of

setenv("NEW_ENV", <some value>)

but instead they are doing this
if(OS==windows)
    exec("set NEW_ENV="+<some value>);
if(OS==flavor of UNIX)
    exec("NEW_ENV="+<some value>);

People still create non-portable code, they just create uglier non-portable code.
thanks

Please visit the Bug Parade here to view the other comments on this:
http://developer.java.sun.com/developer/bugParade/bugs/4199068.html

(Review ID: 139305) 
======================================================================