TestHttpUrlConnectionHelper.openInputStreamGZipOk fails on Windows

[ecki]

While building the 1.35 SNAPSHOT master (abde52) on windows one test fails:

Dez 30, 2014 10:16:15 AM com.tagtraum.perf.gcviewer.util.HttpUrlConnectionHelper openInputStream
INFORMATION: Reading 559 bytes from http://localhost/gclog.txt; contentType = text/plain; contentEncoding = gzip; last modified = Tue Dec 30 09:35:44 CET 2014
Tests run: 233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.128 sec <<< FAILURE!
openInputStreamGZipOk(com.tagtraum.perf.gcviewer.util.TestHttpUrlConnectionHelper)  Time elapsed: 0 sec  <<< FAILURE!
 java.lang.AssertionError: openInputStream(conn,gzip): # bytes read at position 0 expected:<2944> but was:<2976>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:743)
    at org.junit.Assert.assertEquals(Assert.java:118)
    at org.junit.Assert.assertEquals(Assert.java:555)
    at com.tagtraum.perf.gcviewer.util.TestHttpUrlConnectionHelper.verifyInputStreamWithFile(TestHttpUrlConnectionHelper.java:183)
    at com.tagtraum.perf.gcviewer.util.TestHttpUrlConnectionHelper.testOpenInputStreamOk(TestHttpUrlConnectionHelper.java:156)
    at com.tagtraum.perf.gcviewer.util.TestHttpUrlConnectionHelper.openInputStreamGZipOk(TestHttpUrlConnectionHelper.java:80)
Failed tests:
  TestHttpUrlConnectionHelper.openInputStreamGZipOk:80->testOpenInputStreamOk:156->verifyInputStreamWithFile:183 openInputStream(conn,gzip):
# bytes read at position 0 expected:<2944> but was:<2976>

First I thought the problem has to do with URLConnection converting unix linefeeds to windows linefeeds, but when I look at the .gz file it looks like it already contains Windows linefeeds and it should never be the same length as the .txt which is in unix convention:

C:\ws\github\GCViewer\src\test\resources\openjdk>gunzip -l SampleSun1_6_0PrintHeapAtGC.txt.gz
compressed  uncompr. ratio uncompressed_name
      559      2976  82.8% SampleSun1_6_0PrintHeapAtGC.txt
C:\ws\github\GCViewer\src\test\resources\openjdk>gunzip -c SampleSun1_6_0PrintHeapAtGC.txt.gz | wc -c
   2976
C:\ws\github\GCViewer\src\test\resources\openjdk>gunzip -ca SampleSun1_6_0PrintHeapAtGC.txt.gz | wc -c
   3008
C:\ws\github\GCViewer\src\test\resources\openjdk>wc -c SampleSun1_6_0PrintHeapAtGC.txt
   2944 SampleSun1_6_0PrintHeapAtGC.txt
C:\ws\github\GCViewer\src\test\resources\openjdk>dos2unix -D SampleSun1_6_0PrintHeapAtGC.txt
C:\ws\github\GCViewer\src\test\resources\openjdk>wc -c SampleSun1_6_0PrintHeapAtGC.txt
   2976 SampleSun1_6_0PrintHeapAtGC.txt

mvn 3.2.5 with Java 7u72 on Win7 x64 (german)

[chewiebug]

I have run the tests using mvn 3.2.5 with Java 7u71 and Java 8u25 and can't reproduce your test failure. What tool do you use to clone the git repository? It seems weird to me, that the .txt file is with unix line endings. On a windows platform, I'd expect it to contain windows line endings (.gitattributes should make sure, that it is so).

[ecki]

My git is configured to not use the windows line endings for text files. Is this test supposed to test if the url stream is actualy normalizing the line endings to the platform defaults? Otherwise I would simply compare the length to a constant instead to a different file.

[chewiebug]

The goal of this test is to check, whether reading from a gzip stream
yields the same results as reading the file directly. Because of those
line ending problems, this test probably had better be rewritten. Line
endings are not interesting in the context of this test.

[chewiebug]

I have pushed a fix to the repository. Do the tests run through now?

[ecki]

Thanks, the test pass now with acc3634. There are some trailing space introduced.

[chewiebug]

Thanks for testing!