United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4749531 : Enable user editable properties files in other encodings

Details
Type:
Enhancement
Submit Date:
2002-09-18
Status:
Resolved
Updated Date:
2014-11-12
Project Name:
JDK
Resolved Date:
2003-08-15
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.util
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:
5.0 (tiger)

Related Reports
Relates:
Relates:

Sub Tasks

Description

Name: nt126004			Date: 09/18/2002


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


FULL OPERATING SYSTEM VERSION :

OS independent RFE



A DESCRIPTION OF THE PROBLEM :
I'm going to try this one more time, and hopefully someone
will actually give it a few seconds of thought before
closing it as "Will not fix".

Please reevaluate bug 4503634, which was summarily closed
without being adequately addressed.

  To reiterate my request:  I need a way to include
internationalized messages in Java programs for display to
the enduser.  Internationalized properties files are a pain
in the butt to deal with due to the bizarre \uxxxx encoding,
and there's no reason for such a commonly-needed thing to be
a pain in the butt.

The evaluator said that the Properties class was "legacy",
phased out in favor of Preferences.  Just so there's no
confusion:  we have been using Preferences since it was
first released.  However, the Preferences API does not
replace all usages of Properties, such as in conjunction
with PropertyResourceBundle.  So we continue to use
properties files to store I18N messages.  And it continues
to be a pain in the butt to deal with international
characters, because we're stuck with the default encoding.
I would love to be able to use UTF-8 for all of the files,
but we don't have the option (short of implementing weird
hacks).

I can accept an evaluation of "not worth the effort, deal
with it" (although I'd be happy to make the changes myself
in such a case).  But I cannot accept an evaluation of
"Properties is a legacy API" unless you point me to APIs
which replace all usages of said class, and Preferences
isn't enough to do that.

I simply don't see the relation between the two.  Yes, properties files 
can be used to store user preferences, and that specific usage of them 
is (quite rightly) deprecated in favor of Preferences, but properties 
files are also, and far more frequently, used to store static 
information such as defaults and messages.  Every Java program I have 
ever worked on, whether written by me or by others, does this, and I 
have never once seen Preferences used for that purpose.

I just ran a count -- the JDK itself contains two hundred and fifty 
static properties files.  Most of them are used to store 
internationalized text, which is exactly what everybody else is doing 
with properties files.  Unless you are suggesting that Sun itself is 
doing the wrong thing by using properties files for this purpose, I fail 
to see how Preferences is any more relevant to my request than, say, 
SecurityManager.

I would also point out that this RFE has been requested *over and over* 
in the past.  This is a very simple change.  I am certainly not the only 
person who is baffled why it is so complicated to fix this.  Again, I'd 
be more than happy to fix the stupid class myself, if someone would only 
include the change.

Of course, every prior request for this has also been closed as Will Not 
Fix, so I'm not sure why I still hold out hope.

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 164261) 
======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b16


                                     
2004-06-14
EVALUATION

This issue can be re-examined for Tiger. Unfortunately allowing other encodings will require us to adopt a backward compatible means of identifying the encoding of the properties file.
###@###.### 2002-10-02

We will propose new Property load and save methods that use XML format for Tiger. This should allow properties files to be easily editable in other encodings.
###@###.### 2002-10-10
                                     
2002-10-10



Hardware and Software, Engineered to Work Together