Name: bsT130419			Date: 09/17/2001


java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


Properties file i18n support is painful due to the restriction of requiring an
unusual ASCII encoding (\uxxxx) for Unicode characters.

This has been mentioned many other times in other bug reports (4081034, 4172926,
4069051, 4094886, 4101795, 4077980, 4035543, 4153531, 4035169, 4383964, 4209903
... I could keep going but I think you get the point).

Obviously, many other people before me have complained about this problem and
all been met with the dreaded Will Not Fix.  However, I still feel that we need
some sort of solution to this problem.  My own team has wasted a lot of time on
this issue, as our company's translation system Really Wants (TM) to use native
encodings, and for various reasons using native2ascii is very annoying.  Our
current solution (don't laugh) involves a custom InputStream which wraps a
Reader in order to translate the characters into \uxxxx escapes as they are
read.

I suggest two possible solutions which will hopefully please everybody:

1) an encoding tag which can be embedded at the beginning of a properties file,
something along the lines of #@encoding=EUC-KR or something like that.  Without
this special tag, the ordinary ASCII encoding would be assumed.  Naturally, the
Properties object would remember which encoding had been used to read it and
default to storing using the same encoding.

2) load(InputStream in, String encoding) and store(OutputStream out, String
encoding) methods.  I believe that this is preferable to using Readers and
Writers (an idea that has been rejected before) because it will not encourage
people to rely on platform's default encoding happening to match the properties
file's encoding.

Both solutions would address existing complaints about this API without breaking
current usages or encouraging bad habits.  I'd personally prefer to see both of
them be implemented, but *anything* is better than what we have now.  If you
don't like either of my ideas, feel free to come up with something else, but
please do something about it.
(Review ID: 131967) 
======================================================================