FilesPlume.inferLineSeparator always returns the platform line separator; the annotator mixes line endings #2235

FilesPlume.inferLineSeparator(File) in plume-util never infers the line separator of the file; it always returns the platform's line separator (and "\n" if the three counts tie on a platform with another separator).

Cause

String s = r.readLine();
...
if (s.endsWith("\r\n")) {
  dos++;
} else if (s.endsWith("\r")) {
  mac++;
} else if (s.endsWith("\n")) {
  unix++;
}

BufferedReader.readLine() returns the line without its terminator, so none of the three tests can succeed. dos, mac and unix stay 0, and the method falls through to the tie-breaking code that returns the platform separator (lineSep).

Effect on the Annotation File Utilities

annotator/Main.java calls FilesPlume.inferLineSeparator(javafilename) and uses the result for the import lines it inserts. On Windows, a source file with LF line endings gets CRLF import lines, and a CRLF file on Linux gets LF import lines, so the file ends up with mixed line endings. The annotator tests (annotation-file-utilities/tests) do not notice on Windows because their diff calls ignore carriage returns (--strip-trailing-cr); that workaround can be removed once this is fixed.

Possible fix

Count the terminators from the raw characters, for example by reading the file with a Reader and looking for '\r' (followed by '\n' or not) and '\n', instead of using readLine(). A regression test needs files with each of the three line endings, independent of the platform.

The code lives in plume-util (org.plumelib.util.FilesPlume, the version org.plumelib:plume-util that the Checker Framework depends on). The eisop-plume-lib/plume-util fork has issues disabled, so this is filed here; the fix needs to go to the plume-util repository the fork tracks.