> On 13 Jul 2023, at 7:20 am, Andrew Rowley <[email protected]> > wrote: > > On 13/07/2023 9:02 am, David Crayford wrote: >> I'd like to understand your reasons for wanting to encode your Java source >> files in UTF-8. It's important to note that the default encoding on z/OS is >> IBM-1047 (EBCDIC). We typically use ISO8859-1 and have to specify the >> "-encoding iso8859-1" option when using the javac compiler. As mentioned >> earlier, tagging files as UTF-8 can lead to unexpected issues, which is why >> it's not commonly done. > > I commonly see > <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> specified > for Java projects.
We specify <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> in our Maven builds as most of the time we are building off host on machines with UTF8 locales. However, we tag our files ISO8859-1 on z/OS other then some YAML docs that must be tagged UTF-8 or else SnakeYaml barfs when reading it from the class path which doesn’t support tags :). The server runs with file.encoding=ISO8859-1 as well. If we cared about the euro sign we could change it to ISO8859-15 which is still an 8-bit character set. It’s those pesky codes above 0x7F in UTF-8 that cause the issues. > > I have wondered how this works if you try to compile on z/OS. The obvious but > possibly wrong answer would be to checkout in git as UTF8 and tag the files. > > If you encode as ISO8859-1, what happens to e.g. literals with characters not > in ISO8859-1? An obvious one would be the Euro character, but I'm sure there > are more. > > -- > Andrew Rowley > Black Hill Software > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
