On Mar 26, 2009, at 2:44 PM, David Andrews wrote:
Great catch, Steve. Thanks! My z/OS system now tells me: $ java -Dfile.encoding=ISO8859-1 -Dconsole.encoding=IBM-1047 -cp clojure.jar clojure.lang.Repl Clojure user=> (+ 1 1) 2
You're quite welcome, David. I gather (via Google search) that you've been interested in this since November, I'm sorry I wasn't aware of it earlier.
With your modified Clojure, you may be able to get rid of the "-D" command line args as well.
I see in the mailing list history that the UTF-8 encoding for the default input and output streams was from a patch that was primarily intended to institute a standard for Clojure's file input format as UTF-8. Even at the time, the requester (Chas Emerick) was unsure of the advisability of a change away from Java's default encoding for Clojure's default input and output streams. The patch included both those changes, so that's the current behavior of Clojure.
I think as an interoperability enhancer, having Clojure source files be required to be UTF-8 encoded is a good idea. In contrast, I think this z/OS experience shows that doing so for the default input and output streams (and therefore for the REPL) may do more harm than good. Presumably our JVM host is providing default encodings for each platform for a good reason and we should (by default) honor that.
Right now I think this should be an issue against Clojure and would welcome some discussion about it. My inclination currently is that we should keep the UTF-8 standard for encoding Clojure source files, but change the default input and output streams (and therefore the default REPL) back to using the platform's default encoding(s).
There is more discussion in this thread: http://groups.google.com/group/clojure/browse_thread/thread/39ba33d15e7633e0/191ee8b83f815189 --Steve
smime.p7s
Description: S/MIME cryptographic signature
