[Bug]: Two Java sources contain a literal NUL byte, so Git treats them as binary

[fskorgen]

Apache Hop version?

2.20.0-SNAPSHOT

Java version?

21

Operating system

Windows

What happened?

I found this while preparing a pull request for another issue. After a build, two files I had not
touched showed up as modified.

Both files use a NUL character as a separator, and it is written as a real byte in the source:

• HopGuiSearchHelper.java, line 461
• MetadataPerspective.java, lines 3161 and 3180

Git sees that NUL and treats these two files as binary. Because of that it does not normalize line
endings for them, so on Windows the build rewrites both files with CRLF. They then look like a
4200 line change, even though nothing has really changed - git diff --ignore-cr-at-eol shows
nothing at all. I have to run git restore after every build, and it is easy to include that noise
in a pull request by mistake.

If the NUL is written as the escape "\0" instead of a real byte, the character is the same at
runtime and both files become normal text files for Git. It is a three line change.

I have the change ready and tested locally, and will open a pull request for it as soon as this
issue has a number.

Tested on main (2611fdfdda), Windows, Java 21.

The ten .txt files that Git also reports as binary are test files with special bytes and should
stay as they are.

Issue Priority

Priority: 3

Issue Component

Component: Infrastructure