UTF-8 output: regression or not fixed or 3rd party problem?

Help/Discuss
1

There still is an issue with UTF-8 encoded output, with sometimes breaking encoded characters and printing � (0xEF BF BD) instead.

2

Hi Christian,

Thanks for the heads up. Perhaps https://github.com/gradle/gradle/commit/1746300a did not fully fix the issue. I would be very surprised if 3.2 was fixed and 3.2.1 was broken again given the isolated changes in 3.2.1, but that would be very useful to confirm. Would you be willing to try 3.2.0 and confirm?

Are you able to confirm this locally in addition to Travis CI, or can you give me instructions so that I can reproduce myself with the junit5 project?

Thanks,
Eric

3

Hi Eric,

locally, I couldn’t reproduce the failure, yet.

I’m working on a Win 10 x64 machine with Oracle JDK 8 (112) and forcing IDEA via idea64.exe.vmoptions setting -Dfile.encoding=UTF-8 to use UTF-8 in the “Run” console view. In almost 9.000 lines of build log, there’s no single � char. That is what saw with Gradle 3.2.0.

I’m also trying a local Linux (WSL based) build, but it doesn’t start here, yet. Permission issues…

To reproduce the Travis output, just clone/checkout https://github.com/sormuras/junit5/tree/trees (trees branch) and execute gradlew build.

Hope that helps,
Christian

4

Looking at the raw log from https://travis-ci.org/junit-team/junit5/jobs/180752503 - which does contain � chars (line 460 and others) - there might be an old Gradle 2.13 version doing the build: https://api.travis-ci.org/jobs/180752503/log.txt?deansi=true (line 129 and below)

The build explicitly calls ./gradlew for the wrapper version, but may be there’s a problem with that on Travis?

5

Thank you for the additional information.

I see the correct output locally using Gradle 3.2.1. Before I dig deeper here into Travis CI, mind if I ask what the impact of this bug is on you and if you’re able to work around it.

Cheers,
Eric

6

Here, the impact is primarily aesthetic – but if one compares log output textually to a reference w/o the � chars, the assertions may fail unpredictably.

I don’t know of any workaround that allows extended ASCII encoded texts to print always as expected at Travis CI.

Cheers,
Christian

7

This simple Gradle task

task GRADLE3329() {
  def text = " ▓ " + ("✔" * 10) + (" a b c d e f " * 2) + ("✔" * 10) + " ▒ "
  1000.times {println text + text}
}

produces the output at https://travis-ci.org/sormuras/beethoven/builds/183432849 with a lot “���”.

8

Thank you for the simple and effective way to reproduce this. I have
created https://github.com/gradle/gradle/issues/1008 to track work on it.