clojure/data.xml fails test-indent and test-indent-str when tests are run on AArch64/ARM64

Question

This is a weird one, and I'm not sure how to provide a repro. But basically, when I try and build data.xml on ARM64, when the tests run, two of its tests fail. When I do the same on X64 architecture, no such failure.

Testing clojure.data.xml.test-emit

FAIL in (test-indent-str) (test_emit.clj:123)
expected: (= expect (indent-str nested-xml))
actual: (not (= "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n" "<?xml version=\"1.0\" encoding=\"UTF-8\"?><a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n"))

FAIL in (test-indent) (test_emit.clj:131)
expected: (= expect (.toString sw))
actual: (not (= "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n" "<?xml version=\"1.0\" encoding=\"UTF-8\"?><a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n"))

Ran 9 tests containing 12 assertions.
2 failures, 0 errors.

The difference in indentation seem to be that on ARM64, there is a missing newline after the xml declaration:

"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n"
"<?xml version=\"1.0\" encoding=\"UTF-8\"?><a>\n  <b>\n    <c>\n      <d>foo</d>\n    </c>\n  </b>\n</a>\n"

Answer 1

It turns out I was using an older version, newer version don't have this issue.

For others interested, I also looked into what had changed, and newer versions added this line: https://github.com/clojure/data.xml/blob/0a26f131658c58d16a20175ca0bba40330ce33c0/src/main/clojure/clojure/data/xml/jvm/pprint.clj#L21 which seems to solve it for AARCH64 as well.

Comments

Good educational answer. There is a very interesting comment in that commit.

Answer 2

What are the specific Java versions?

Answer 3

What commit of data.xml source code are you using, and have you made any changes to it? With the latest version of data.xml, those tests appear like they should be omitting everything before the first occurrence of <a> in those strings before they are compared, so it is especially confusing that the <?xml ...> part is included in the report of what is miscomparing.