future proof method that is marked for incompatible change #6
Conversation
There was a problem hiding this comment.
When platform encoding is being used, this change removed it from being printed to the log. This is useful ingformation to users that don't know what encoding is being used.
This can be accessed by simply calling "System.getProperty( "file.encoding" )" instead of "ReaderFactory.FILE_ENCODING".
|
Is it useful though? The relevant detail is that the platform default is being used. The point is that whatever value that is, and which we would print here, is not reliable or consistent. |
|
In my experience it is very useful. When moving a project from being built locally by developers to a CI solution, developers are often surprised when they don't get the same results there. |
|
Yes, and when that happens they should sit down and figure out which encoding they should use (usually UTF-8). They should not simply copy and paste whichever encoding they happened to be using by accident like they're writing a characterization test to mimic the idiosyncratic behavior of their development box. |
|
If their build is failing, then knowing the encoding that was used gives
them a hint about what not to use.
|
and generally be explicit about which dependencies this depends on