James M Snell wrote:
Yeah, the challenge I have with this is that it makes the test
circular... testing the output of a function against the output of the
same function. We need to understand why the test is failing on the Mac
and figure out if it's something we need to fix.
- James
Yeah, the only thing that's still being actually tested in my diff are
that the default encoding is what it's supposed to be. I can see
arguing that beyond that, the tests are superfluous in that it's commons
codec's responsibility to generate correct output; that said, what you
want is proper encoding handling, so the way the tests are actually
structured is preferable. At any rate, if the encoding is crucial and
it's not working on a popular(?) platform, that's probably worth knowing.
IMO, the three most likely causes are a file encoding problem, an Apple
JVM bug, a commons codec bug, or some kind of interaction between the
latter. Since I'm unfamiliar with the other stuff, though, I'm not sure
where I'd start, so I've been looking at the file encoding angle.
Both OSes think their respective copies are encoded as UTF-8; I tried
iconv to iso-8859-1, and for fun, to utf-8, with the same results. One
thing I didn't try yet was replacing the é in the test string with
\u00e9, which should answer that question. I'll try that when I can get
some time later. If none of that pans out, I'll start exploring the JVM
angle.
On another topic: is the current plan to have a 0.30 release soon after
the APP draft is submitted to the IESG?
AC
