> On 21 May 2015, at 22:20, Andreas Delmelle <andreas.delme...@telenet.be> > wrote: > <snip /> > FWIW - Those 17 'high' priority "Reliance on default encoding" warnings are > definitely worth checking out. So far, I think the handful that I already > looked at can be safely added to the exclusions list, but this is *exactly* > the type of bug that can lead to issues at runtime that are a real pain to > track down, if they do arise.
Some follow-up: In the meantime, I had a look at each of those 17, and the suggestion here would be a temporary blanket exclusion of the pattern for now. Note - This should be replaced with an explicit set of approved exclusions, so that future warnings in new code would not go unnoticed due to the exclusion of the entire bug pattern. Only one occurrence seemed suspicious, and would be easy to resolve, but not really an issue - Strictly speaking, RtfHandler.startDocument should be using explicit US-ASCII encoding for the stream. No priority to fix, since the RTF library already contains code that automatically escapes any character outside of the US-ASCII range. The remainder can be divided in following groups: 1) The actual source encoding seems out of FOP's control (?) - 5 warnings This is the case for the warnings in the o.a.f.fonts package and the one o.a.f.render.ps package. The binary data here comes from FontBox classes. Not sure how to resolve those. I have to defer to the experts here. Should we assume that constructing Strings from the byte arrays using default encoding is always going to work here? 3) Default encoding is used as a fallback/last resort - 3 warnings The developer in question added this in a catch-block for an UnsupportedEncodingException, so the choice is either to terminate or try the default, which should always work... Strictly speaking, if an explicit encoding is expected, I would say that the safer bet is to terminate, rather than silently revert to the default, but I am not going to insist. 2) Reads from/writes to the console (System.in/System.out) - 3 warnings Using the default encoding is OK in this case. 4) Private methods where byte-to-string and string-to-byte conversions are guaranteed to always happen on the same platform - 1 warning No problem to use default encoding here. 5) Classes used by the build or from the command line - 4 warnings Should be cleaned up over time, but no priority now. KR Andreas
