java.util.Properties

Urban Widmark urban@svenskatest.se
Tue Oct 3 14:30:00 GMT 2000


Hello
The libgcj (and Classpath) java.util.Properties appears to have problems
with encoding values (and keys for Classpath) for writing. The
new_lead/leading checks make it only output a \ if the first thing in the
string is a space. This produces identical(?) output as 1.1, but
completely different from 1.2 (1.2.2-RC4, linux x86, blackdown jdk).
JDK1.1.8_v1 writes:
"two spaces=spacy "
"a space=a value"
which is the same as I get when copying the encoding code from libgcj or
Classpath. (Trying to compile libgcj was a painful experience ...)
1.1.8 reads that like this (key -> value):
"a" -> "space=a value"
"two" -> "spaces=spacy "
Grr, it can't read what it writes! 1.2.2 can not read this either.
JDK 1.2.2 generates this:
"a\ space=a\ value"
"two\ \ spaces=a\ value\ "
Which it can read back, spaces and all. 1.1.8 gets confused by the spaces
in the key but parses the value correctly. A 1.2 file:
"key=a\ value"
"sdsdfjhsdf=asd\ asd\ asd"
can be read by both.
The javadoc I have says for store() "Space characters, but not embedded or
trailing space characters, are written with a preceding \" which does not
appear to match what the 1.2.2 JDK produces. But the 1.2 format is much
more useful since both 1.1 and 1.2 can read it if there are no spaces in
the key, and 1.2 can handle spaces in the keys.
Is libgcj/Classpath aiming for 1.1 or 1.2 compatibility?
/Urban


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /