scala.xml.XMLTestJVM fails on Scala 2.11 on Java 6

[SethTisue]

this was caught by the Scala 2.11 community build

it's reproducible standalone though, just make sure you're running on Java 6, then xmlJVM/testOnly scala.xml.XMLTestJVM and boom:

[error] Test scala.xml.XMLTestJVM.writeReadNoDeclarationDefaultEncoding failed: expected:<...klmnopqrstuvwxyz{|}~[???????????????????????????????????̀???????????????ͅ???????????????????????????????ֿ???????]</x>> but was:<...klmnopqrstuvwxyz{|}~[ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ]</x>>, took 0.0070 sec
[error] Failed: Total 33, Failed 1, Errors 0, Passed 32
[error] Failed tests:
[error] 	scala.xml.XMLTestJVM

question: is this is a real failure, or is this happening because we're actually testing whatever version of scala-xml the compiler depends on, rather than testing the scala-xml we just built...?

meta-question: why didn't we know about this from Travis-CI, why did the community build have to catch it?

[SethTisue]

oh maybe this is a test that's sensitive to the platform default encoding? because I'm on a Mac and:

Welcome to Scala 2.11.12 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_65).
Type in expressions for evaluation. Or try :help.

scala> System.getProperty("file.encoding")
res0: String = MacRoman

but:

Welcome to Scala 2.11.12 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_162).
Type in expressions for evaluation. Or try :help.

scala> System.getProperty("file.encoding")
res0: String = UTF-8

[SethTisue]

and running the 2.11 JDK6 community build on a Mac is something I haven't tried to do in ages; I'm only doing it now because our Jenkins is being redone. so that would explain how this could have gone undiscovered for quite a while, it doesn't need to be a recent regression

[ashawley]

oh maybe this is a test that's sensitive to the platform default encoding?

It could be. It's been a while, but I thought #121 would have fixed the encoding regardless of JVM settings.

[SethTisue]

the test does outputStream.toByteArray without specifying an encoding, maybe that's the cause?

never mind, there is no opportunity specify an encoding there

[SethTisue]

this makes the test green:

-    val streamReader = new java.io.InputStreamReader(inputStream)
+    val streamReader = new java.io.InputStreamReader(inputStream, XML.encoding)

but then it doesn't fail if I revert e15ce87, so apparently that makes it no longer actually test anything?

@ashawley hoping you can figure this out since you've been here before, I'm just fumbling around...

[ashawley]

I'm on a Mac

I can't recall, is file encoding inferred from shell environment LANG?

> eval sys.env.get("LANG")
[info] ans: Option[String] = Some(en_US.UTF-8)

Ok, I see you're comparing Java 6 and Java 8: Maybe that behavior changed?

[SethTisue]

at one point I know it was normal for System.getProperty("file.encoding") to return MacRoman on MacOS, I'm not sure of the details on when it changed, or whether the value you get ever depends on anything else other than JDK version

[SethTisue]

I would you think you could reproduce the error on Linux just by starting up sbt with -J-Dfile.encoding=MacRoman

[ashawley]

this makes the test green

Interesting, I believe what you suggest should probably be the way the test is written. I guess that was an oversight. Rather than relying on the XML.encoding everywhere in the test, the test probably should probably also use more literals for the encoding ("UTF-8", "ISO-8859-1", ...). Otherwise, having XML.encoding everywhere, it just becomes a data in and data out issue, and it doesn't "actually test anything" as you say.

The original test tried to show that switching from ISO-8859-1 to UTF-8 would be a breaking change, and was originally motivated to prove that ISO-8859-1 isn't forward compatible with UTF-8 (although US-ASCII is). Obviously, the test should be written to only prove that the XML.encoding setting isn't causing the defect found in #121.

I'll see if I can sharpen up the test, and even make it work in Java 6 regardless of the JVM's default file.encoding.