DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2291

Reading "META-INF/services/" should NOT assume default character encoding is UTF-8





------- Additional Comments From [EMAIL PROTECTED]  2001-10-04 12:11 -------
I fully agree with Alex on this one.
As long as the /META-INF/services/* contents are standardized to be UTF-8, we 
must explicitly use it, regardless of the platform's native encoding and 
specific JVM's features (like IBM's "file.encoding" system property on Java for 
OS/390).
In my humble opinion, a good global solution for this problem would be if Sun 
came up with an API for reading service providers properties; then, the 
specification of how to read & treat those properties will be hidden from us.

As for Gary's comments from July 13th: there is an important point in what you 
wrote, and I believe that Sun has to change the service providers' 
specification to also be relevant for any META-INF/services/* found in the 
classpath, regardless of whether it's in a JAR file or not (I think we should 
wake them up on this subject). However, in my opinion, even being the standard 
not so clear, doesn't legitimate running away from it.

About the ".properties" files: well, according to the java.util.Properties 
class' specification (JDK 1.3.1):

"When saving properties to a stream or loading them from a stream, the ISO 8859-
1 character encoding is used. For characters that cannot be directly 
represented in this encoding, Unicode escapes are used; however, only a 
single 'u' character is allowed in an escape sequence. The native2ascii tool 
can be used to convert property files to and from other character encodings."

In the java.util.PropertiesResourceBundle specification:

"See (java.util.)Properties for more information about properties files, in 
particular the information on character encodings."

So I guess that the standard applies that ".properties" files MUST be encoded 
in ISO8859-1, regardless of what IBM wants; but this problem is an IBM's JVM's 
specific issue, which we are able to solve with IBM themselves.

As far as Xalan2-J is concerned, I think we should change this to explicitly 
use UTF-8 as the encoding.

Reply via email to