Though many system properties are read-only, the VM and the runtime system
allow them to be set, sometimes with unpredictable if not disastrous results.
We should identify precisely which system properties are read-only and disallow
them from being set either on the command line or via the methods in the
java.lang.System class.  --   xxxxx@xxxxx   8/11/1998

N/A

This should be done, but careful thought and possibly some API changes are
required.  It's too late for 1.2.  --   xxxxx@xxxxx   9/3/1998

Usages of  java -Dfile.encoding=SJIS should be supported.
Otherwise how can we regression test NLS bug fixes?  Only
one or two machines in our lab have foreign locales loaded.
 -Thomas Wang from HP ejl lab

I agree with Thomas.  Being able to set this property is 
much better than having to hard-code every IO routine to 
explicitly state the character encoding.

Another good reason to include especially the possibility 
to set file.encoding on all JVMs is this: The algorithm 
which automatically sets this property on JVM startup is 
undocumented and sometimes leads to undesired results. We 
just experienced this problem on our systems while using a 
change root environment for a server program on a Linux 
machine.

Within the change root environment, file.encoding defaulted 
to some strange ANSI 1968 coding (probably just US-ASCII), 
whereas, otherwise, the default was iso-8859-1 on the same 
machine. For obvious reasons, we need both settings to be 
consistent for our system to work, but this seems to be 
impossible to achieve unless we remove the change root 
environment, thus creating a security leak...  :-(

Evaluation: "It's too late for 1.2"

It's too late for 1.4 now as well, maybe version 1.5 ?

why is sun so arrogant on this?  file.encoding setting behaves 
differently from paltform to platform, which is against java's 
own advocate.  the rumor is that .net can do better:-)

2 luke_hillary:
now it is too late for 1.5 ;-(